| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Use strtobool instead of kstrtoint when parsing bool from sysfs.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
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>
|
|
Convert simple/strict_strto* functions to kstrto* functions. Only simple
cases are converted.
simple_strto* uses are still left to places where it is used to parse
numbers from a list of numbers. These need some other solution than
kstrto*.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
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>
|
|
Using bool silently converted input to 0 or 1, making the range check
useless. Use unsigned long instead, and convert to bool later. Found by
Coverity.
Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
|
