On 26.9.2019 8.45, Felipe Balbi wrote:
Hi,
David Laight <David.Laight@xxxxxxxxxx> writes:
From: Mathias Nyman
Sent: 25 September 2019 15:48
On 24.9.2019 17.45, alex zheng wrote:
Hi Mathias,
...
Logs show your transfer ring has four segments, but hardware fails to
jump from the last segment back to first)
Last TRB (LINK TRB) of each segment points to the next segment,
last segments link trb points back to first segment.
In your case:
0x1d117000 -> 0x1eb09000 -> 0x1eb0a000 -> 0x1dbda000 -> (back to 0x1d117000)
For some reason your hardware doesn't treat the last TRB at the last segment
as a LINK TRB, instead it just issues a transfer event for it, and continues to
the next address instead of jumping back to first segment:
That could be a cache coherency (or flushing (etc)) issue.
The Link TRB is written very early, right after the ring segment is allocated,
and before any other TRBs. 255 other TRBs were written and handled by hw
on this segment after this, so not very likely a flushing/cache coherency issue.
XHCI has a HW-configurable maximum number of segments in a ring. AFAICT,
xhci driver doesn't take that into consideration today. Perhaps the HW
in question doesn't like more than 3 segments.
Mathias, what was the register to check this? Do you remember?
I only recall a limit for the event ring in the HSCPARAMS2 register(ERST MAX),
not for transfer rings.
Other things to look at would be
- check that Toggle Cycle bit is correct for last segments link TRB (incomplete logs)
- some old xHCI hardware needed the Chain bit set in link TRB for some isoc rings
- was ring recently expanded?, usually rings start with only two segments
Mathias
