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

[Mathias Nyman]

On 29.12.2022 23.14, Wesley Cheng wrote:
> 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.

Good to know, that means interrupter should be chosen per endpoint, not per device.

> > 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.


I started looking at supporting secondary interrupters myself.
Let me work on that part a bit first. We have a bit different end goals.
I want to handle interrupts from a secondary interrupter, while this audio offload
really just wants to mask some interrupts.

Thanks
Mathias