Re: [PATCH 3/3] OMAPDSS: DSS: Add runtime_pm protection around wait_for_vsync.
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<lajos@xxxxxx> 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<lajos@xxxxxx> Signed-off-by: Archit Taneja<archit@xxxxxx> --- 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.
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html