Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

On Tue, Dec 11, 2012 at 12:01:57PM +0200, Roger Quadros wrote:
> On 12/11/2012 11:12 AM, Jassi Brar wrote:
> > On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> >> On 12/06/2012 04:34 PM, Jassi Brar wrote:
> >>>>
> >>>> Yes, this is where we can think of a generic PHY driver to make sure thy
> >>>> PHY has necessary resources enabled. In the Panda case it would be the
> >>>> PHY clock and RESET gpio.
> >>>>
> >>> I wonder if ehci-omap should assume, besides regulator, a clock might
> >>> also be need to setup for the transceiver chip.
> >>> Maybe "usbhs_bdata" in board-omap4panda.c should have
> >>> .reset_gpio_port[0]  = GPIO_HUB_NRESET ?
> >>>
> >>
> >> Just like the regulator, reset_gpio_port has nothing to do with OMAP
> >> EHCI. So we would want to get rid of that too from the OMAP USB driver.
> >>
> > Looking at the code I realized we already book resources only for
> > populated ports. Saving power from LAN9514 chip would come from a
> > separate solution. So, for now when our transceiver, USB3320, has
> > simple hardwired configuration probably just platform_data/DT would
> > do. When we come across some programmable transceiver (like USB3503
> > over i2c), that might warrant a separate PHY driver. Still I don't
> > think we could have a 'generic' phy driver.
> > 
> Yes I2C based Phys might need a different driver. At least we could have
> a generic PHY driver for all ULPI based phys. (NOTE: the USB3320 is also
> configurable and can work in OTG mode)

we already do, that's what nop-xceiv is for.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]