Hi, On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote: > On 11/21/2012 05:32 PM, Alan Stern wrote: > > On Wed, 21 Nov 2012, Roger Quadros wrote: > > > >> On 11/21/2012 04:52 PM, Alan Stern wrote: > >>> On Wed, 21 Nov 2012, Felipe Balbi wrote: > >>> > >>>> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote: > >>>>> From: Andy Green <andy.green@xxxxxxxxxx> > >>>>> > >>>>> This patch changes the management of the two GPIO for > >>>>> "hub reset" (actually controls enable of ULPI PHY and hub reset) and > >>>>> "hub power" (controls power to hub + eth). > >>>> > >>>> looks like this should be done by the hub driver. Alan, what would you > >>>> say ? Should the hub driver know how to power itself up ? > >>> > >>> Not knowing the context, I'm a little confused. What is this hub > >>> you're talking about? Is it a separate USB hub incorporated into the > >>> IP (like Intel's "rate-matching" hubs in their later chipsets)? Or is > >>> it the root hub? > >>> > >> > >> This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard > >> wired on the panda board with its Power and Reset pins controlled by 2 > >> GPIOs from the OMAP SoC. > >> > >> When powered, this chip can consume significant power (~0.7 W) because > >> of the (integrated Ethernet even when suspended. I suppose the ethernet > >> driver SMSC95XX) doesn't put it into a low enough power state on suspend. > >> > >> It doesn't make sense to power the chip when USB is not required on the > >> whole (e.g. ehci_hcd module is not loaded). This is what this patch is > >> trying to fix. > > > > Ah, okay. Then yes, assuming you want to power this chip only when > > either ehci-hcd or the ethernet driver is loaded, the right places > > to manage the power GPIO are in the init and exit routines of the two > > drivers. > > > > The Ethernet function actually connects over USB within the chip. So > managing the power only in the ehci-hcd driver should suffice. the thing is that this could cause code duplication all over. LAN95xx is a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any* platform could use it and could hook those power and reset pins to a GPIO. If we handle this at ehci-omap level, we risk having to duplicate the same piece of code for ehci-*.c Since that's a hub driver anyway, I wonder if it would be better to play with those gpios somewhere else ?!? -- balbi
Attachment:
signature.asc
Description: Digital signature
