On Wednesday 29 April 2009, Wu, Hao wrote: > Dear all: > We are developing the driver for Intel Moorestown Platform > USB OTG controller. Intel Moorestown USB OTG controller has > USB EHCI or USB device operation using the same hardware. We > modified kernel EHCI driver to support its host function, > wrote one new driver (client controller driver) for its device > function and one new driver (transceiver driver) to implement > OTG SRP and HNP functions. Ideally you'd be able to submit host-only and peripheral-only support patches, with the remaining OTG bits later. The HCD and peripheral controller drivers are both fairly substantial chunks, though I suspect you didn't need to change much in EHCI (other than for OTG). There should be host-only and peripheral-only configuration options. > User can switch its role between > host and peripheral via sysfs interface. The default role is > decided on plug type. But because we can't find a full OTG > compliance product in the market, the HNP function testing > is executed between the Moorestown USB OTG controllers themselves. USB-IF seems to have had the highspeed OTG Protocol Test (OPT) modules on backorder forever. :( Other options include: (a) Fullspeed OPT, if you still have one. (Disk died in mine, I've got to reinstall...) (b) Other fullspeed OTG devices, like Atmel's AT90USBKEY which is a fullspeed $30 (at Digi-Key) OTG device, which comes with default firmware which ISTR will do HNP. Not yet (c) OMAP3 Beagleboard, ~$150, since its OTG patches aren't fully cooked yet. (HNP support is in the -next tree, but doesn't yet pass OPT conformance.) Incestuous testing -- Moorestown to itself -- is OK but not as convincing as one might prefer. > The drivers are still in development as well as Moorestown > platform. We have cleaned the coding style using checkpatch.pl > and finished testing though not all bugs are solved. Are they *ever* all solved? Sigh. ;) > Before we submit this driver, we would like to know whether > there are any other criteria as required to meet. Well, the code should get reviewed first; you'll likely get a few more comments than just checkpatch.pl, and with any luck you'll get good technical review. Reviews of big patches -- like, I'll assume, the peripheral controller driver -- take time. So it's worth submitting them sooner. You should be able to run the "usbtest" cases from this; best if the "test.sh" script can run at least over the full weekend, if not the full week: http://www.linux-usb.org/usbtest/ That means a Linux PC ("known good") talking to your Moorestown peripheral ("device under test"). Those tests will uncover different stuff than USBCV, which you should also pass. That also means some Linux Peripheral ("known good") talking to your Moorestown in host mode (with EHCI). The webpage above gives a few suggestions to help that not be an incestuous Moorestown-only test. > And do we need to submit the modification to EHCI > driver, client controller driver and transceiver > driver at the same time? Don't need to. That's a lot of complex low-level code though (as I expect you know!), so smaller chunks may be easier for reviewers to digest. Also, ensuring that the system builds and works in all three modes -- host only, peripheral only, or OTG -- will likely be easier if you can submit patches that are not interdependent. - Dave p.s. I'm still waiting on an updated patch for the Poulsbo USB peripheral controller driver. That had some really goofy control-OUT code, pretty much guaranteed to break. > > Thanks > Hao > -- 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
