On 26 June 2012 20:41, Tomi Valkeinen <tomi.valkei...@ti.com> wrote: > On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote: >> On 26 June 2012 20:38, Tomi Valkeinen <tomi.valkei...@ti.com> wrote: >> > On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote: >> >> On 26 June 2012 17:33, Tomi Valkeinen <tomi.valkei...@ti.com> wrote: >> >> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote: >> >> > >> >> >> Seems similar, but I only tested OMAP4 HDMI. >> >> > >> >> > Would something like this one below work for you? It fixes the issues on >> >> > my overo board. >> >> > >> >> I think this should work too (I will get to test it only tomorrow). >> >> >> >> Though I don't think it'll fix stack spew when run without >> >> CONFIG_PM_RUNTIME. Maybe we could simply remove the WARN_ON in the >> >> xxx_runtime_put() as Alan noted? >> > >> > Yes, that's a different issue. I'll look at that also. >> > >> Well, my patch took care of that also. But I agree, that could be >> added separately as well. > > Well, I don't agree that your patch is correct =). I don't think it's > right to skip runtime get and put when pm_runtime_enabled() returns > false. > While I think your patch is simpler and achieve the same, I also think your fears about this patch are unfounded.
A quick snack for thought... > > But if pm_runtime_get_sync() returns an error, it means the HW has not > been resumed successfully, and is not operational, > Not always. The HW could be in RPM_ACTIVE state while PM on it could be disabled, if the returned error is -EACCESS. And pm_runtime_enabled() only catches a potential -EACCESS. BTW, I just tested your patch and it worked for me as well. But as suspected, it doesn't help the stack spew of CONFIG_PM_RUNTIME:=n So I understand, I only need to resend the other three patches ? Thanks. -- 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
