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@xxxxxx> 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:
signature.asc
Description: Digital signature
