summaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2/omapfb/omapfb-ioctl.c
Commit message (Collapse)AuthorAgeFilesLines
* OMAPDSS: add helpers to get mgr or output from displayTomi Valkeinen2013-06-171-2/+7
| | | | | | | | | | 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 <tomi.valkeinen@ti.com>
* Revert "OMAPFB: simplify locking"Tomi Valkeinen2012-12-131-9/+59
| | | | | | | | | This reverts commit b41deecbda70067b26a3a7704fdf967a7940935b. The simpler locking causes huge latencies when two processes use the omapfb, even if they use different framebuffers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: simplify lockingTomi Valkeinen2012-12-071-59/+9
| | | | | | | | | | | | | | | | | | | | | | | Kernel lock verification code has lately detected possible circular locking in omapfb. The exact problem is unclear, but omapfb's current locking seems to be overly complex. This patch simplifies the locking in the following ways: - Remove explicit omapfb mem region locking. I couldn't figure out the need for this, as long as we take care to take omapfb lock. - Get omapfb lock always, even if the operation is possibly only related to one fb_info. Better safe than sorry, and normally there's only one user for the fb so this shouldn't matter. - Make sure fb_info lock is taken first, then omapfb lock. With this patch the warnings about possible circular locking does not happen anymore. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
* OMAPFB: move dssdev->sync call out from omapfb_realloc_fbmemTomi Valkeinen2012-12-071-0/+4
| | | | | | | | | | | | | | Currently omapfb_realloc_fbmem() calls dssdev->sync to ensure any possible frame update is finished. This patch moves the call to dssdev->sync from omapfb_realloc_fbmem to the callers of omapfb_realloc_fbmem. This keeps dssdev related calls out from omapfb_realloc_fbmem, which makes sense as the function should only deal with fb memory. Also, this seems to avoid a lockdep warning about possible circular locking. However, the exact reason for that warning is still unclear. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: remove exported udpate windowTomi Valkeinen2012-12-071-24/+3
| | | | | | | | omapfb contains an exported omapfb_update_window function, which, at some point in history, was used by a closed source SGX driver. This was a hack even then, and should not be needed anymore. So remove it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge tag 'omapdss-for-3.7-rc' of git://gitorious.org/linux-omap-dss2/linuxTomi Valkeinen2012-11-261-1/+1
|\ | | | | | | | | | | | | omapdss fixes for 3.7-rc Conflicts: drivers/video/omap2/dss/dss.c
| * OMAPFB: Fix possible null pointer dereferencingTushar Behera2012-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 952cbaaa9b8beacc425f9aedf370468cbb737a2c (OMAPFB: Change dssdev->manager references) added checks for OMAPFB_WAITFORVSYNC ioctl to verify that the display, output and overlay manager exist. However, the code erroneously uses && for each part, which means that OMAPFB_WAITFORVSYNC may crash the kernel if no display, output or manager is associated with the framebuffer. This patch fixes the issue by using ||. Signed-off-by: Tushar Behera <tushar.behera@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPFB: fix compilation errorTomi Valkeinen2012-11-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | omapfb compilation fails on x86 (but not on omap): drivers/video/omap2/omapfb/omapfb-ioctl.c: In function ‘omapfb_ioctl’: drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: error: ‘SZ_1M’ undeclared (first use in this function) drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: note: each undeclared identifier is reported only once for each function it appears in Fix this by including linux/sizes.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | Merge branch '3.8/vram-conversion' of git://gitorious.org/linux-omap-dss2/linuxTomi Valkeinen2012-11-161-7/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/video/omap2/dss/Kconfig drivers/video/omap2/omapfb/omapfb-ioctl.c drivers/video/omap2/omapfb/omapfb-main.c Merge changes to make omapfb use common dma_alloc, and remove omap's custom vram allocator.
| * | OMAPFB: use dma_alloc_attrs to allocate memoryTomi Valkeinen2012-11-131-7/+7
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use dma_alloc_attrs to allocate memory instead of omap specific vram allocator. After this we can remove the omap vram allocator. There are some downsides to this change: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support "passing" a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram". 4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAP: move arch/arm/plat-omap/include/plat/vrfb.hTomi Valkeinen2012-10-171-1/+1
|/ | | | | | | | | Now that vrfb driver is not omap dependent anymore, we can move vrfb.h from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
* OMAPFB: Change dssdev->manager referencesArchit Taneja2012-09-261-2/+5
| | | | | | | | To retrieve the manager pointer via a device, we need to now access it via the output to which the device is connected. Make this change in omapfb_ioctl() where the WAITFORVSYNC ioctl tries to access the manager's device. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: OMAPFB: always allow to configure overlayGrazvydas Ignotas2012-05-111-2/+2
| | | | | | | | | | | | | Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails. Instead of failing, allow it to configure the first overlay as if there was only one overlay, the remaining ones will have to be configured in other ways (sysfs). This allows overlay-controlling programs (like video players) to function properly when framebuffer is cloned to another display (like TV). Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: OMAPFB: check for matching memory size earlyGrazvydas Ignotas2012-04-231-6/+7
| | | | | | | | If the size of memory region that is being set up is the same as before, we don't have to do memory and layer busy checks. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Remove video SRAM supportTomi Valkeinen2012-02-231-1/+1
| | | | | | | | | | | | OMAP SRAM can be used as video memory on OMAP1 and 2. However, there usually is very little SRAM available, thus limiting its use, and no board supported by the kernel currently uses it. This patch removes the use of SRAM as video ram for the omapdss driver to simplify memory handling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
* OMAPDSS: APPLY: move ovl->info to apply.cTomi Valkeinen2011-12-021-6/+6
| | | | | | | | | | 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-021-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-311-0/+1
| | | | | | | | | 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-011-36/+36
| | | | | | | | | | | | | | | | | | | | | 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-111-2/+10
| | | | | | | | 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-111-1/+1
| | | | | | | 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-051-0/+12
| | | | | | | | 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-051-1/+1
| | | | | | | | 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-031-0/+2
| | | | | | | | 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-031-11/+34
| | | | | | | | | | 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-031-8/+2
| | | | | | | | 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-031-11/+33
| | | | | | | | | 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-031-23/+102
| | | | | | | | | | | | | | | | | 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-181-1/+2
| | | | | | | | 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-181-2/+2
| | | | | | | | | 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-241-5/+5
| | | | | | | | | | | | 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-241-4/+9
| | | | | | | | | 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-241-2/+3
| | | | | | | | | 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-241-2/+2
| | | | | | | | | 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-241-1/+1
| | | | | | | | | 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-241-2/+2
| | | | | | | | | 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-241-4/+4
| | | | | | | | | 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-151-0/+24
| | | | | | | | 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-091-0/+755
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
OpenPOWER on IntegriCloud