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

From: Val Packett

Date: Fri Apr 24 2026 - 15:11:21 EST


On 4/24/26 9:28 AM, Konrad Dybcio wrote:
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.

lpass-cpu is also great from a "I don't want my pure libre operating system to touch dirty proprietary binary blobs" perspective, but you can definitely argue that that's not a genuine use case :)

~val