On 27 June 2012 00:14, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On Tue, 2012-06-26 at 22:31 +0530, Jassi Brar wrote: >> >> > 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. > > True. But the HW could also be in disabled state. And that would lead to > a crash when accessing the registers. > > It is not a fatal error if pm_runtime_get returns -EACCES, but we sure > shouldn't ignore it (or avoid it with pm_runtime_enabled()), but handle > it. In some rare cases it could be ok to get -EACCES, but that's a > special case, not standard. > You are mixing up generic concepts with what we have in omapdss. Believe me, I do understand it's bad to proceed without caring for returned _errors_. The way omapdss is organized -EACCESS is _not_ an error, it just denotes PM is disabled on the device and that DISPC is in RPM_ACTIVE is backed by the fact that HDMI always hold a reference between resume-suspend and DISPC goes to suspend last and resume first. >> 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 ? > > Yes, please. > OK, will do today later. Regards. -- 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
