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. 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. 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. So the tasks I see here are: 1. Split PHY from OTG (covered by this set) 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? Br, -- heikki -- 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
