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... > 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.) > 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 -- 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
