On Wednesday 22 February 2012 12:19 PM, Tomi Valkeinen wrote:
On Wed, 2012-02-22 at 11:15 +0530, Archit Taneja wrote:
On Tuesday 21 February 2012 09:38 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-21 at 19:36 +0530, Archit Taneja wrote:
From: Lajos Molnar<la...@ti.com>
If DSS is suspended during a wait_for_vsync operation, it may loose its clock.
Request runtime_pm around wait_for_vsync.
Signed-off-by: Lajos Molnar<la...@ti.com>
Signed-off-by: Archit Taneja<arc...@ti.com>
---
drivers/video/omap2/dss/dispc.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
This only handles omap_dispc_wait_for_irq_interruptible_timeout(),
there's also omap_dispc_wait_for_irq_timeout().
However, I think it'd be better to do the runtime_get/put in the caller,
instead of in these dispc's wait funcs. While it doesn't really matter
with dss_mgr_wait_for_vsync(), for dss_mgr/ovl_wait_for_go() it makes
much more sense to get/put there just once, instead of every time the
omap_dispc_wait_* is called.
Right, that makes sense. Btw, in the current code, how do we ensure that
clocks are enabled when someone calls omap_dss_mgr_apply().
We don't. Apply does not touch any of the registers if the corresponding
manager is not enabled, so there's no need to enable clocks.
Okay, so if a manager is disabled, we won't write to the registers, but
still update the private data of the manager and connected overlays, and
these will be later written to the registers once the manager gets
enabled. Makes sense.
In the older apply, we used to always enable clocks, even if we wrote to
registers or not. So I got mixed up with that.
Thanks,
Archit
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
