On Sun, 23 Jun 2013, 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 usual order of things is: Maybe you don't care about this any more, but in case you still do, here's my perspective. This applies to the drivers in the standard kernel; I don't know anything in particular about the driver used in the RPi. > I submit an out URB (to rx my response) No, an OUT URB transfers data _out_ from the computer to the device. The response goes from the device _in_ to the computer. > I submit an in URB (with my request) Likewise, your request goes _out_ from the computer to the device. > My in URB completion handler is called > My out URB completion handler is called. Because of the confusion in the terminology, it's hard to tell what this means. I take it that normally, the request completes before the response does (which is what you would expect). > 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. That can happen. URBs for any single endpoint always complete in order of submission (unless one of them terminates prematurely because it was cancelled), but this is not guaranteed for URBs to different endpoints. If both URBs happen to complete in the same frame or microframe, the order in which the handlers get called is entirely up to the host controller driver. Of course, if you didn't submit the response URB until after the request URB completed, then everything would always go in the expected order. (Just stating the obvious...) > I'm (obviously) new to device drivers, but I wasn't able to find any > information saying that this is normal. Is it? It is a little unusual, but it can happen. > 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. > > Anyway, I guess I'll test on my workstation for now, but it would be > nice to understand what's happening. Things will probably make more sense on a workstation. Hope this helps, Alan Stern -- 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
