I've done some work on the pxa27x UDC driver which may be of interest to others. I have CDC-Ethernet running but can't get RNDIS to work (fresh pairs of eyes would be welcome).
The patches: http://projects.o-hand.com/hx2750/patches/usb_add_epalloc-r1.patch provides usb_ep_autoconfig() with more information about the configuration, interface and altinterface combinations any particular endpoint might take. This is unfortunately necessary to correctly setup the pxa27x (see below). usb_ep_autoconfig can then optionally call a driver provided configuration function (ops->ep_alloc) instead of using its autoconfigure logic. This shouldn't change any existing behaviour and reading the comments in that function, it looks like such a function was already envisaged? Comments would be welcome on any better way of doing this. http://projects.o-hand.com/hx2750/patches/usb_pxa27x_udc-r0.patch is the pxa27x driver itself. I've taken the one from handhelds.org and made changes to get full CDC-Ethernet running with it instead of CDC-Subset by handling the pxa27x specific configuration issues properly. I've also started the process of cleaning up the style a bit although there's still a way to go. This patch is now being used in the Zaurus kernel tree and there are a couple of Zaurus specific lines of code in there which can easily be abstracted to the platform data. The tricky problem with the pxa27x is that it has 24 endpoints, each of one of which can only be active for one configuration, interface and altinterface combination. The driver therefore maps multiple pxa endpoints to one linux usb_ep structure and this is why the above interface details are required. Once pxa27x controller is enabled, you can't change these numbers... g_zero is known to work with this driver and tests with usbtest.c only fail on test 11 (count > 1 on double stalls). g_serial and g_filestore haven't been tested yet. RNDIS Issues As mentioned above, CDC-Ether works fine. If an RNDIS connection is attempted, the controller receives an RNDIS request and queues an "RNDIS RESPONSE_AVAILABLE" message via the status (interrupt) endpoint. The host never appears to actually transfer this message across the wire though as the controller never informs the transfer was completed. Whether the host knows the message is waiting on the status ep is unknown and I lack the hardware to check this. Having tried many different things to try and provoke this transfer, I'm at a loss as to why it doesn't work. Perhaps a fresh pair of eyes looking at it might spot something. I was slightly concerned that the data endpoints on interface 1 get activated whilst interface=0 and data gets queued against them prematurely as this could have been upsetting the controller. I changed this locally to match the CDC-ether method of waiting for the SET_INTERFACE command and it made no difference to the above problem though (something like http://projects.o-hand.com/hx2750/patches/usb_rndis_tweaks-r0.patch ). Any collaboration on improving this code would be welcome. I'd also be interested in a rough indication as to what needs doing to the driver itself before it can be merged into mainline linux. At a minimum I suspect it needs: 1. Coding style changes to be completed / code cleanup (removal of pxa25x related comments) 2. Proper abstraction of device specifics (mainly UP2OCR handling) 3. Proper pull up handling (again UP20CR handling) 4. Perhaps some kind of interfacing with the pxa27x ohci_hcd (is there some similar code for the omap udc?) Anything else? Regards, Richard ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
