Hi, On Wed, Nov 09, 2011 at 12:15:44PM +0200, Heikki Krogerus wrote: > On Tue, Nov 08, 2011 at 04:33:22PM +0200, Felipe Balbi wrote: > > All in all, except for a few comments I had, the series is ok. But I > > truly don't see the big benefit we have out of this. You're just > > renaming a bunch of structures, enumerations and functions without a > > real reason behind it. > > > > What we need in the long run, like I had told you back in Nokia, is to > > be able to compile several transceiver drivers into the same zImage or > > as dynamically loadable modules and still have it working somehow. Which > > means that we need a way for a Link (dwc3, musb, omap_udc, renesas_udc, > > etc) to request a transceiver, or that transceiver has to be assigned to > > a link as a resource. > > > > Also keep in mind that on USB3 device controllers, we will have at least > > two PHYs: one which will be handling USB2 signalling and another which > > will be handling USB3 signalling. > > > > I say "at least" because OMAP boards generally have split PHY > > functionality between internal (into the SoC) entities and an external > > PMIC. If you take OMAP4, for example, we have an internal IP handling > > the data parts and communicating VBUS/ID levels to MUSB while the > > actual VBUS/ID comparators are inside the PMIC. > > > > With this series of yours I don't see any way we could easily model this > > split PHY functionality. > > > > Some OEMs might also decide to ditch completely the internal and PMIC > > PHY functionality in exchange for their own solution of an all-in-one > > PHY (e.g. N900). > > > > So all of that is still a pain in the ass to get sorted out and your > > series isn't helping at all towards that goal so I can't see the real > > benefit in accepting these patches other than having better matching > > structure names. > > > > You didn't even cleanup the <linux/usb/otg.h> header. There's a bunch of > > stuff in there which isn't OTG-related at all and you seem to not have > > cared too much about it. > > > > At the end of the day we need to solve the problems we have and make the > > Embedded part of the USB suport on linux (mainly the gadget framework > > and OTG support) as easy as possible to generate a product out of it. > > > > If you remember the amount of patches we had to get N900 sorted out, you > > know what I'm talking about. To prevent our users from ever rebasing > > their own hacks on their internal trees, we need to provide solutions > > which are flexible enough to have boards with USB2-only, USB3, > > Host-only, device-only, OTG, with and without USB Battery Charging. > > > > As of now we can't. > > > > I hope you have some other patches/ideas behind this series, otherwise > > there's not enough reason to merge it. > > > > I suggest you start laying down your ideas and, where possible, code so > > we can come up with a solution to help everybody. > > To me there are several things that need to be addressed in Linux USB > OTG and Gadget architecture. Having support for multiple transceivers > is one of them, but I'm after clear cut between OTG and PHY first. > > I got the idea of doing it like this when you said: > "I would start by splitting <linux/usb/otg.h> into things which are > really otg specific and things are only related to transceivers...": > > http://www.spinics.net/lists/linux-usb/msg50152.html > > I know you had more in mind, but it felt like the right thing to do. > The changes are quite minor like you said, but they affect many > drivers. It's only the first step but it is enough to introduce the > basic structures. I'm hoping we could at least avoid any new > "langwell_otg" driver that mix controller and transceiver control > into one driver, making them impossible to maintain. > > The idea was indeed to add support for multiple PHYs, but only after > this. good to know that there's more coming. Since we're at the very begining of the 3.2 cycle, you could take some time and prototype a little more of what's coming and how things should look like in the long run. I'll leave this series cook for a little longer before applying. I'll also wait for updates on the comments I had. -- balbi
Attachment:
signature.asc
Description: Digital signature
