summaryrefslogtreecommitdiff
path: root/drivers/video/omap2/omapfb/omapfb.h
AgeCommit message (Collapse)Author
2011-07-01OMAP: DSS2: OMAPFB: Implement auto-update modeTomi Valkeinen
Implement auto-update mode for manual-update displays. omapfb driver uses a delayed work to update the display with a constant rate. The update mode can be changed via OMAPFB_SET_UPDATE_MODE ioctl, which previously called omapdss but is now handled inside omapfb, and a new sysfs file, "update_mode". The update interval is by default 20 times per second, but can be changed via "auto_update_freq" module parameter. There is also a new module parameter "auto_update", which will make omapfb start manual update displays in auto-update mode. This auto-update mode can be used for testing if the userspace does not support manual update displays properly. However, it is a very inefficient solution, and should be considered more as a hack for testing than something that could be used as a long term solution. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-07-01OMAP: DSS2: OMAPFB: Add struct to store per-display dataTomi Valkeinen
Create a new struct omapfb_display_data to contain omapfb's private per-display data. Move the bpp override there. This struct will be used to hold auto/manual update state of a display in the following patches. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-11OMAP: DSS2: OMAPFB: make DBG() more resistant in if-else constructionsNiels de Vos
When DBG() is used in a simple if-else, the resulting code path currently depends on the definition of DBG(). Inserting the statement in a "do { ... } while (0)" prevents this possible misuse. Signed-off-by: Niels de Vos <ndevos@redhat.com> [tomi.valkeinen@ti.com: changed the title of the commit msg] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-11OMAP: DSS2: Move display.h to include/video/Tomi Valkeinen
arch/arm/plat-omap/include/plat/display.h is an include for the OMAP DSS driver. A more logical place for it is in include/video. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2010-08-03OMAP: DSS2: OMAPFB: Add some locking debug checksVille Syrjälä
Trigger WARN_ON() messages from various places in the code in case the memory region is not currently locked. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-08-03OMAP: DSS2: OMAPFB: Make lockdep happyVille Syrjälä
When more than one memory region needs to be lockd at the same time use the memory region id to fix the order in which the locks are taken. Also one needs to use the _nested() versions of the locking primitives. The memory region id can serve as the lock class there as well. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-08-03OMAP: DSS2: OMAPFB: Convert the memory region locking to rwsemVille Syrjälä
R/W semaphore is a good fit for the memory region locking pattern. So use it. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-08-03OMAP: DSS2: OMAPFB: Add locking for memory regionsVille Syrjälä
Add locking to the memory regions to make sure the memory region size won't be changed while some other piece of code is performing some checks or setup based on that information. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-08-03OMAP: DSS2: OMAPFB: Add support for switching memory regionsVille Syrjälä
Separate the memory region from the framebuffer device a little bit. It's now possible to select the memory region used by the framebuffer device using the new mem_idx parameter of omapfb_plane_info. If the mem_idx is specified it will be interpreted as an index into the memory regions array, if it's not specified the framebuffer's index is used instead. So by default each framebuffer keeps using it's own memory region which preserves backwards compatibility. This allows cloning the same memory region to several overlays and yet each overlay can be controlled independently since they can be associated with separate framebuffer devices. Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-08-03OMAP: DSS2: OMAPFB: Skip unnecessary set_overlay_info()Ville Syrjälä
In omapfb_enable_overlay() if the overlay state is already what we want skip the set_overlay_info(). Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-02-24OMAP: DSS2: move get_recommended_bpp()Tomi Valkeinen
Move get_recommended_bpp() from omap_dss_device to omap_dss_driver. This is part of a larger patch-set, which moves the control from omapdss driver to the display driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-02-15OMAP: DSS2: OMAPFB: Add omapfb_update_window prototypeTomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2009-12-09OMAP: DSS2: omapfb driverTomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>