On Monday 27 September 2004 2:11 pm, Alan Stern wrote:
> On Mon, 27 Sep 2004, David Brownell wrote:
>
> > 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.
> > Driver model state probably needs to grow to include the "idle"
> > bit too ... letting drivers support "active-enough" modes that
> > are also low power states (like suspending idle mice), and
> > hardware wakeup.
>
> The "idle" states I described earlier had nothing to do with power levels.
Right ... and splitting them out from managing PM levels should
be what lets the PM core stop getting confused about low-power
versus active/usable.
> I included them only as a way of communicating to drivers that they should
> prepare for a memory snapshot. Given some other way to do that, there's
> no reason to keep an "idle" bit.
I'd rather have an "active" bit (everything is initially idle, yes?);
it'd be useful for things other than snapshotting.
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.
> You should call them "suspend-with-wakeup" and "suspend". Don't confuse
> it with "idle". (Unless I'm the one who's confused and you mean something
> totally different...)
Different. If it's idle, by definition it will not issue wakeups.
But there are lots of suspend states that can wake up; those
are still active devices. As examples: USB root hubs that
have suspended their busses; USB mice that are suspended
and enabled wakeup.
> The way I envision it working is that the user tells the PM core to go to
> Standby mode, for example.
I see that as going to the active policy module, which uses PMcore
to do its stuff ... eventually. The current kernel/power/* code would
be re-used, but it'd need to be taught to act a bit differently. Not
near-term changes ...
> The PM core works its way down the device
> tree, telling drivers about the change. When it reaches a PCI USB host
> controller driver, the code in hcd-pci decides what the new PCI state
> should be (D3hot -- this may already have been decided by higher-level PCI
> drivers)
... and bus-specific logic (like driver-specific logic) would be factored
a bit differently. Probably all PCI devices would use common rules,
entering D3hot in most cases -- but only in the power-it-down stage,
at the very end of "enter standby" (~= PCI D1 for some devices)
or whatever system stae was specified..
> > I'm trying to tie threads together here. How does this mesh with
> > what you were saying about an idle state? Wouldn't that first
> > pass better be viewed as "idle all drivers"? Otherwise you're
> > making STR vs STD matter to drivers, which is what I thought
> > you agreed should NOT matter.
>
> 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.
> The difference between STR and STD _does_ matter to drivers (although
> maybe only to "bus adapter" code), since it is the drivers who have to
> decide what device-specific power level is appropriate for STR or STD.
But again, that's just the final stage of the PM state change, and
they'll be told the relevant constraints up front. And for PCI,
it's not exactly going to matter ... the device can go into at most
PCI D3hot. STR vs STD doesn't matter to the hardware. And
drivers must in any case (!!) be prepared to handle funky states
during resume().
- Dave
-------------------------------------------------------
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
