On Wed, 24 Nov 2004, David Brownell wrote:
> On Wednesday 24 November 2004 13:25, Alan Stern wrote:
> > On Wed, 24 Nov 2004, David Brownell wrote:
> >
> > > On Tuesday 23 November 2004 14:15, Alan Stern wrote:
> > > > It's not a question of using timers or anything else. If wakeup_enabled
> > > > isn't set then the HCD _must not_ allow wakeup/resume signalling in any
> > > > form. Regardless of whether it is able to. That's the whole point of
> > > > the
> > > > wakeup_enabled flag, right?
> > >
> > > I'd describe "wakeup_enabled" as "allow wakeup", rather than
> > > "!wakeup_enabled" as "... also treat wakeup as error".
> >
> > Isn't that the same as what I just said? If wakeup_enabled set means
> > "allow wakeup", then what can wakeup_enabled clear mean but "don't allow
> > wakeup"? What else could it mean?
>
> "should" is weaker than "must". There are devices that ignore
> the setting of the device's remote wakeup feature flag (or
> maybe the default is just set wrong: "on", not "off").
> Likewise "enable" is different from "allow".
Okay, fine. My original point still stands: If wakeup_enabled isn't set
then the generic hub autosuspend code won't suspend a hub. A root hub can
do whatever the HCD likes under such circumstances, but I still think it
should do its best to mimic the behavior of a real hub when the
REMOTE_WAKEUP feature is clear.
> > Furthermore, things might not be under khubd's control. Suppose the HC
> > device's wakeup_enabled is on but the root hub's is off. If the driver
> > allowed the root hub to generate wakeup requests anyhow, it could wake
> > the entire system up from a global suspend state before khubd has a
> > chance to do anything.
>
> I don't understand how a hub that's "off" could generate any
> kind of event at all!
Minor point. You misread what I wrote; the hub isn't off, rather its
wakeup_enabled flag is off.
> > But hubs won't autosuspend, so HCDs will have to do
> > something else to reduce power.
>
> I didn't say "no autosuspend", where did that come from?
You didn't say it; I did. I said that when wakeup_enabled is clear, HCDs
shouldn't use resume signalling and so should not autosuspend.
> > > I've called what OHCI does now "autosuspend", which expects IRQs
> > > to work (and tolerates root hub timer polling) ... usbcore has
> > > no need to care about that state.
> >
> > Maybe you should call it something else,
>
> That's a generic term though; I'd call lots of things
> "autosuspend". Calling it something else wouldn't
> change the fact that OHCI calls that state "suspended",
> without reference to the Linux PM framework, and that
> the driver automatically puts the hardware into that
> state whenever it makes sense.
>
>
> > if the root hub isn't totally
> > suspended. Think of it this way: If root_hub->state ==
> > USB_STATE_SUSPENDED and the hub driver's hub_suspend routine has been
> > called, then it really is suspended. Otherwise it isn't, it's only
> > "half-suspended" or something similar.
>
> It's what the OHCI spec describes as "suspended";
> no "half" about it.
>
> Would you be happier to talk about different
> mechanisms like "controller autosuspend" (what
> OHCI does) versus "hub autosuspend" (does those
> other things too)? The HCD hub_suspend() method
> doesn't change anything except HC registers, so
> it's for "controller suspend".
Well, if you can dislike the USB spec's use of "global suspend" then I can
dislike the OHCI spec's usage. :-)
I also dislike using "controller autosuspend" for this; it sounds too much
like the HC has been put into a PCI reduced-power state (which if I
understand you correctly is _not_ what happens).
I don't have good suggestions for better terminology. There are too many
distinct but similar concepts:
(a) USB device is physically suspended (upstream ports receives no
packets, power usage is very low). This notion does not apply
to root hubs because they don't receive packets on a regular basis
from upstream.
(b) Usbcore thinks a device is supended (udev->state ==
USB_STATE_SUSPENDED and udev->driver->suspend() has been called).
Applies to root hubs as well as real devices, and for real
devices this implies (a) -- unless usbcore is broken!
(c) Root hub is not transmitting packets. It may or may not allow
polling of registers and it may or may not have reduced power use;
these could be considered sub-divisions of (c).
(d) Host controller is in a PCI low-power mode. Only config-space
registers are accessible. Analogous notions apply to non-PCI
controllers. This implies some form of (c).
If you can come up with good names for the (a) - (c) we can refer to (d)
as "HC is suspended". Maybe (a) could be a "physical suspend".
Obviously these definitions overlap and a device may satisfy more than one
of them at a time. Also, I don't know exactly how the OHCI autosuspend
state fits into this classification.
Alan Stern
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
