On Tue, Feb 05, 2008 at 12:43:49PM -0800, David Brownell wrote:
> On Wednesday 30 January 2008, Sarah Sharp wrote:
> > Hi Dave,
> >
> > I've been looking at ehci_shutdown() in ehci-hcd.c with increasing
> > puzzlement.
>
> I'm puzzled by your puzzlement. ;)
>
> static void
> ehci_shutdown (struct usb_hcd *hcd)
> {
> struct ehci_hcd *ehci;
>
> ehci = hcd_to_ehci (hcd);
> (void) ehci_halt (ehci);
> ehci_turn_off_all_ports(ehci);
>
> /* make BIOS/etc use companion controller during reboot */
> ehci_writel(ehci, 0, &ehci->regs->configured_flag);
>
> /* unblock posted writes */
> ehci_readl(ehci, &ehci->regs->configured_flag);
> }
Whoops, I meant ehci_stop(). Do my questions make more sense now?
> > Why shut off port power before attempting to stop the host controller from
> > processing the periodic and async schedules?
>
> Which lines makes you think it does that? The call to ehci_halt() should
> stop all processing -- first. The ehci_turn_off_all_ports() will then
> clear PORT_POWER, on systems which allow that.
>
>
> > It seems like you want to allow
> > the host to complete whatever transactions it was in the middle of.
>
> Given the system is shutting down, and that every driver with pending
> transactions already had its chance to insist they complete ... no.
>
>
> > If ehci_shutdown() is trying to stop attach/detach notifications,
>
> The ehci_halt() code disables the IRQs. There is a minor oddity
> there, in that this code isn't grabbing the spinlock ... which
> means that some other CPU could poll the hardware too. And nothing
> update the HCD state. Feel free to submit a patchlet to fix those.
>
>
> > that will only
> > work if the host controller supports port power switching.
>
> Actually that's somewhat silicon-specific. I agree that it would make
> more sense to expect the root hub to work without the RUN bit set, since
> key parts of it can be done with combinatoric logic rather than needing
> latches that are clocked by more than a bus write cycle. (And one might
> expect multi-MHz clocks to be off until RUN is set, or on power-aware
> designs to be gated off until some high speed port activity requires it.)
>
> But that's not how the EHCI spec is written ... and some implementations
> of the root hub really _don't_ work unless RUN is set.
>
> The reason to try powering off the ports is that, well, the system is
> shutting down. Why waste (potentially battery) power? Whatever runs
> next can turn it back on if it wants. And if PPS isn't set, then trying
> to clear the per-port power-enabled flag is supposed to be a NOP.
>
>
> > ehci_shutdown() also calls ehci_reset() after shutting down the schedules.
>
> Ah, not the version I'm looking at (above), from current GIT.
>
> - Dave
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
