Hi Dave: Your feedback is really appreciated. It's a helpful guide for us. :) For OTG, we will purchase the Atmel's AT90USBKEY for the OTG testing, but it may cost a lot of time, so we plan to submit our code (Host patch, Client patch and OTG transceiver patch) respectively to the mailing-list for review first. Thanks Hao >-----Original Message----- >From: David Brownell [mailto:david-b@xxxxxxxxxxx] >Sent: 2009年5月4日 15:30 >To: Wu, Hao >Cc: linux-usb@xxxxxxxxxxxxxxx; Yuan, Hang; Shen, Xiaochen >Subject: Re: USB OTG driver submission question > >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 >> > ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
