On Fri, 22 Oct 2004, David Brownell wrote:
> So long as it doesn't get in the way of me finishing basic integration
> of USB_SUSPEND and system suspend, I'm all for it!
It shouldn't interfere. Although it will need to be updated when your
wakeup_supported/enabled stuff gets added to the driver model structures.
> > It would be very nice to integrate this into the new autosuspend
> > picture; as it stands it's rather awkward because it runs in interrupt
> > context -- and each HCD does it differently (or not at all). With the new
> > scheme the hub driver would be in overall charge.
>
> I've thought that too. So you want to save me the effort of writing
> autosuspend logic for EHCI? :)
The secret of successful management is the ability to delegate. I've
decided to delegate that responsibility to you! :-)
> > There are two things to consider here. First, CONFIG_USB_SUSPEND might
> > not be set. Obviously then we wouldn't autosuspend external hubs -- but
> > we would still want to autosuspend root hubs. Not only will this provide
> > a non-trivial power saving in itself, but also it will prevent DMA bus
> > mastering and hence allow the CPU to go to a lower power state.
>
> Thing is, I think EHCI will be able to do that as easily as OHCI can.
> So no _need_ for usbcore to be involved ... except for external hubs.
It isn't as simple as that. There's a real benefit from having all the
autosuspend logic funnel through a single place (the hub driver). If the
HCDs do their own independent autosuspending in addition, the potential
for confusion increases greatly. Remember, the standard suspend pathway
will be present whenever CONFIG_USB_SUSPEND is set.
Furthermore, we may be talking about two slightly different things. The
new autosuspend I'm proposing would work through usb_suspend_device(),
which means changing the hub's state to USB_STATE_SUSPENDED plus doing all
the stuff that goes with it. You can't do this in interrupt context.
What you're doing in OHCI is probably a lot like what UHCI does. It
doesn't interact cleanly with the standard USB device suspend code and
it's complicated by the need to maintain a state machine so that the
necessary actions (and their multi-millisecond delays) can be handled
in_interrupt.
> > Second, not all root hubs support remote wakeup. (All external hubs do,
> > if I'm not mistaken.)
>
> I think all hubs have to handle at least the "resume on change in
> port connect status" style wakeup, including root hubs. Waking
> the system from a sleep state is a different issue, not all root hubs
> are wired to do that.
When a suspended external hub gets a port status change, it has to send a
wakeup signal from its upstream port. (I think if the status change was a
wakeup request then it also has to echo a resume signal out the downstream
ports but I forget the details.) All external hubs are required to have
this capability.
When a suspended root hub gets a port status change, it has to send a
wakeup message upstream to the CPU. This message will take the form of a
normal IRQ if the host controller isn't also suspended, otherwise it will
take some alternate form (like asserting PME#). Yes, some controllers
aren't wired to send an alternate signal.
But on a few systems the UHCI controller can't send either sort of signal,
IRQ or PME#. That is, it can issue an interrupt request but not in
response to a port status change if the root hub is suspended (there's no
problem if the root hub is active or "half-suspended"). For these broken
systems it makes sense to say the root hub doesn't support wakeup.
> That is, if you partition a hub into "downstream" (towards peripherals)
> and "upstream" (towards CPU, through buses and bridges) links, the
> downstream can always suspend/wake, but the upstream link may
> not be able to do that except as part of a system sleep transition.
I think this agrees with what I described in greater detail above.
> > Again obviously we wouldn't want to autosuspend a
> > root hub if it won't send wakeup requests. But with root hubs there's
> > another alternative, something we might call a "half-suspended" state.
> > The driver can basically stop the controller and turn off most of its
> > high-power components, while leaving the port status registers alive. In
> > effect, the root hub's downstream ports would be suspended while its
> > upstream port would be awake. This would have most of the advantages of
> > suspending the root hub (power savings, no DMA) but without actually going
> > into the suspended state.
>
> I describe that differently: the root hub itself is fully suspended.
> The frame clock might not even be running. Nothing goes on
> downstream of that hub, nothing.
My use of terms isn't the same as yours, although I agree in substance.
I say that the root hub isn't suspended because it can receive and reply
to URBs and because root_hub->state is USB_STATE_CONFIGURED, not
USB_STATE_SUSPENDED. In other words, as far as usbcore is concerned the
root hub isn't suspended. (And as far as the hardware is concerned the
root hub isn't running.)
> What's _not_ suspended is the interface to its bus ... it still issues
> IRQs, the host can read registers, and so on. Upstream activity
> is completely normal, outside of system sleep states.
Yes, the upstream part is normal while the downstream part is suspended.
That's why I called it "half-suspended".
> > Wakeup requests wouldn't be needed since the
> > hub driver could still learn about status changes, through the usual
> > status interrupt URB. And this could be used without CONFIG_USB_SUSPEND,
> > since the device wouldn't actually be suspended.
>
> Erm, it won't involve _any_ kind of "wakeup" from a system sleep
> state: the CPU is getting scheduled, so there's no sleep state!
"Wakeup" can refer to waking the CPU from a system sleep state, but it can
also refer to resuming a suspended device. Of course, with a
"half-suspended" root hub neither kind of wakeup is needed!
> > The HCDs will have to be changed to add support for "half-suspend". This
> > shouldn't be too hard, and it can be done separately from the major part
> > of the work.
>
> Hmm ... other than not working for external hubs, or through a
> settable timer, how does the current OHCI behavior differ from
> what you're describing?
I'm not familiar with all the details of the OHCI behavior, but here
goes...
The transitions are transparent to the hub driver rather than
controlled by it;
The transitions take place in interrupt context rather than in
process context;
The transitions take place independently of any other autosuspend
code in the hub driver (which would naturally apply to root hubs
as well as to external hubs);
The transitions take place independently of the driver model's
conception of the root hub's state;
If an OHCI controller is autosuspended with a suspended child,
does the driver wake the controller up when a someone wants
to resume the child?
Alan Stern
-------------------------------------------------------
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
