On Monday 20 September 2004 2:16 pm, Alan Stern wrote:
> > > 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.
That'd probably work too.
> > 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.
A truly awful term, it's clearly not "global" since it doesn't affect
even one other host controller. Or even all of that controller, given
the register access issue!! We hates it forever.
> > > 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?
That wasn't the kind of resume processing I was thinking of;
too bad you couldn't read my mind! Yes, that's right; but it's
not involved in "echo -n 0 > /sys/bus/usb/devices/*/power/state"
either. And putting khubd in that call path would be needlessly
awkward.
> 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.
Right, though the patch I just sent does include a tweak to prevent
resubmit when the interface is suspended. Similar; but I'm not sure
I like that. (It made some things begin to work OK though.)
> 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().
Actually the root hub interface is supposed to have been suspended
already then, killing urbs. I think there's some other problem there.
(The bugs are starting to get fenced in ... )
> 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?
What I said right above this: when the hub suspends, urb_kill should
stop resubmits until resume. But there do seem to be some glitches there,
maybe (I just thought about this) because a "killed" urb isn't the same as
one that's just been unlinked.
- Dave
-------------------------------------------------------
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
