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/24/26 9:07 PM, Val Packett wrote:
> 
> 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 :)

That's a genuine usecase, but probably not realistic (in the 'actually
zero closed blobs' sense) today, if you want to have a featureful and
stable system

Konrad