On Fri, 9 Sep 2011, Felipe Balbi wrote: > > > you mean ioremap() and that sort of thing ? ehci-$arch.c should only > > > pass the correct resource down to ehci-hcd.c. And ehci-hcd.c should > > > request_mem_region() and ioremap_nocache() it. > > > > Yes, that's what I mean. Except that the request_mem_region() and > > ioremap_nocache() could be done in usbcore rather than in ehci-hcd.c. > > I see. OTOH, ehci-hcd, does need to access its own memory space, right ? > > But if you're talking about something like ehci-hcd calling a certain > API where it will ioremap() the resource and return the virtual address, > then it might work just fine. Right. We might be able to get usb_add_hcd() to use the resource values directly instead of taking the values from the usb_hcd structure. > > I think you're mixing up two different layers of the device model. > > The bus_suspend and bus_resume routines are used for power management > > of the root hub, whereas the dev_pm_ops methods are used for power > > management of the controller device itself. > > > > Thus the bus_suspend and bus_resume affect things like the downstream > > USB ports and the frame counter, whereas (in the PCI driver, for > > example) the dev_pm_ops methods put the entire controller into D0 or > > D3. > > Hmm, you're right. But couldn't we make it so that ehci-hcd's dev_pm_ops > handle the bus states and PCI, if it's is a parent device to ehci-hcd, > puts the controller to D0 or D3 ? > > I mean, an EHCI controller has many ports and each port can have many > children devices. > > So, when all children of a specific port are suspended, that port goes > to USB Bus Suspend, and when all ports are in suspend state, PCI > driver's runtime_suspend will get called, and that will put the > controller to D0 or D3. > > Does that work ? > > What I mean is that ehci-hcd.c::runtime_suspend() method will handle USB > ports and frame counter and pci.c::runtime_suspend() would handle > controller states. Does that work ? When all the ports are suspended, the root hub's runtime_suspend routine gets called. That routine is in usbcore (the same routine is used for runtime suspend of every USB device), and it indirectly invokes the HCD's bus_suspend method. After the root hub has been suspended, ehci-pci.c's runtime_suspend method is called. It puts the controller into D3. We can't call ehci-hcd.c::runtime_suspend() for anything, because there's no struct device that routine could be attached to. > > It sounds like you don't have a complete picture of how USB power > > management is implemented. Almost all of the things you're asking for > > are things we already do. The one exception is something we can't do > > at all, because root hubs have to use the same dev_pm_ops method > > pointers as any other hub. > > that's a good point. I had missed that :-p Does this explanation make things clearer? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
