From: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Michal Pecio <michal.pecio@gmail.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-sound@vger.kernel.org
Subject: Re: [PATCH v2 0/4] Add larger page size support for USB audio offload path
Date: Mon, 31 Aug 2026 17:16:49 -0700 [thread overview]
Message-ID: <0deb246b-0387-4921-b875-9477d73cdeed@oss.qualcomm.com> (raw)
In-Reply-To: <c3f69010-4263-4d71-bdfd-62f21989b639@linux.intel.com>
On 8/31/2026 6:04 AM, Mathias Nyman wrote:
> On 8/29/26 00:37, Wesley Cheng wrote:
>> On some environments, 16kB pages can be enabled from the Linux subsystem,
>> which manages the IOMMU mappings for the audio DSP within the system. In
>> the current design, the following assumptions break when 16k pages are
>> utilized:
>> 1. xHCI ring size is equal to PAGE_SIZE
>> 2. Ring addresses start at the beginning of a page
>>
>> When the USB offload driver maps the rings (w/ the audio DSP SID), it is
>> set with a 16k granular, which is a problem, as several xHCI rings could
>> exist on the same page. This is because the rings are currently allocated
>> from the segment_pool. Hence, potentially mapping non USB audio related
>> rings into the region accessible by the audio DSP.
>>
>> To mitigate this, this series introduces a separate segment_pool
>> associated to each sideband instance. Before the USB audio offload path
>> is enabled, the USB audio data streams/endpoint are not active. Only when
>> the class driver issues a usb_set_interface() call (done from
>> snd_usb_endpoint_prepare()), will the xHCI allocate the transfer ring
>> resources. Which pool is selected is all based on if the sideband path
>> is being enabled, and if so, memory can be allocated from that pool,
>> which expects to be owned in conjunction with the audio DSP. This
>> concept allows to keep the same model existing in xHCI, where multiple
>> 4k segments can reside on the same page, which reduces potentially over
>> allocating based on the page size.
>>
>> Likewise this mechanism also allows for the offload client driver to
>> determine which SID is associated to the segment_pool if it decides to
>> map outside of the Linux subsystem. The new ring allocation flow for
>> sideband/offload clients will be as follows:
>>
>> qc_usb_audio_offload_probe()
>> ├─ segment_pool = dma_pool_create(...)
>> ▼
>> xhci_sideband_register(intf, XHCI_SIDEBAND_VENDOR, segment_pool,
>> notify_client)
>> │ sb->segment_pool = segment_pool
>> ▼
>> uadev[card_num].sb = sb
>>
>> handle_uaudio_stream_req()
>> ▼
>> enable_audio_stream(subs, ..., pcm_card_num)
>> ├─ data_ep = uaudio_find_host_endpoint(subs, subs->data_endpoint)
>> ├─ xhci_sideband_add_endpoint(sb, data_ep) ← ep->sideband = sb; sb-
>> >eps[ep_index] = ep
>> ├─ snd_usb_endpoint_prepare(chip, sync_endpoint) ─┐
>> ├─ snd_usb_endpoint_prepare(chip, data_endpoint) ├─→
>> xhci_check_bandwidth()
>> │ ▼
>> │ xhci_endpoint_init(xhci, virt_dev, ep, ...)
>> │ pool = sideband ? sideband->segment_pool : xhci-
>> >segment_pool
>> │ new_ring = xhci_ring_alloc_from_pool(..., pool, ...)
>> │ ▼
>> │ xhci_ring_alloc_from_pool(..., pool, flags)
>> │ ring->segment_pool = pool
>> │ ▼
>> │ xhci_alloc_segments_for_ring(xhci, ring, flags)
>> │ xhci_segment_alloc(xhci, ring->segment_pool, max_packet,
>> num, flags)
>> │ ▼
>> │ xhci_segment_alloc(xhci, pool, max_packet, num, flags)
>> │ seg->trbs = dma_pool_zalloc(pool, flags, &dma)
>> ▼
>> xhci_sideband_get_endpoint_buffer(sb, data_ep) → xhci_ring_to_sgtable()
>>
>> qc_usb_audio_offload_disconnect() / unreg_xhci:
>> ├─ segment_pool = sb->segment_pool
>> ├─ xhci_sideband_unregister(sb)
>> ▼
>> dma_pool_destroy(segment_pool)
>>
>> Similar logic is added for the secondary interrupter path as well. The USB
>> offload class driver calls xhci_sideband_create_interrupter(), which will
>> be responsible for allocating the secondary event ring.
>
> The custom dma pool looks like a good solution.
>
> I think we should tune this a bit and pass the custom pool pointer to
> xhci_sideband_add_endpoint() and xhci_sideband_create_interrupter() instead
> of xhci_sideband_register()
>
> xhci.h:
> struct xhci_virt_ep {
> ...
> struct dma_pool *priv_seg_pool;
> }
>
> xhci-mem.c:
> xhci_endpoint_init()
> {
> struct dma_pool *pool;
> struct xhci_virt_ep *ep;
> ...
>
> ep = &virt_dev->eps[ep_index]
>
> /* use ep->priv_seg_pool if set by sideband or .add_endpoint wrapper */
> if (ep->priv_seg_pool)
> pool = ep->priv_seg_pool;
> else
> pool = xhci->segment_pool;
>
> xhci_ring_alloc_from_pool(..., pool);}
>
> xhci-sideband.c:
>
> xhci_sideband_add_endpoint(..., struct dma_pool *pool)
> {
> ...
> if (pool)
> ep->priv_seg_pool = pool;
> }
>
> This allows finer granularity in selecting dma pools for endpoints.
>
> It also keeps the xhci "core" sideband agnostic, avoids including xhci-
> sideband.h
> in xhci-mem.c
>
> It also helps possible vtio support so it can set its own ep->priv_seg_pool
> in a
> possible .add_endpint wrapper.
>
Hi Mathias,
Makes sense. I made the switch to adding it into the add_endpoint path and
its cleaner. I'll wait for a little bit for more reviews before submitting
the next revision.
Thanks
Wesley Cheng
prev parent reply other threads:[~2026-09-01 0:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 21:37 [PATCH v2 0/4] Add larger page size support for USB audio offload path Wesley Cheng
2026-08-28 21:37 ` [PATCH v2 1/4] xhci: sideband: fix ring sg table for sub-page TRB segments Wesley Cheng
2026-08-28 21:37 ` [PATCH v2 2/4] usb: xhci: sideband: allocate sideband ring segments from a dedicated pool Wesley Cheng
2026-08-28 21:37 ` [PATCH v2 3/4] ALSA: usb-audio: qcom: tag sideband endpoints before ring allocation Wesley Cheng
2026-08-28 21:37 ` [PATCH v2 4/4] ALSA: usb-audio: qcom: fix xfer ring IOMMU unmap on 16K+ page kernels Wesley Cheng
2026-08-31 13:04 ` [PATCH v2 0/4] Add larger page size support for USB audio offload path Mathias Nyman
2026-09-01 0:16 ` Wesley Cheng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0deb246b-0387-4921-b875-9477d73cdeed@oss.qualcomm.com \
--to=wesley.cheng@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=michal.pecio@gmail.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox