[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7f80320-02bb-a573-dd95-b6d58c260624@quicinc.com>
Date: Thu, 29 Dec 2022 13:14:43 -0800
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Mathias Nyman <mathias.nyman@...ux.intel.com>,
<srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
<perex@...ex.cz>, <broonie@...nel.org>, <lgirdwood@...il.com>,
<andersson@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
<gregkh@...uxfoundation.org>, <Thinh.Nguyen@...opsys.com>,
<bgoswami@...cinc.com>, <tiwai@...e.com>, <robh+dt@...nel.org>,
<agross@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
<alsa-devel@...a-project.org>, <devicetree@...r.kernel.org>,
<linux-usb@...r.kernel.org>, <quic_jackp@...cinc.com>,
<quic_plai@...cinc.com>
Subject: Re: [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter
support
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
Powered by blists - more mailing lists