From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 211683BE650 for ; Wed, 26 Aug 2026 10:25:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787739961; cv=none; b=VuN2LoUZujw6RUtctk02KVqXgBY4ghSvXJ7gvlFGoOMnPBvTsCHQrmB228lSCpgFaEqP7URBe95DOTowEfE+KETMxQdXzJ/da5nT/5g0aAVzXOCSy+iZZO32+GZ1U4g0SxglJO47pEKl5LqoJdipC6poT4tCni5R9h3dACdnAb8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787739961; c=relaxed/simple; bh=wEDTJJ7W8kiwxLRX1+enWo0Pl+M9+VeM0mUaKzfEPJQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=J/GCGhZjo27kTcmSKBJOuWtqK/j9knmF3A8EUsi7NzINBtEU+ztc6Amke0TFxplUax4jzzorjqd8Sep8nde1mLNZ3YdZdm5q5abh5qLoPf8vbCD2noZ7o6ZKTd0/LWq8eEskbAC9wIhtcv0xHuG29KE0rC6RSHIoy2/N9vyILjU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=L9AyZFMT; arc=none smtp.client-ip=209.85.218.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="L9AyZFMT" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-c2022323c37so96653566b.0 for ; Wed, 26 Aug 2026 03:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787739958; x=1788344758; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=7ZF4eI1OEh2v4DHesaWp67R2xMPuMRHeqkB4bC7uF/4=; b=L9AyZFMTPLVgsgN/QDMGCIjX76X9TyCv31wnNPTuF0SyjUO639QZDm+CiBFbYGFOZV mF7TmrWSh6Ryg554P/HOfzY76N8xLe2GXafJcXvApNBMHQHU5PLU5xTpgT5AeMf6Z4Oh Ch3pjhHOJ5GdOgpw+lA56jwB67U6uwxTrmfYPKVsee6odPrH2SCyaZMfUfAUVR7HmMnX Ucc7wAf6sGaUNlukYHxHbfKahV8GCD6+87pOCh/12Jdkfka6jKYyGnyS1Id5u6Uzs4A6 bKr8yNLi4HOTAfD2vqYZh04SW8VCEZhI9OgQddtPqqPXuXszXVLWl53pOiJhLwPlsI2Q NAQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787739958; x=1788344758; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7ZF4eI1OEh2v4DHesaWp67R2xMPuMRHeqkB4bC7uF/4=; b=S/LWsQ7/QdzI46uRxjMf1q596t93qlcx7Iq/eEGTsMjf1PuVqGwyQKmDWUQKVW37Zq BeWlB8jDLllFzavASd0V/uFhGK+2HYwOMhNgP0GdH7P3s0fZwgB5oxjCHlae7Z2Jfmsc vWZTUlBBZMTwnRGXHEdM5rJXjFqI/inDLLKlRdnuursYAARQYz8HZebBW8iFzlDRXsow NTPivEdQyq0wXBn6S54zrtL2nA2phys/OMlP3huZJn6rN4qQsMBkOjc96uQmRo5ge0io mA3TyUkgdSOV/nFINs39WvkI+XZLwuSuS1IEQv9rAuLcUOw2W5tMwhVZ4+BiE6Gf/dDi f3TQ== X-Forwarded-Encrypted: i=1; AHgh+RqjnmO3BzFgdutNW3fNgpwb8tbmHKVW18nIE4ZWSVGSdJrRj9RermzaW3cjNbof2T8oZjrus/MB5H5i5yk=@vger.kernel.org X-Gm-Message-State: AFuF++nibmLg+M9xso1o/EyzKJR5rw28k3e1R1xjucVYLWc66mKqN2rV gFxw47orvm2EG0Ku0DA/7tseQ9w2rOOXToxuXEVVNqzbhFYebLM11dhZ+dAASQ== X-Gm-Gg: AR+sD11Q8E070P5y6e1EPy6Hupi/plVZFmTYWUGe7XpC6VGkdsaviyxAArYsL95OuJ6 Krs+OVQUt04zkLsm4qcvVjkujaAqJkluP1dhcDAW71c0XtRPHFIT4v3ApVX1VUhA/qTzt99pxR2 a/M1iisH5slWdrRY6LRpH9hQ08z4/VsZpf1uIXuNmMXQIqadgdLSyURSI7nVe86PMEtVloB7lKE A217LnWu9W0PZ7F6m7FkFt2lZYcnAxY7he9xlTy1N6sB/i7T1XzXX0pzWvSGHcvKUtlFVTdxl7n GqOPRjOhgW+y7BVPwn7z/Bh/qwU5KaDkLd7Vn0xZsN1TZrRQ66sTkf2M/tr8ZCPuV5lWlzJSFes 8FtkLJqkFCVypcr87kIGe0Ol6RI9Oa8+JgWyZ0eu7zqVNRCtS25EJgiKErnd/etaOiTk/m3SsEp vg1A2I1aV1exf7/grRWK5yFjQRCC++6jRYS/ffEUurLmPPHLvYdLqNmU5S4dMc7czdzBA5cBFZB sjy9g== X-Received: by 2002:a17:906:478c:b0:c24:6505:8f67 with SMTP id a640c23a62f3a-c250bb556c2mr665876766b.10.1787739957750; Wed, 26 Aug 2026 03:25:57 -0700 (PDT) Received: from foxbook (bfk5.neoplus.adsl.tpnet.pl. [83.28.48.5]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c250dfd6e6asm307762866b.19.2026.08.26.03.25.56 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 26 Aug 2026 03:25:57 -0700 (PDT) Date: Wed, 26 Aug 2026 12:25:52 +0200 From: Michal Pecio To: Wesley Cheng Cc: Mathias Nyman , Greg Kroah-Hartman , Jaroslav Kysela , Takashi Iwai , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sound@vger.kernel.org Subject: Re: [PATCH 0/2] Add larger page size support for USB audio offload path Message-ID: <20260826122552.5761dea2.michal.pecio@gmail.com> In-Reply-To: <0bf654f3-51c5-4555-8cdd-dc9d25dd9f78@oss.qualcomm.com> References: <20260824-16k_offload_v1_b4-v1-0-49a6be60ca30@oss.qualcomm.com> <20260825094327.606072e9.michal.pecio@gmail.com> <25ebe180-a620-4170-92f7-fda6c55a4129@oss.qualcomm.com> <0bf654f3-51c5-4555-8cdd-dc9d25dd9f78@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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