linux-kernel - Re: [PATCH v35 00/31] Introduce QC USB SND audio offloading support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82ce69a3-d248-494f-6ddb-098f392c78a0@quicinc.com>
Date: Mon, 3 Mar 2025 18:39:52 -0800
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Stephan Gerhold <stephan.gerhold@...aro.org>,
        Greg KH
	<gregkh@...uxfoundation.org>
CC: <srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
        <perex@...ex.cz>, <conor+dt@...nel.org>, <dmitry.torokhov@...il.com>,
        <corbet@....net>, <broonie@...nel.org>, <lgirdwood@...il.com>,
        <tiwai@...e.com>, <krzk+dt@...nel.org>,
        <pierre-louis.bossart@...ux.intel.com>, <Thinh.Nguyen@...opsys.com>,
        <robh@...nel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-sound@...r.kernel.org>,
        <linux-input@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v35 00/31] Introduce QC USB SND audio offloading support



On 2/19/2025 3:24 AM, Stephan Gerhold wrote:
> On Tue, Feb 18, 2025 at 04:47:23PM -0800, Wesley Cheng wrote:
>> Requesting to see if we can get some Acked-By tags, and merge on usb-next.
>>
>> Several Qualcomm based chipsets can support USB audio offloading to a
>> dedicated audio DSP, which can take over issuing transfers to the USB
>> host controller.  The intention is to reduce the load on the main
>> processors in the SoC, and allow them to be placed into lower power modes.
>> There are several parts to this design:
>>   1. Adding ASoC binding layer
>>   2. Create a USB backend for Q6DSP
>>   3. Introduce XHCI interrupter support
>>   4. Create vendor ops for the USB SND driver
>>
>>       USB                          |            ASoC
>> --------------------------------------------------------------------
>>                                    |  _________________________
>>                                    | |sm8250 platform card     |
>>                                    | |_________________________|
>>                                    |         |           |
>>                                    |      ___V____   ____V____
>>                                    |     |Q6USB   | |Q6AFE    |  
>>                                    |     |"codec" | |"cpu"    |
>>                                    |     |________| |_________|
>>                                    |         ^  ^        ^
>>                                    |         |  |________|
>>                                    |      ___V____    |
>>                                    |     |SOC-USB |   |
>>    ________       ________               |        |   |
>>   |USB SND |<--->|QC offld|<------------>|________|   |
>>   |(card.c)|     |        |<----------                |
>>   |________|     |________|___     | |                |
>>       ^               ^       |    | |    ____________V_________
>>       |               |       |    | |   |APR/GLINK             |
>>    __ V_______________V_____  |    | |   |______________________|
>>   |USB SND (endpoint.c)     | |    | |              ^
>>   |_________________________| |    | |              |
>>               ^               |    | |   ___________V___________
>>               |               |    | |->|audio DSP              |
>>    ___________V_____________  |    |    |_______________________|
>>   |XHCI HCD                 |<-    |
>>   |_________________________|      |
>>
> 
> As I noted on v34 [1], this version is still missing instructions and
> changes needed for testing this series. The device tree changes don't
> need to be part of the same series, but there should be at least a link
> provided to give other people the chance to provide Tested-by tags.
> 
> IMO we shouldn't merge this series without those instructions, otherwise
> we risk that this just ends up being dead code that no one can use.
> 
> Can you please share the device tree changes for a board upstream and
> any other changes needed to be able to test this series? E.g. for
> sm8250-mtp.dts, based on the examples in your cover letter.
> 

Hi Stephan,

To clarify I'm testing this on sm8350 in recent times, but utilizing sm8250
definitions for the ASoC platform card, as the platform sound card is 
more or less the same between the two SoCs.  Back
when I started this series, sm8350 was missing a bunch of dependent
components, such as aDSP not being loaded, and missing platform sound card
definition, so I had to define and enable those on my own, which required a
slew of new DT nodes, hence why it wasn't as straight forward to include
the DT definitions yet for sm8350.  Not thinking that this series would
take as long as it did, I was planning on separating out the DT changes in
a different series to enable offloading for the devices I have tested with.
(sm8150, sm8250 and sm8350)

There's still a pretty big chunk of dependencies missing from sm8350, so
those would also be handled in the follow up DT submission.  For now, its a
much bigger hurdle to get the main/functional changes in, and that was
taking a significant amount of time from my end to manage.

If you want, I can give you the changes I have offline to enable this 
for sm8350, since I haven't spent time formatting/prepping the changes 
for submission yet.

Thanks
Wesley Cheng