On Tue, Dec 4, 2012 at 1:09 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 3 Dec 2012, Andy Green wrote: > >> Unless someone NAKs it for sure already (if you're already sure you're >> going to, please do so to avoid wasting time), I'll issue a try#2 of my >> code later which demonstrates what I mean. At least I guess it's useful >> for comparative purposes. > > Before you go writing a whole lot more code, we should discuss the > basics a bit more clearly. There are several unsettled issues here: > > 1. Should the LAN95xx stuff be associated with the ehci-omap.0's > driver or with the hub port? The port would be more flexible, IMO, it shouldn't be associated with ehci-omap controller driver because the LAN95xx is a external USB device and should be nothing to do with ehci, but it is reasonable to be associated with the hub port because it takes a out of band power control method. > offering the ability to turn the power off and on while the > system is running without affecting anything else. But the > port code is currently in flux, which could cause this new > addition to be delayed. > > (On the other hand, since the LAN95xx is the only thing > connected to the root hub, it could be powered off and on by > unbinding the ehci-omap.0 device from its driver and rebinding > it.) > > 2. If we do choose the port, do we want to identify it by matching > against a device name string or by matching a sequence of port > numbers (in this case, a length-1 sequence)? The port numbers > are fixed by the board design, whereas the device name strings > might get changed in the future. On the other hand, the port > numbers apply only to USB whereas device names can be used by > any subsystem. Alos, the same ehci-omap driver and same LAN95xx chip is used in beagle board and panda board with different power control approach, does port driver can distinguish these two cases? Port device is a general device(not platform device), how does port driver get platform/board dependent info? > > 3. Should the matching mechanism go into the device core or into > the USB port code? (This is related to the previous question.) > > 4. Should this be implemented simply as a regulator (or a pair of > regulators)? Or should it be generalized to some sort of PM > domain thing? The generic_pm_domain structure defined in > include/linux/pm_domain.h seems like overkill, but maybe it's > the most appropriate thing to use. Not only regulators involved, clock or other things might be involved too. Also the same power domain might be shared with more than one port, so it is better to introduce power domain to the problem. Looks generic_pm_domain is overkill, so I introduced power controller which only focuses on power on/off and being shared by multiple devices. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
