Hi Mathias,
On 12/28/2022 7:47 AM, Mathias Nyman wrote:
On 24.12.2022 1.31, Wesley Cheng wrote:
Implement the XHCI operations for allocating and requesting for a
secondary
interrupter. The secondary interrupter can allow for events for a
particular endpoint to be routed to a separate event ring. The event
routing is defined when submitting a transfer descriptor to the USB HW.
There is a specific field which denotes which interrupter ring to
route the
event to when the transfer is completed.
An example use case, such as audio packet offloading can utilize a
separate
event ring, so that these events can be routed to a different processor
within the system. The processor would be able to independently submit
transfers and handle its completions without intervention from the main
processor.
Adding support for more xHCI interrupters than just the primary one make
sense for
both the offloading and virtualization cases.
xHCI support for several interrupters was probably added to support
virtualization,
to hand over usb devices to virtual machines and give them their own
event ring and
MSI/MSI-X vector.
In this offloading case you probably want to avoid xHC interrupts from
this device
completely, making sure it doesn't wake up the main CPU unnecessarily.
So is the idea here to let xhci driver set up the new interrupter, its
event ring,
and the endpoint transfer rings. Then pass the address of the endpoint
transfer rings
and the new event ring to the separate processor.
This separate processor then both polls the event ring for new events,
sets its dequeue
pointer, clears EHB bit, and queues new TRBs on the transfer ring.
so xhci driver does not handle any events for the audio part, and no
audio data URBs
are sent to usb core?
Your entire description is correct. To clarify, the interfaces which
are non-audio will still be handled by the main processor. For example,
a USB headset can have a HID interface as well for volume control. The
HID interface will still be handled by the main processor, and events
routed to the main event ring.
How about the control part?
Is the control endpoint for this device still handled normally by usb
core/xhci?
Control transfers are always handled on the main processor. Only audio
interface's endpoints.
For the xhci parts I think we should start start by adding generic
support for several
interrupters, then add parts needed for offloading.
I can split up the patchsets to add interrupters first, then adding the
offloading APIs in a separate patch.
Thanks
Wesley Cheng
