Hi Mathias,
On 1/26/2023 1:23 AM, Mathias Nyman wrote:
On 26.1.2023 5.14, Wesley Cheng wrote:
Changes in v2:
XHCI:
- Replaced XHCI and HCD changes with Mathias' XHCI interrupter changes
in his tree:
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters
I'll submit the first three patches from that branch myself to usb-next,
might modify
them slightly.
Just need to make sure they don't cause regression. Those are changes I
want done anyway.
Sounds good! Thanks!
Adjustments made to Mathias' changes:
- Created xhci-intr.h to export/expose interrupter APIs versus
exposing xhci.h.
Do you think using the xhci-intr.h is a viable solution for class
drivers to request for a secondary interrupter?
Moved dependent structures to this file as well. (so clients can
parse out
information from "struct xhci_interrupter")
- Added some basic locking when requesting interrupters.
- Fixed up some sanity checks.
- Removed clearing of the ERSTBA during freeing of the interrupter.
(pending
issue where SMMU fault occurs if DMA addr returned is 64b - TODO)
Was this solvable by first clearing high 32 bits and then low 32 bits?
During the freeing of the secondary interrupter, the SMMU fault wasn't
resolvable with clearing the high bits first. This does somewhat give
me the notion that the xHC is attempting to access the event ring base
address every time the ERSTBA is written. I believe the hi-lo write
didn't work, as this time we are zero'ing out the base address. (SMMU
FAR=0x0)
As stated in Table 5-40 in the XHCI spec, when we write a 0 to the
secondary interrupter ERSTSZ, it should disable that event ring. In
this case, do we really need to explicitly clear the base address
register? If I don't clear the ERSTBA (during free), then I don't see a
SMMU fault even after the event ring has been freed. (ie event ring
memory has been unmapped from the SMMU) So this should mean the xHC
hasn't attempted to access that unmapped region for the memory address
stored in the ERSTBA.
Likewise, we'll write the ERSTBA again during the alloc phase to a valid
and mapped address.
Thanks
Wesley Cheng
