Re: [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support

[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