talos-op-linux/drivers/video/omap2/omapfb, branch master

video: move fbdev to drivers/video/fbdev

2014-04-17T05:10:19+00:00

The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen Acked-by: Laurent Pinchart Acked-by: Geert Uytterhoeven Acked-by: Rob Clark Acked-by: Jingoo Han Acked-by: Daniel Vetter

Merge branch '3.15/dss-dt' into 3.15/fbdev

2014-03-20T06:13:50+00:00

Merge OMAP DSS DT support

OMAPFB: search for default display with DT alias

2014-03-19T09:03:06+00:00

Improve the search for the default display in two ways: * compare the given display name to the display's alias * if no display name is given, look for "display0" DT alias Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja

OMAPFB: clean up default display search

2014-03-19T09:03:05+00:00

Separate the code for finding the default display into a function for clarity and to make it easier to extend it in the future. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja

OMAPDSS: convert pixel clock to common videomode style

2014-03-05T06:33:30+00:00

omapdss has its own video-timings struct, but we want to move the common videomode. The first step is to change the omapdss's pixelclock unit from kHz to Hz. Also, omapdss uses "pixel_clock" field name, whereas the common videomode uses "pixelclock" field name. This patch changes the field name also, as that makes it easy to spot any non-converted pixel_clock uses. Signed-off-by: Tomi Valkeinen

OMAPFB: disable overlays on driver removal

2014-01-13T10:19:56+00:00

When omapfb module is removed, the driver will turn off all the displays it manages. However, it leaves the overlays enabled. While the overlays are obviously disabled as the displays are disabled, it causes issues when the driver module is loaded again, as at that point the overlays are still enabled on the hardware level. The result is that even if the SW thinks overlays are disabled, they are actually enabled. Fix this by making sure the overlays are disabled at module removal. Signed-off-by: Tomi Valkeinen

OMAPFB: give informative print when probe succeeds

2014-01-13T10:19:55+00:00

It is quite common to have omapfb probe deferred because of a missing resource, and to get omapfb probed succesfully a bit later. This works fine. However, omapfb does not give any print on a successful probe, so if the omapfb is actually never probed again after deferral, this is not shown in the log. To help debugging, add a simple print from omapfb at the end of its probe, saying which display it is using and in which resolution. Signed-off-by: Tomi Valkeinen

OMAPFB: use EPROBE_DEFER if default display is not present

2013-06-17T11:00:54+00:00

Currently omapfb returns EPROBE_DEFER if no displays have been probed at the time omapfb is probed. However, sometimes some of the displays have been probed at that time, but not all. We can't return EPROBE_DEFER in that case, because then one missing driver would cause omapfb to defer always, preventing any display from working. However, if the user has defined a default display, we can presume that the driver for that display is eventually loaded. Thus, this patch changes omapfb to return EPROBE_DEFER in case default display is not found. Signed-off-by: Tomi Valkeinen

OMAPDSS: Implement display (dis)connect support

2013-06-17T11:00:43+00:00

We currently have two steps in panel initialization and startup: probing and enabling. After the panel has been probed, it's ready and can be configured and later enabled. This model is not enough with more complex display pipelines, where we may have, for example, two panels, of which only one can be used at a time, connected to the same video output. To support that kind of scenarios, we need to add new step to the initialization: connect. This patch adds support for connecting and disconnecting panels. After probe, but before connect, no panel ops should be called. When the connect is called, a proper video pipeline is established, and the panel is ready for use. If some part in the video pipeline is already connected (by some other panel), the connect call fails. One key difference with the old style setup is that connect() handles also connecting to the overlay manager. This means that the omapfb (or omapdrm) no longer needs to figure out which overlay manager to use, but it can just call connect() on the panel, and the proper overlay manager is connected by omapdss. This also allows us to add back the support for dynamic switching between two exclusive panels. However, the current panel device model is not changed to support this, as the new device model is implemented in the following patches and the old model will be removed. The new device model supports dynamic switching. Signed-off-by: Tomi Valkeinen

OMAPDSS: add helpers to get mgr or output from display

2013-06-17T11:00:42+00:00

Add two helper functions that can be used to find either the DSS output or the overlay manager that is connected to the given display. This hides how the output and the manager are actually connected, making it easier to change the connections in the future. Signed-off-by: Tomi Valkeinen