Hi Ramya, I've just pushed some fixes to the xhci-streams branch. The errors that were there would have meant that your driver might have received an error code when it called usb_alloc_streams(). Did your code check the return value of that function? Or the return value of usb_submit_urb()? Please test with the latest code and let me know if the bug fixes help your device. Thanks, Sarah Sharp On Mon, Feb 08, 2010 at 05:51:06PM -0800, Sarah Sharp wrote: > On Thu, Jan 28, 2010 at 02:07:54AM +0530, Ramya Desai wrote: > > Dear Experts, > > > > I am trying to use the Bulk streams to make data transfer to/from my > > UASP device. > > xHCI was able to send requests on Status and Data-in pipes using the > > SID 0xFFFE(Prime SID), and it was able to receive the NRDY for both > > requests using the same SID. > > Ok, so your device was in the Idle state at that point. (I'm looking at > figure 8-29 in the USB 3.0 bus specification). > > > Where as, if my device is trying to send the ERDY using the SID > > 0x01(Which is being send using Command IU), > > So your device is attempting to go to the "Move Data" state with > stream ID (SID) 1. > > > xHCI is responding with ACK using 0xFFFF SID. > > Looking at section 8.12.1.4.1, a stream ID (SID) of 0xFFFF is an invalid > stream ID: > > "NoStream – This SID indicates that no Stream ID is associated with the > respective bus packet and the Stream ID field should not be interpreted > as referencing a valid Stream. The NoStream SID value is FFFFh." > > If you look at the Figure 8-29, you'll see your device was supposed to > transition back to the Idle state because the host indicated no data was > available on that stream ID. > > Basically, your device is asking for data on stream ID 1, and the > host is saying that there is no data on stream ID 1. > > > I am attaching the analyzer log file, which shows this behaviour. > > Which host controller is your device running under? > > > Can anyone tell me the place where the ACK signal will be generated > > using the given SID, so that I can debug the code. > > The ACK signal is something the host controller generates. The xHCI > driver adds a Transfer Request Buffer to the stream ring that is used > for that stream ID (SID). Your device will be in the idle state at this > point. When the xHCI driver rings the doorbell for that stream ID, the > host will generate an ACK with that stream ID, and the device will transition > into the Move Data state. > > If you don't ever see an ACK from the host with the stream ID you're > looking for, and if the host always responds to the device's ERDY on > stream ID n with an ACK with the NoStream ID, then I think the buffer > never got posted to the stream ring. > > It's possible that the xHCI driver did something wrong when it added the > transfer request buffer to the stream ring, or made a mistake while > setting up the stream rings. It's possible your UASP driver did > something wrong when allocating stream rings or submitting an URB. I > can't tell unless I see your UASP code. It's also possible that the > hardware is sending a bogus stream ID. I can't tell unless I see the > dmesg log from the computer. > > > Can you turn on CONFIG_USB_XHCI_HCD_DEBUGGING on and send me the output > from the command `tail -f /var/log/kern.log | tee xhci-streams.log`? > Run the command before you plug in your device and send me the output. > The log file is much more useful to me than the analyzer trace. Source > code to your UASP driver would be even more helpful. > > > The Kernel version I am using is 2.6.32-rc6, with "Support for USB 3.0 > > streams" patch supplied by Sarah Sharp ( > > http://git.kernel.org/?p=linux/kernel/git/sarah/xhci.git;a=commit;h=b540c0e55e2b88c2f29543e4170d19ccd12bb62f > > ) > > I assume you're using the whole xhci-streams branch, not just that > commit. The code probably wouldn't compile otherwise. > > I just received a bug fix patch for that branch, let me apply it and you > can test if it works. I'll let you know when I've applied it; I can't > do that until tomorrow. > > Sarah > -- > 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 -- 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
