Re: [PATCH 12/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: add LPASS CPU audio variant

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 4/8/26 11:47 AM, Xilin Wu wrote:
> On 4/8/2026 5:06 PM, Konrad Dybcio wrote:
>> On 4/7/26 5:20 PM, Xilin Wu wrote:
>>> Add a qcs6490-radxa-dragon-q6a-lpass-cpu.dts variant for debugging and
>>> bring-up of the host-controlled LPASS audio path on the Radxa Dragon
>>> Q6A.
>>>
>>> This variant enables the LPASS blocks and codec macros needed by the
>>> lpass-cpu driver, wires WCD9380 playback/capture and DisplayPort audio
>>> to the LPASS CDC DMA and DP interfaces, and disables remoteproc_adsp so
>>> that the audio hardware is owned directly by Linux.
>>>
>>> This DTB is an optional configuration for systems booted with the kernel
>>> running at EL2, where direct CPU access to the LPASS hardware is
>>> available. It is useful for users who need low-latency and fully
>>> controllable audio.
>>
>> I believe on Chrome platforms it was done this way because at some point
>> it was determined that they would specifically like not to use the DSP.
>>
>> I think this is more of a hack than anything else.. but at the end of the
>> commit message you mention low latency - is the impact actually measurable?
>>
> 
> Some of our users also specifically prefer not to use the DSP [1] :)
> 
> Based on their testing, the AudioReach/ADSP path imposes a minimum scheduling interval of 10 ms, which is much higher than the 0.67 ms they can get on a Raspberry Pi 5 with direct I2S/DMA.

We passed on this feedback.

> Since the lpass-cpu setup works properly, I would not consider this a hack.

Well yeah it works, but I was really hoping it would be made
unnecessary and available for removal sooner or later..

But since there's a genuine usecase, perhaps not.

Konrad