Hi!
> > Thing is, it's the system power states that are placing clock
> > constraints on devices. On OMAP, going into "deep sleep" means
> > you've got to stop using the 48 MHz clock. For "big sleep",
> > you can keep using that clock. Most other CPUs have similar
> > constraints: multiple system states, defined primarily by
> > clock usage.
>
>
> So to focus on one point: "pm_message_t" doesn't work well
> at all, since it doesn't have a way to identify the target
> system power state, and drivers thus have no way to see if
> they should drop their requests for those clocks or whether
> the hardware should keep working away.
Well, in current model, drivers shoudl stop all the activity they can
("deep sleep"). If you want to add support for "big sleep", then you
should probably use flags... I guess calling "big sleep" standby is
okay...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
