Hi!
> > > I'd rather see a struct with a printable name (or even just the printable
> > > name) and drivers knowing which constant pointers to compare to.
> > > And have that name show up in sysfs. Abolish confusion about u32
> > > values, and easily catch all the drivers (ab)using the old value. Not
> > > much code uses those PMcore APIs yet; good changes can be merged.
> >
> > Sounds good to me. The strings could be writable in sysfs as well as
> > readable (to do selective suspend/resume).
>
> Right. Luckily most drivers ignore the driver model PM stuff,
> so the size of such a patch shouldn't be unreasonable.
Yes, but you'd have to change all the prototypes. About one in 10
drivers actually did something with the value, last time I checked.
> However it WOULD eventually let the suspend-to-disk and
> suspend-to-ram scenarios look pretty much the same to
> drivers: In both cases they get:
>
> - a "quiesce" pass, at the end of which all drivers are idled
> so (for STD) a snapshot can be done (with swap partition);
>
> - then a "power down" pass, where suspend-to-disk
> turns everything more or less "off" while suspend-to-ram
> leaves at least non-wakeup devices in PCI D3cold (or a
> roughly equivalent state), and RAM alive.
>
> So those "spurious resume during suspend" paths would
> start to go away, because the first pass wouldn't need to
> involve PM operations -- only the second.
Well, in suspend case it always will be "quiesce", "unquiesce",
"suspend", and no, suspend-to-RAM and suspend-to-DISK will be
different because suspend-to-RAM does not need "unquiesce".
> > If I understand you correctly then no, the first pass has nothing to do
> > with "idle". To implement STD, the PM core would first do a PM_SNAPSHOT
> > double-pass, then create the memory image, then maybe do a resume pass so
> > that the image can be stored, and finally do a PM_SUSPEND_DISK
> > double-pass.
>
> But how is a "PM_SNAPSHOT double-pass" different from "idle
> all drivers"? It certainly shouldn't need to change the PM state
> of any device. The amount of power the consume isn't at
> all the issue ... just whether the driver is active or not. As soon
> as a driver goes inactive, it's safe to snapshot it.
Agreed.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
