On 12/11/13 14:06, Kohji Okuno wrote:
Hi HPS,
All link trbs which are not the end need CHAIN bit, I think.
But, this is errata in xHCI ver 0.95. So, linux has quirk for chain
bit. Could you check linux codes?
Regards,
Kohji Okuno
Hi Kohji,
I went through the Linux codes a bit, and I see they have some quirks
for the chaining bit. Unfortunately Linux does the queuing quite
differently than in FreeBSD and Shara Sharp which is the author of that
code, stated recently a need for rewrite of the TRB/TD stuff in Linux,
so I'm not sure if that means there are more bugs in there or not. Let
me explain a bit how things work in FreeBSD and why I did not put the
chaining bit in line 1895 which you suggest.
In my design the chaining bit should not be set at line 1895, because if
you receive a short packet and nframes > 1, the XHCI should not go to
the end of the frame list, but rather the next frame, nframes + 1.
If the single short OK flag is set on a BULK transfer, yes, it would be
correct to set the chaining bit here, but it is not required, because
we are already are handling activation of the next frame in the function
"xhci_activate_transfer()" and "xhci_skip_transfer()". Transfer here
means zero or more TRBs. We use the cycle bit on the TRB to single step
the frames in software, although you are right that we might optimise
this by setting the chaining bit instead for the BULK case so that we
don't need software intervention to handle the job.
If the multi short OK flag is set, multiple short terminated frames can
be received and then the chaining bit should not be set.
Are you seeing a real problem because of the chain bit not being set, or
is this more the result of code review?
Thank you for the interest in my XHCI driver.
--HPS
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
