Hi!
> I gather that you're more interested in system-wide suspend and resume,
> and not so much in selective suspend/resume. But the two features
> interact and can't be entirely separated. At the very minimum, system
> suspend has to be able to deal with devices that are already in a
> low-power mode because they were selectively suspended.
Yes, agreed. Feel free to submit a patch ;-).
> > > There's no check for suspending a device with fully-powered
> > > children, or conversely, resuming a child while its parent is
> > > still suspended.
> >
> > This only happens in per-device suspend, right?
>
> Not so, or at least, not quite. For example, in
> drivers/base/power/suspend.c, suspend_device() won't do anything if the
> device isn't at full power to begin with. So if the parent is at full
> power but the child is in low power when a system-wide suspend occurs, the
> child will be left at low power while the parent is turned off.
Fixing this should be as easy as removing the test, right?
> > > The locking is insufficient (no protection against calling a
> > > driver's suspend() during probe() for example) and prone to
> > > deadlock.
> >
> > Again, I guess patch will be welcome.
>
> To fix this properly requires changes in the heart of the driver model.
> It can't be patched up simply by altering a few routines in the PM
> core.
You probably need to talk with patrick about this. He is also
interested in per-device states...
> > > The meaning of the power states is unclear, particularly for
> > > buses that don't support all the PCI states.
> >
> > Well, in suspend I'm currently only using 0/3, where 0 is on, and 3 is
> > suspended. What should be done is convert that interface to enums or
> > some kind of structure, probably solving per-device suspend at the
> > same time. I'd prefer drivers to ignore that parameter for now.
>
> Although the picture isn't really clear, I gather the device states one
> really needs to consider could be described something like this (using an
> ad hoc notation):
>
> S0: Full power, S0': Full power,
> IRQ & DMA enabled IRQ & DMA disabled
>
> S1: Low power, S1': Low power,
> IRQ enabled for wakeup requests, IRQ & DMA disabled
> DMA disabled
>
> S2: Power off, S2': Power off,
> IRQ & DMA disabled, IRQ & DMA disabled
> PME# enabled PME# disabled
>
> S0' is a device's initial unconfigured state. S0 is the normal
> operational state. Selective suspend would use state S1. Suspend-to-RAM
> and suspend-to-disk would use S2 for devices that support PME#, otherwise
> S2'. Perhaps there's no need to distinguish between the two; I don't know
> how closely people want to tie remote wakeup enable/disable with power
> states, although they are related concepts.
What is PME#?
> Not all devices need to distinguish among all the states. For example,
> S0, S0', and S1 would all correspond to PCI's D0 state. The differences
> are that in S0' the device's interrupt-enable registers are turned off
> (and likewise for DMA), and in S1 the device's internal clocks and other
> high-power components are turned off. S1' would corrrespond to D3hot, and
> S2 and S2' would correspond to D3cold.
>
> The distinction between the unprimed and the primed states is needed when
> preparing or restoring a memory image for suspend-to-disk. Devices
> shouldn't be allowed to generate interrupt requests at those times.
I do not think we need S1' and S2'. As far as swsusp is concerned,
having S0 and S0' is okay, plus some state suitable for powerdown.
> > > The transitions to and from the device-idle states needed for
> > > suspend-to-disk aren't well defined.
> >
> > I'll answer questions if you promise to submit documentation patch
> > ;-)).
>
> I'll be happy to work on documentation once it's clear exactly how
> everything (including selective suspend) is supposed to work! :-)
Well, IIRC Olivier said he'll do the documentation.
> > device-idle states needs to ensure:
> >
> > * no DMA running
> > * even if kernel state is lost, you are able to bring device back to
> > normal state... Or "when one kernel is replaced with another one, all
> > variables are lost, you still can resume that device". Easily
> > accomplished by having just one hardware state you put it into.
>
> I'm not so sure about that last bit. If a driver was loaded manually or
> by a hotplug program, then it won't be present in the bootup kernel when
> the memory image is restored. Consequently its device won't be put into
> the desired hardware state -- it will be in the virgin unconfigured
> state, S0'. Of course, a driver can tell at compile time whether this is
> the case by testing "#ifdef MODULE".
Hmm, you are right, I have not thought about modules (I do not use
them myself).
> Also, it seems like it might be important to inform drivers, when resuming
> from the "idle for memory image" state, whether the system has gone down
> and come back up in the meantime. In other words, are we resuming for
> purposes of writing the memory image to swap as part of the
> suspend-to-disk, or are we now in the resume-from-disk stage? Drivers
> might want to know.
There are ways to find that out; but I'd rather not pollute interface
with that information. What driver would want that? If there's some,
we can provide second system_state-like variable. But I do not think
any driver needs to know.
> > I'll gladly help with everything thats used by suspend-to-{RAM,disk},
> > which basically means everything but per-device power
> > managment. Per-device power managment basically needs to be designed,
> > first.
>
> Is Patrick the best person to ask about doing that design?
I can't speak for Patrick. [And he was pretty busy lately].
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: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
