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 driver are platform driver, and "PHY user" can be passed through platform data or DT entries. For your last question, do the USB3 and SATA can be used together? If it does, software or hardware manages resource competition? Seems this PHY is multi-function, is it like we do at drivers/mfd/? > > 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. > > Even though Kishon's patchset doesn't allow for multiple PHYs of the > same type, it's still better than what we have today - only a single > global PHY pointer -, right ? Yes, it is. > > -- > balbi -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
