On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote: > On 25 June 2012 19:19, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote: > > >> > /* this accesses a register, but the HW is disabled? */ > >> > dispc_read_reg(FOO); > >> > > >> .... the H/W is already always enabled if CONFIG_PM_RUNTIME is not defined. > >> > >> If CONFIG_PM_RUNTIME is indeed defined, pm_runtime_enabled() will > >> always return true after pm_runtime_enable() unless someone disables > >> it explicitly - omapdss or the RPM stack(during suspend/resume). > >> OMAPDSS never does so in the lifetime of a driver. So the only period > >> in which pm_runtime_enabled() returns false, is when the platform is > >> suspending, suspended or resuming. > > > > Right. So what happens in my example above? > > > > Normally if the driver does dispc_runtime_get() and dispc_read_reg(), > > the first call will enable the HW so the reg read works. > > > > But if the pm_runtime is disabled, say, during system suspend, with your > > patch dispc_runtime_get() will just return 0 without doing anything, and > > the dispc_read_reg() will crash because the HW is disabled (because > > nobody enabled it). > > > Hmm, I am not sure if new calls would/should be made to dispc.c after > the system has suspended and before resumed. That is, anything other > than from runtime_resume/suspend callbacks of DSS, DISPC, HDMI, VENC > and RFBI, which rightly don't touch any dss reg but only > enable/disable a clock. They do touch the registers. For example, dispc's callbacks save and restore the registers. The HW should be fully functional during the callbacks. The point of the callbacks is to suspend/resume the HW in question, which of course requires accessing the HW. > As we know, a subsystem should make sure any active work is cleared > out before suspending and set some flag so that nothing runs until it > has resumed. I don't say we can't crash the system with this patch, > but then we would be violating rules of suspend-resume. Let's go back a bit. I feel like I'm missing some pieces of information, as I still don't quite grasp the problem. In the patch you said this fixes an issue with HDMI. Can you tell more about the problem? What code path is being run? Any error messages? I tried system suspend with omap4-sdp and panda, with 3.5-rc2, but neither board seems to wake up from the suspend. Does it work for you? Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
