On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote: > On 27 June 2012 13:43, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > > > I don't like it at all that omapdss disables and enables the panels in > > omapdss's suspend/resume hooks. But I'm not sure how this should work... > > Should panel drivers each have their own suspend/resume hooks, and > > handle it themselves? Or should the call to suspend/resume come from > > upper layers, like omapfb or omapdrm. > > > > I made a prototype patch a few weeks ago to move the suspend to omapfb, > > and it feels better than the current one, but I'm still not sure... > > > IIUC, I have similar opinion. > Each panel having its own suspend/resume sounds like inter-dependency trouble. What do you mean with that? If we just consider omapdss and the panel drivers, I see no dependency trouble. Panels are independent of each other, and omapdss is supposed to handle any locking & refcounting related to multiple panels already, as from omapdss's point of view panel suspend is the same as panel disable. And if we take omapfb/omapdrm into equation, well, in any case it couldn't be any worse than the current one where suspend is handled by omapdss. > I too would prefer suspend/resume propagating from omap-fb/drm, which > imho fits better with the notion of a linux device(omapdss is only > backend). Though I don't have strong feelings about how core then take > various panels up/down optimally. One one hand, I see the combination of omapdss (or the "output" side of omapdss) and a panel as a whole entity. I mean, if you just load omapdss and a panel driver, but no omapfb/omapdrm, you already have a working panel. You don't _need_ omapfb/omapdrm there. And in that sense it'd make sense if the panels did handle their own suspend/resume. But then, in real life it may be just simpler if omapfb/omapdrm handles the suspend. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
