Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux