On Mon, 20 Sep 2004, David Brownell wrote:
> > So we need both a way for khubd to carry these things out, and a way to
> > _tell_ khubd to do them.
>
> Right now there's no restriction that khubd do those things;
> they're implemented by whatever task starts the work.
That's true for suspend and normally true for resume (but not for resume
triggered by root hub remote wakeup!). It's also true for reset_device
but not for hc_died(). The exceptional cases occur because the work was
started by an interrupt handler, not by a task. I was thinking that khubd
would be the logical task for the handler to co-opt, but keventd could
work just as well.
> I find myself thinking about a hardware register with bitfields like:
>
> nerrors - 8 bits, number of consecutive errors
> resume - 1 bit, task is to resume hub
> shutdown - 1 bit, task is to shutdown hub
> reset - 1 bit, task is to reset the hub
> hub changed - 1 bit, from hub status urb, task is ..
> port changed - N bits, from hub status urb, task is ..
>
> Overloading nerrors seems error prone, they'd be better off
> as distinct flags.
Well, we've already got the last two (they are the event_bits). Reset
isn't needed since it's never triggered by an interrupt handler. That
just leaves resume and shutdown (which will be implemented as a power-off
suspend). I guess there's no reason not to add those two bits to struct
hub.
> > You missed my point. The root hub _can't_ "just wake up"; someone has to
> > call usb_resume_device(), and that can't be done in_interrupt.
>
> Like this bit from OHCI:
>
> if (ints & OHCI_INTR_RD) {
> ohci_vdbg (ohci, "resume detect\n");
> schedule_work(&ohci->rh_resume);
> }
How about adding a helper routine to hcd.c to handle this, just like
hc_died()? Then the mechanism can be centralized, with only one place to
change if we decide to use khubd rather than keventd.
> There are lots of integration issues in this area still, but I think all HC
> hardware handles that sort of state ... maybe it'd be useful to call
> that a "bus suspend". It's not a PCI suspend; since that's a PCI IRQ.
> And clearly it's not a "global suspend" even in the context of a
> signle HC, since the controller registers are still in use.
I don't follow that last bit. It seems to me that it _is_ exactly a
"global suspend", in the sense used by the USB spec (7.1.7.6.1 and 11.9).
It's what you get when you suspend the root hub.
> > The
> > logical choice for that someone is again khubd -- so how does the HCD (or
> > the hcd glue layer) tell khubd that the root hub needs to be resumed?
>
> In the current tree, khubd is never involved in resume processing.
That's not true. khubd calls remote_wakeup() when it sees the C_SUSPEND
status bit is set for a device's parent port. Why not make it do the
equivalent thing for root hubs, even though they don't have parents?
Alan Stern
P.S.: Here's something else to consider. It's possible to suspend a root
hub while there are still URBs in flight (URBs for other devices, that is,
not for the root hub itself). With non-root hubs, those URBs would soon
terminate with -EPROTO because of lack of a response from the target
device. But there's no general mechanism to terminate URBs when a root
hub is suspended.
As I see it, we could add special code to the hcd glue layer to unlink all
the URBs just before calling the HCD's hub_suspend(). Or we could leave
the URBs intact. That could cause problems down the road if someone wants
to unlink one of the URBs while the root hub remains suspended. With
uhci-hcd and dummy_hcd it won't work; the unlink won't complete until a
device (or timer) interrupt is received. The HCDs could be modified to
make it work, but it seems easier to unlink everything first. What do you
think?
-------------------------------------------------------
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
