Hi!
> > > > Not. Could pm_message_t have a member indicating the suspend state?
> > >
> > > Well, I thought about that, but I did't know what people on linux-pm would
> > > think about that.
> >
> > Let's get rid of pm_message_t entirely. Didn't we already discuss
> > how the main reasons for it will vanish if drivers get new PM methods?
> >
> >
> > > Alternatively, we could introduce a pm_target() global PM operation that
> > > will
> > > set the target sleep state for the entire system.
> >
> > I hope you mean "get the target state"!!
> >
> > If drivers actually need a handle on that state, that'd be a fair
> > approach; make it an opaque type though, platform-specific.
> >
> > But actually I don't see much point to having such a struct. What
> > matters is the attributes of the target state (what resources will
> > be present, especially), and that rarely needs to be indicated by
> > any kind of cookie. Consider the "current" task ... it's implicit,
> > always present (except in IRQ contexts), and hardly ever accessed
> > despite being more fundamental than "target PM state".
>
> The issue at hand is that some device drivers may need to know what the
> target sleep state of the system will be when their .suspend() routines are
> being executed. Currently, there's no means of passing that information to
> the
> drivers and my question is how to do this.
>
> IMO it can be done in two different ways:
> 1) via a .suspend() argument
> 2) via a global variable that the drivers can read.
Just do 1). Global variables are ugly, and we already have space in
pm_message_t.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
