On 27 June 2012 11:28, Tomi Valkeinen <tomi.valkei...@ti.com> wrote: > > It doesn't matter how omapdss is organized, -EACCES _is_ an error. It > tells us that something unexpected happened, and we should react to it > somehow. > $ git show 5025ce070 Exactly how omapdss is organised is the reason -EBUSY isn't an error there :) Otherwise, omapdss should panic that somehow 'imbalance' has been introduced in rpm.
> > Sure, in the current omapdss neither is a breaking problem, because 1) > the matching dispc_runtime_put() is called also with runtime PM > disabled, and thus we don't decrease the use count, and 2) the HW > happens to be already enabled. But that's just by "luck", and tomorrow > omapdss could be different. > It's no 'luck', but it's because today omapdss takes proper care of PM enable/disable and get/put. Rather, if tomorrow that stops working, it would hint that we managed to screw up the balance. Because if omapdss suspended and disabled PM on DISPC, and still HDMI attempted to access dss regs, that clearly means HDMI hasn't been duly made aware of the DISPC status. Just as preemption and suspend/resume don't introduce any race in locking, RPM won't introduce new imbalance in get/put of omapdss. I am afraid, we won't reach any eureka moment on this, so I would leave us to our conditions. This patch and discussion made me look deep into rpm, I thank you for that and for your patience. Cheers! -- 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
