On 06/23/2013 01:43 PM, Greg KH wrote:
On Sun, Jun 23, 2013 at 01:13:34PM -0500, Daniel Santos wrote:
So I'm working on this MCP2210 driver which talks in 64-byte
request/response pairs using interrupt URBs (it can be used with
hid-generic, but I don't want to do that). I'm testing on a
Raspberry Pi Model B using the Raspbian 3.9.7 kernel.
My deepest sympathies, the USB host controller driver on the Raspberry
Pi is a huge shop of horrors, it's amazing that it works at all, and
when it does, it eats huge amounts of CPU for no known good reason.
Good luck with it, and be happy that it's working for you in the first
place :)
Anyway...
Well, our project needs more than two USB ports, and we were looking at
the model A anyway, so maybe I should just find some nice USB hub chip
and/or PIC that uses SPI and has a good stable driver and hook it up via
the Pi's SPI interface? I know that sounds kinda stupid when it already
has the USB interface on it, but if it's an unstable thing, it may be
good since we're going to be moving big telescopes around with these
things and it would be bad if it suddenly whacked somebody in the head
because of a bad USB message. :)
My usual order
of things is:
I submit an out URB (to rx my response)
I submit an in URB (with my request)
My in URB completion handler is called
My out URB completion handler is called.
But occasionally (more so when my system is heavily loaded, spamming
printks & such), the out URB completion handler is called first. I
initially thought this was due to the device chattering or some
electrical noise as I have all of this open with wires in
bread-boards & such, but then I dumped the contents of the out URB
and discovered that it was a valid response for the given request.
So the transaction must have completed normally & correctly, but my
completion handlers weren't called in the same order as the actual
communications occurred.
I'm (obviously) new to device drivers, but I wasn't able to find any
information saying that this is normal. Is it?
Yes it is, there is no guarantee in which order an urb callback happens,
as the hardware itself can answer them in different order (the hardware
in the client device, not the host.)
Ahh, this is so good to know. This shouldn't be too hard of a change to
make in my driver.
Also, again usually when I have debug enabled, it is common for me
to have a stalled out URB (that I detect with a manager thread
running in a delayed work queue) that I have to kill and re-submit.
This almost always stalls as well, so I have to re-submit the in URB
(request) as well. I'm not sure of the cause of that either, but it
causes me to think that some of my responses are being dropped on
the floor, which wont allow me to build a reliable device since
double-sending some requests will cause undesired results.
That's probably due to the crappy USB host driver on the rpi. Try it on
a "normal" machine and see what happens there.
thanks,
greg k-h
Well on the bright side, this is a good training ground -- a nice
unstable USB interface that fails a lot in a lot of various ways -- at
least I get to test my error recovery code a lot! I ran it
(reluctantly) on my workstation and it worked flawlessly! At least
until about the 5th SPI message and then my machine hung (I didn't
expect my driver to be perfect yet :). So I guess I'll try it on my
laptop, which doesn't have 5TB of storage to recover when it crashes.
Thanks for the help!!
Daniel
--
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
