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);
}
> 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
