From: Mathias Nyman
> Sent: 11 October 2017 15:41
..
> If possible I'd like to try and find some other solution before chopping the
> Segment
> size to smaller than 256.
> I think that your first proposal of adding the guard page to the segment pool
> could be an option.
Would be a waste of a page - which could be used for a lot of extra TRB.
IIRC the rings used to have 16 TRB - that caused some serious problems,
but I can't quite remember all of them.
I don't remember anything that made 256 'good' - except that it was a 4k page.
Did you add something to copy badly fragmented buffers to get around the
problem with misaligned LINKs. ISTR my original fix didn't work for requests
for very long disk transfers.
> other things that could be checked:
> - check if we can avoid prefetching over segment by altering the link TRB
> chain or ioc bits.
> - check if we prefetch only over mid-ring link TRBs or also over last link
> TRB with cycle change.
> If only mid ring then we could try to allocate two consecutive pages for
> the segments.
> - check if prefething over segment is related to manually setting the TR
> dequeue command.
> Set TR deq ponter command fushes xHC chached TRBs and might be the cause
> for the prefetch.
I'd guess that it is reading multiple TRB and can't know one is a LINK.
> - does VIA VL805 have some odd xhci page size (xhci PAGEZISE register), does
> it affect anything.
It is 'funny' that this device will try to prefetch TRB across 64k boundaries
but data buffers aren't allowed to cross them.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
