> On Tue, Nov 29, 2011 at 11:43:46AM +0200, Heikki Krogerus wrote: > > Hi, > > > > On Mon, Nov 28, 2011 at 01:14:22PM +0000, Chen Peter-B29397 wrote: > > > Hi Heikki, > > > > > > Any updates for your patch? If possible, I would like to co-work with > you > > > about this patch, and test it at my platform. > > > > I'm afraid I don't have any updates for these. I'm stuck with some > > other things at work, so any help would be appreciated. > > > > I think we need to have a new plan how to go forward with these. My > > idea was that these would be really only the fist set, followed by > > the very basic support for multiple PHYs and some minor reorganizing > > of the code. However, Felipe commented about the importance of the > > multiple PHYs, and if I understood correctly, he would like to see > > it already at this first stage. Felipe, please correct me if I'm > > wrong. > > I mentioned that I would like to hear at least some plans because it > wasn't clear from your patchset what you wanted to do in the long run > ;-) > > > This is a problem as I newer planned to come up with anything more > > then very basic support for multiple transceivers. I don't have a plan > > for it, and even though I understand some special cases that need to > > be addressed, like RX-51 which has two transceivers, I don't know all > > the different platforms/things that we need to consider. I guess OMAP4 > > and USB3 are most obvious ones. So, we need a plan/design for multi > > PHY support and I'm not the correct person to come up with it. > > Kishon has been working on that part on top of your patchset. Kishon ? > > > My goal on top of have the PHY split from OTG, is to have generic OTG > > stage machine as part of the OTG utility. This would be useful > > initially with the various ChipIdea UDC drivers that all seem to have > > the OTG state machine implemented separately, the Marvell one being > > the last to do this. The idea is to implement support for this generic > > state machine for the ci13xxx_udc, that we are planning to make the > > only driver for all the users of the ChipIdea UDC. Obviously the > > generic OTG state machine would be useful with other controllers > > besides ChipIdea. > > sure. > > > So the tasks I see here are: > > > > 1. Split PHY from OTG (covered by this set) > > Kishon had a few comments to some of your patches and so had I (IIRC), > you need to sort those out and resend the series, then I can apply them. > > > 2. Support for multiple PHYs (I can't take care of this) > > 3. Generic OTG sm as part of the utility > > > > Since these features have raised interest on many, I'm hoping we can > > have a discussion about how we want to go forward with these and > > perhaps about the workslit. Does the multi PHY support really need to > > be part of the first task of splitting PHY from OTG? Felipe, it was > > originally your idea to start by simply splitting PHY from OTG, or did > > I misunderstood you? If you feel this is not the correct approach from > > the beginning, then please comment. How would you guys like to do > > this? > > let's get those comments sorted out, then I can take your patches and > Kishon can send his take on multiple-PHY support. Without multiple-PHY, > we can't support easily USB3 peripheral/drd controllers. > Balbi, I can also give some help for this. Freescale i.mx51 bbg platform has two phys at board, one is on-chip UTMI phy for OTG controller, the other is ULPI phy for HOST 1 controller. I can post a patch using refined heikki's phy utility file, related phy drivers, and i.mx host driver ehci-mxc.c. Then we can more clearly how separated phy struct works (split from otg), phy driver works and how multiple PHYs works, and refine a good PHY framework. Do you think so? > -- > balbi -- 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
