On 25 June 2012 15:00, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On Mon, 2012-06-25 at 14:19 +0530, Jassi Brar wrote: >> On 25 June 2012 11:50, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: >> > On Sat, 2012-06-23 at 13:36 +0530, jaswinder.singh@xxxxxxxxxx wrote: >> .... >> >> Currenlty HDMI fails to come up in the suspend-resume path. >> >> This patch helps that real-world scenario. >> > >> > What is the problem there? It'd be good to explain the problem in the >> > patch description. Does the pm_runtime_get return -EACCES? >> > >> Yes, it returns -EACCESS because RPM on devices is disabled during the >> period from suspend-start to resume-finished. > > So... You didn't answer my first comment, how can the code work? > Sorry, don't know why I thought I didn't miss anything. > The driver needs to enable the HW and the call to pm_runtime_get() is > skipped. Won't this lead to crash as the DSS registers are accessed > without the HW in enabled state? > Hmm... how does the extant code in hdmi driver ensures DSS is up and running ? While it does sound important even to my limited knowledge of OMAPDSS, I see rpm of HDMI, VENC and RFBI only dependent on DISPC, not DSS. And for DISPC these drivers already hold a reference in their display enable/resume and keep it until disable/suspend. So we don't lose DISPC anytime it is really required. > And what happens if the pm_runtime_get() call is skipped, but pm_runtime_put() is not? > Not sure in what newly introduced scenario by this patch, because get/put both check for pm_enabled before proceeding. Am I overlooking something? thnx -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
