On Sunday 19 September 2004 2:01 pm, Alan Stern wrote:
> David:
>
> I did some testing with "echo 4 >/proc/acpi/sleep" and looked at the code
> in drivers/base/power. What a mess! The routines there have no real
> concept of suspending or resuming individual devices, only the entire
> system. This business of handling separately drivers that require
> interrupts to be disabled looks ridiculous -- and it will break the
> necessary topological ordering of the device lists.
Well, there's some concept of selective suspend, but not much of one.
So for example PCI has the concept, as does USB, but as you've
noticed: things misbehave, at very basic levels like not guaranteeing
children suspend before parents ... and devices that are already
suspended getting woken up in order to suspend the whole system.
(Pointlessly woken up, that is.)
Did you know that the swsusp and pmdisk versions are merging?
Last I looked, those changes didn't affect pmcore. However the
"swsusp2" work does have some fixes to that.
> I also found a few bugs in the USB code. The problems can be summed up
> like this: Who is responsible, the caller or the callee, for checking that
> old_state != new_state (i.e., whether the call is necessary), and who is
> responsible for setting dev->power.power_state to new_state? The code is
> inconsistent in its answers to these questions, leading to various weird
> behaviors.
Yes, I have some fixes in that area that I've not yet submitted. Of course,
the PM core code should be making the same tests too, and doesn't;
at least not consistently.
Another example of "PM core design is confused" is that it's not clear
who _interprets_ the states. So for example USB only has one suspend
state. Yet when the PM core code checks those states, it wrongly thinks
that USB has multiple suspend states ... so it tries to "suspend more deeply"
by first resuming (the whole subtree!!) then suspending it again (to the
same level). Bleech.
Oh yes, and there's also the fact that the PM core currently insists
there be a flat namespace of state numbers. As Linus has observed,
given that assumption, and the number of PM-aware drivers in Linux,
there is only one suitable answer: the numers must match what
PCI uses. Yet it doesn't. (See OSDL bugid 2886.)
> For instance, interface drivers' resume() method can be called either from
> finish_port_resume() or from usb_generic_resume(). One checks whether the
> interface has already been resumed and the other doesn't. One of the
> callees, hub_resume(), doesn't check. Hence there can be multiple resumes
> of a hub.
>
> As another example, the bus->op->hub_suspend() call in
> __usb_suspend_device() doesn't have to set power_state because the code
> following the call does so. But the corresponding call to
> bus->op->hub_resume() in usb_resume_device() does have to set power_state.
And there are others. Some of those fixes are in my patchset.
> Even the suspend_device() and resume_device() routines in
> drivers/base/power/{suspend,resume}.c are inconsistent about checking
> whether the device is already suspended/resumed. At least they are
> consistent in relying on the callee to set power_state.
>
> Presumably the callee is always supposed to set power_state, rather than
> the caller -- that is the majority behavior. But who's supposed to weed
> out unnecessary calls?
There are several levels of caller and callee ... too many ways into
suspend()/resume() methods to rely exclusively on a single answer
there, I'm afraid, given the current PM core.
For the moment I'm thinking that protection in both places in usbcore
is safest. Let's try to keep individual drivers from needing to check; we
can do that, since we know there's only one suspend state. Once that
mess starts to behave sanely, we'll at least be armored against the worst
bogosity from the PM core code, and can clean things up later when
the PM framework makes sense.
Unfortunately I think the PM core code still needs to be rewritten, but I'd
rather have USB behaving better -- notably, integrated so that it works
OK with system-wide suspend not just USB suspend/wake/resume -- before
any of that starts. Key deficiencies in the PM core code include the very
notion of a global/flat namespace for device power states (can't possibly
accomodate the variety of real-world options), and thinking that the only
kinds of PM policy are system-wide suspend transitions (rather than for
example having special agents managing transitions, like the cpufreq
governors manage CPU PM transitions).
- Dave
> 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
