Hi Sven, I had a closer to look at the stalled sam-ba tools issue before proceeding with the sam-ba driver revert and need to revise my statements below. On Tue, Mar 22, 2011 at 05:13:34PM +0100, Johan Hovold wrote: > On Tue, Mar 22, 2011 at 02:41:38PM +0100, Sven Köhler wrote: > > Am 22.03.2011 11:43, schrieb Johan Hovold: > > > There is one more issue, though; the SAM-BA devices can not handle > > > merged write request, that is, (at least to me) they seem to be > > > violating the cdc specification: > > > > > > "The data is always a byte stream. The Data Class does not define the > > > format of the stream, unless a protocol data wrapper is used." > > > > What you say is, that the SAM-BA device cannot handle the case that a > > single command spreads among two packets, or if multiple commands are > > contained in one packet? > > Multiple commands in one packet. The SAM-BA devices can handle merged multiple command in one packet as well as commands split over multiple packets. > > How did you test it? > > Do you have test program? > > This was what made the generic usb-serial driver break when the write > fifo was introduced, and why I wrote a custom write implementation > for sam-ba, effectively by-passing the fifo. The SAM-BA tools indeed broke with the introduction of write aggregation (through the write fifo), but it was not the aggregation per se but rather changed timings that caused the tools to fail. In particular, the tools stalled during initialisation after issuing the following commands while trying to read the response to the latter: 47 32 30 30 30 30 30 23 0a 77 32 30 30 30 30 34 2c 34 23 0a Adding a delay between the two commands, or simply adding a timeout and resending the second, should read return 0, solved at least this issue. Of course, I do not have access to the SAM-BA sources, so I have only verified this much using a simple test program and cannot guarantee that there are no other similar issues. Nonetheless, this seems to be a user-space bug which should have been fixed by Atmel. Thanks, Johan -- 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
