USB device controller problems with out-of-tree driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear all,

I'm currently using an ARM9 system called TMPA900 from Toshiba
http://www.toshiba-components.com/microcontroller/TMPA900Family.html

Linux-supported is maintained in an out-of-tree Git repository here
http://git.labs.kernelconcepts.de/?p=topas.git;a=summary

This SoC has an USB device controller which I want to use.

The current driver can be found here:
http://git.labs.kernelconcepts.de/?p=topas.git;a=blob;f=drivers/usb/gadget/tmpa9xx_udc.c;h=5c5bfcc9f7b0d08f5711457aca28bfe8d98a055c;hb=HEAD

The datasheet can be found here, the device controller is explained in
chapter 3.16:
http://www.semicon.toshiba.co.jp/openb2b/relateddocument.jsp?did=19635&lang=en&pid=TMPA900CMXBG&returnFlag=1

Basic USB device support is working. I can load g_serial with "use_acm =
0" and then run minicom on both my target and the host system and send
bytes back and forth. So far, so good.

When using "use_acm = 1", however, things are different on Linux and
Windows hosts.

Under Linux, the communication works fine, but when using Windows, there
are problems. The communication from the Windows host to my embedded
target works fine, ie. I can see all characters typed. But the opposite
direction is not working. Usually only the very first character makes it
through, and then no other character can be seen.

Here are some more observations:

0. Obviously the driver was cloned from the at91_udc driver, because a
lot of the comments match. It's not some other USB host driver IP, so no
other driver can be (re)used. The overall code quality is no very good.
Kernel style is violated very often. Things from the AT91 driver is
sometimes just commented out. It's hard to tell if things are there
because of copy & paste or if they are really needed. Some hardware
specific things are registered, but never actually used, for example the
DMA handling. All in all this does not look very promising.

1. I enabled debugging in all modules that are used and added debug code
here and there. When the first key is pressed, I can see that an USB
packet is created, but apparently either not sent or not received. The
next few keypresses seem to get queued up, some more keypresses and the
driver will hang. I did not include the debug messages here, because
they are specific for this driver.

2. Because there is likely an issue with the driver implementation, I
went ahead and read http://www.linux-usb.org/usbtest/ -> "Testing USB
Peripheral Controller. I used "usbtest" on the host to do the tests, but
this immediately nuked the driver with a segmentation fault. Not a good
sign.

What to do now? I am looking for hints how to proceed.

Especially because of observation 0, I am taking into consideration to
do a rewrite of the driver. For that, I have been looking at existing
drivers obviously, and "dummy_hcd" in particular. Is is a good idea to
take the latter and add the hardware specific parts and remove the
generic software emulation?

Because I am in need for a better driver sooner or later, I am
considering to give this development effort away to somebody that knows
the details better than me. If you are interested in helping me out
against payment of course, please drop me a line off-list.

Best regards
Michael.
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux