aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2/omapfb/omapfb-ioctl.c
Commit message (Collapse)AuthorAge
* OMAPDSS: APPLY: move ovl->info to apply.cTomi Valkeinen2011-12-02
| | | | | | | | | | struct omap_overlayr contains info and info_dirty fields, both of which should be internal to apply.c. This patch moves those fields into ovl_priv data, and names them user_info and user_info_dirty. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: rewrite overlay enable/disableTomi Valkeinen2011-12-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Overlays are currently enabled and disabled with a boolean in the struct omap_overlay_info. The overlay info is set with ovl->set_overlay_info(), and made into use with mgr->apply(). This doesn't work properly, as the enable/disable status may affect also other overlays, for example when using fifo-merge. Thus the enabling and disabling of the overlay needs to be done outside the normal overlay configuration. This patch achieves that by doing the following things: 1) Add function pointers to struct omap_overlay: enable(), disable() and is_enabled(). These are used to do the obvious. The functions may block. 2) Move the "enabled" field from struct omap_overlay to ovl_priv_data. 3) Add a new route for settings to be applied to the HW, called "extra_info". The status of the normal info and extra_info are tracked separately. The point here is to allow the normal info to be changed and applied in non-blocking matter, whereas the extra_info can only be changed when holding the mutex. This makes it possible to, for example, set the overlay enable flag, apply it, and wait until the HW has taken the flag into use. This is not possible if the enable flag would be in the normal info, as a new value for the flag could be set at any time from the users of omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: Add export.h for THIS_MODULE/EXPORT_SYMBOL to drivers/videoPaul Gortmaker2011-10-31
| | | | | | | | | With module.h being implicitly everywhere via device.h, the absence of explicitly including something for EXPORT_SYMBOL went unnoticed. Since we are heading to fix things up and clean module.h from the device.h file, we need to explicitly include these files now. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* OMAP: DSS2: OMAPFB: Implement auto-update modeTomi Valkeinen2011-07-01
| | | | | | | | | | | | | | | | | | | | | 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>
* OMAP: DSS2: Add method for querying display dimensions from DSS driversJani Nikula2011-05-11
| | | | | | | | Add get_dimensions() to struct omap_dss_driver. Use the call, if supported by the driver, in OMAPFB. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Move display.h to include/video/Tomi Valkeinen2011-05-11
| | | | | | | 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>
* OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNCGrazvydas Ignotas2010-08-05
| | | | | | | | FBIO_WAITFORVSYNC is a stardard ioctl for waiting vsync, already used by some userspace, so add it as an alias for OMAPFB_WAITFORVSYNC. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
* OMAP: DSS2: OMAPFB: Check fb2display() return valueJani Nikula2010-08-05
| | | | | | | | Make sure NULL return value of fb2display() is not referenced. Found by Coverity. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
* OMAP: DSS2: OMAPFB: Add some locking debug checksVille Syrjälä2010-08-03
| | | | | | | | 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>
* OMAP: DSS2: OMAPFB: Make lockdep happyVille Syrjälä2010-08-03
| | | | | | | | | | 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>
* OMAP: DSS2: OMAPFB: Convert the memory region locking to rwsemVille Syrjälä2010-08-03
| | | | | | | | 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>
* OMAP: DSS2: OMAPFB: Add locking for memory regionsVille Syrjälä2010-08-03
| | | | | | | | | 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>
* OMAP: DSS2: OMAPFB: Add support for switching memory regionsVille Syrjälä2010-08-03
| | | | | | | | | | | | | | | | | 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>
* OMAP: DSS2: check lock_fb_info() return valueJani Nikula2010-05-18
| | | | | | | | Give up if lock_fb_info() fails, following the same convention as other lock_fb_info() users. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
* OMAP: DSS2: fix lock_fb_info() and omapfb_lock() locking orderJani Nikula2010-05-18
| | | | | | | | | Framebuffer ioctl processing forces lock_fb_info() -> omapfb_lock() locking order. Follow that order to avoid possible circular locking dependency, detected by lockdep. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
* OMAP: DSS2: move update() and sync()Tomi Valkeinen2010-02-24
| | | | | | | | | | | | Move update() and sync() from omap_dss_device to omap_dss_driver. Also, update was hardcoded to use virtual channel 0. This patch adds a parameter that specifies the VC. 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>
* OMAP: DSS2: move set/get_update_mode()Tomi Valkeinen2010-02-24
| | | | | | | | | Move set/get_update_mode() 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>
* OMAP: DSS2: move enable/get_te()Tomi Valkeinen2010-02-24
| | | | | | | | | Move enable/get_te() 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>
* OMAP: DSS2: move get_resolution()Tomi Valkeinen2010-02-24
| | | | | | | | | Move get_resolution() 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>
* OMAP: DSS2: move wait_vsync()Tomi Valkeinen2010-02-24
| | | | | | | | | Move wait_vsync() from omap_dss_device to overlay manager. 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>
* OMAP: DSS2: move memory_read()Tomi Valkeinen2010-02-24
| | | | | | | | | Move memory_read() 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>
* OMAP: DSS2: move run_test()Tomi Valkeinen2010-02-24
| | | | | | | | | Move run_test() 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>
* OMAP: DSS2: OMAPFB: implement OMAPFB_GET_DISPLAY_INFOTomi Valkeinen2010-02-15
| | | | | | | | Previously the only place to get the size of the display was from the DSS's sysfs interface, making, for example, configuring overlays and doing updates on manual displays more difficult. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
* OMAP: DSS2: omapfb driverTomi Valkeinen2009-12-09
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>