Re: [PATCH 0/2] Add larger page size support for USB audio offload path

[Michal Pecio <michal.pecio@gmail.com>]

On Wed, 26 Aug 2026 00:50:53 -0700, Wesley Cheng wrote:
> Thanks for this suggestion.  I think it actually makes the overall
> design a lot better.  So now that the sideband driver has its own
> segment pool (per sideband instance), we expect that any page
> allocations done from this pool is technically owned by the audio
> DSP.  This allows us to still utilize 4k ring segments, while mapping
> the entire 16k page, so it helps conserve/optimize the memory
> allocations.  I will do a bit more testing and review before
> submitting a new revision w/ these changes.

The part about memory being "owned by the audio DSP" made me wonder
if it would be helpful to let offload drivers allocate their own memory
and then just dma_map() it for the xHC. No new rings would be allocated
for offloaded endpoints when they are enabled, we would point Endpoint
Context of the xHC to the sideband ring and leave ep->ring as NULL.

Offload drivers would have full control over memory allocation - size,
number of segments (it seems that qc-usb-audio only uses one out of two
allocated by xhci-hcd), alignment, anything else.

It would become impossible to offload an endpoint which is already
enabled, but is this an issue for anyone?

NULL ep->ring will cause oopses/panics when somebody submits URBs to
offloaded endpoints, but I think it wouldn't be a problem otherwise.

Regards,
Michal