On Fri, 24 Sep 2004, Oliver Neukum wrote:
> > All right, the whole point is moot. But it does raise an interesting
> > question. The USB subsystem has no way to preserve the existence of
> > devices across power-off. If people want to keep their mounted
> > filesystems on a USB disk during suspend-to-disk we'll need to add
> > an appropriate facility. How should it work?
>
> As it works for other subsystems. If I do a swsusp on my laptop
> it keeps its IP.
I mean, how should the implementation work? There's actually two
problems. (1) How should we preserve the existence of devices across a
per-device power-off suspend (i.e., not system-wide)? (2) How should we
reinitialize devices during the resume-from-idle that occurs after a
memory image is restored?
For (1), I think the hub driver will have to remember devices
attached to powered-off ports instead of just calling usb_disconnect()
right away. When the port power is turned back on, we could allow say 5
seconds for the device to reconnect. When it reconnects we should check
whether the descriptors have changed, just like we do for a device reset.
If it doesn't reconnect after 5 seconds, then we call usb_disconnect().
For (2), we should probably do a reset of the root hubs and let
the mechanism in (1) take care of the remaining details. For this purpose
a device attached to a hub that is reset can be treated the same as a
powered-off device.
> > What I've learned from this discussion is that there needs to be
> > another PM device state, or really a pseudo-state. Let's call it
> > PM_SUSPEND_IDLE. Devices in this state must not perform DMA or issue
> > interrupt requests, but there's no requirement as to how much power they
> > consume. Drivers _should_ be able to place devices into an idle state
> > starting from any PM state, and they _must_ be able to place fully resumed
> > devices into an idle state.
>
> If it is not a state, don't pretend it were. We should define a proper
> method for that in the generic device methods. If you need full quiet
> here, there will be devices that can't do it unless fully awake.
I don't see why this needs to be different from the existing suspend
callback. If you prefer, don't think of PM_SUSPEND_IDLE as a state but
rather as a request for the driver to idle the device. The fact that some
devices won't be able to do it unless they are fully awake is unimportant;
some devices have the same problem when changing to any reduced power
level. The PM core will handle them all in the same way: resume the
device and then retry the original request.
> > When resuming an idle device, it's best for drivers not to assume very
> > much about the actual state the device is in. If the driver supports
> > multiple idle states (varying, say, according to the power level before
> > the device was idled), then the device might be in any of them -- and not
> > necessarily the last one the driver remembers placing it in. If the
> > driver isn't compiled into the kernel, the device might even be in its
> > default or virgin state.
>
> Why wouldn't it be known? Either the kernel has a driver from boot on,
> then the device is fully awake or the driver is read back in, then it's
> a virgin case. The difference is known at compile time.
Here's an example. Suppose the device is in D2 when suspend-to-disk
starts. Assume it's a PCI device, so the driver doesn't need to do
anything more to idle it, and thus the last state the driver remembers is
that the device was in D2. That fact gets stored in the memory image.
Later on the system reboots and the compiled-in driver initializes the
device to its fully-powered D0 state. The resume-from-disk procedure
begins by asking drivers to idle their devices in preparation for
restoring the memory image. Let's assume this device doesn't perform DMA
or generate IRQs even when it's in D0, so the driver leaves it there.
The memory image is restored and all devices are resumed. Now the device
really is in D0, but the driver's last memory is of putting it into D2,
since that value was stored in the image.
Alan Stern
-------------------------------------------------------
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
