Re: [RFC PATCH 2/2] usb: otg: support for multiple transceivers by a single controller

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


On Mon, May 14, 2012 at 08:20:45PM +0800, Peter Chen wrote:
> On Mon, May 14, 2012 at 12:33:25PM +0300, Felipe Balbi wrote:
> > On Fri, May 11, 2012 at 06:01:37AM +0000, Chen Peter-B29397 wrote:
> > >  
> > > > >
> > > > > Thanks for working on this, but it is just a PHY list, not the PHY
> > > > layer
> > > > > used by PHY driver and controller driver who wants to use PHY.
> > > > > Besides, no USB Spec says there is relationship between OTG and USB PHY.
> > > > > Heikki's (including mine) aim is separate PHY from OTG, and create a
> > > > > generic PHY layer. A generic PHY layer is like below:
> > > > >
> > > > > - There is separate folder at drivers/usb/phy, which includes generic
> > > > PHY
> > > > > files and platform PHY drivers.
> > > > > - Platform PHY driver will add itself to PHY list, and implement kinds
> > > > of
> > > > > PHY utilities, like init, suspend, wakeup, charger detector, etc.
> > > > > - The PHY user (controller driver, no only otg driver) will get the PHY,
> > > > > and use it.
> > > > 
> > > > Completely agree with you. But before we have the generic PHY layer,
> > > > we got to have multi-phy support. It's needed for usb3 controller in
> > > > OMAP5 where it needs usb2 phy and usb3 phy.
> > > > 
> > > I see.
> > > 
> > > Felipe, would you give me some suggestion that my generic PHY work
> > > should be on current tree or you think Kishon's patchset is ok, and I should
> > > be based his work when it is in your usb tree?  
> > 
> > Kishon's patchset is a starting point. There are still many questions
> > to be answered: how to we associate a PHY with a particular controller ?
> > How to handle situations with multiple PHYs of the same type ? What
> > about PHYs which are used for different buses other than USB ? For
> > example on OMAP5 we have the same RX/TX Serdes used for USB3 and SATA,
> > ideally we would have only one PHY driver instantiated multiple times
> > for USB3 and SATA.
> Yes, they are needed to think carefully at generic PHY layer.
> For your first two questions, I plan to use controller platform
> device's name as "PHY user", both controller and individual PHY

no name passing please. We had that issue with the CLK framework long
ago. Everybody was passing clock names down to drivers using
platform_data and that's messy.

> driver are platform driver, and "PHY user" can be passed through
> platform data or DT entries.

For the DT case I would prefer a phandle.

> For your last question, do the USB3 and SATA can be used together?

yes

> If it does, software or hardware manages resource competition?

There are two instances of the IP, one for USB and one for SATA, but
they are the same IP nevertheless and should be managed by the same
drivers.

> Seems this PHY is multi-function, is it like we do at drivers/mfd/?

/me feels like drivers/mfd/ is becoming the place to put whatever we
don't know where to put.

> > Kishon's work is targetted at a kernel-wide PHY layer because of that,
> > but we need to do it incrementally and it's likely to take more than a
> > couple major releases to get it right, so we should try to do small
> > steps to avoid regressions.
> Agree, you have thought Kishon's patch are basically ok? If it is, I would
> like add generic PHY driver based on his work, we need PHY driver urgently
> as we have multiple PHYs at board(SoCs), current, only one port can be used
> if we use PHY driver and struct usb_phy.

Sure, I think his patches are fine :-)

-- 
balbi

Attachment: signature.asc
Description: Digital signature


B and H Foto and Electronics Corp.

[Linux Media]     [Video for Linux]     [Linux Input]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]     [More Archives]

Add to Google Powered by Linux