Am Freitag, 24. September 2004 22:15 schrieb Alan Stern:
> 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.
I agree.
> > > 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.
But it isn't a power state. A device can be in D2 and quiet or not quiet.
It's completely orthogonal to power state, thus should be treated as such.
> > > 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.
True. Resume must tell the driver whether its memory about the power
state is correct. If not, the memorized state should be restored. Again, this
suggests that resumption from swsusp ist not a resumption. Probably it
should not use resume at all. There should be a separate method.
Regards
Oliver
-------------------------------------------------------
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
