Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote:
> On 27 June 2012 13:43, Tomi Valkeinen <tomi.valkeinen@ti.com> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]