Messages in this thread | | | Date | Thu, 29 Dec 2022 13:14:43 -0800 | Subject | Re: [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support | From | Wesley Cheng <> |
| |
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
| |