Re: [RFC PATCH v2 00/22] Introduce QC USB SND audio offloading support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux