From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 013403E5EDC for ; Fri, 24 Apr 2026 19:08:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777057702; cv=none; b=TY5uakm4OOXW4kyMtn9A/vsNKKyuh9nNHCTPFUPSLUfWJ0lulnyLCzdKCwbrb+eJgaiDtAReNlFPDqbcd8uX6ugiAyGQ0qxyF9uYrEwWT3q7qk+U1InM23xGUg/ejuqxKm4VGHIvqfggqme/KcLv9eK81v5T8mCBeOaD2Cm2PfM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777057702; c=relaxed/simple; bh=8A6x/gwvigokDWQHjH1XTTPUpJb98Mhg/r0z4VARm4Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pdaHv0TegBu1aoPULuJCUIVw40yOT7eNLwXON1k//NaC6urg4QgjNrHGNbcWSiaeIdjqxR9Iy7QWFW0Bwnnvy39zHsMHyL7AGNRsqgof8VhMNJhFvcUA455Qn5u09o1n3z1WL1othEE21DZQIsmYRStu+XW34k5eaWIlCzDktx4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=nnt1cmrY; arc=none smtp.client-ip=95.215.58.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="nnt1cmrY" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1777057689; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Q7AY28qlHBjgzfWhhXsEAsuWHcEKhugX23O64AEQqA=; b=nnt1cmrYKgqViG1liVRq6/0f4EejzGYfXen3cebO9qtTfbXXcCQm7vSo3J/ezkwa1y1Huj yuEhv5AQt9otPdCsyU5Si1H+ksvzqUjbHms01qDdVFCGwSYpnMkJQ5N8epX1tab+xAO4/G vz0B/vHMxyRIHTeAxHIvhXQD/5e2r3gy/cVkFvTUbSqwfMeUKqL4bIgfYr1vFyVfTWGLb1 FOwQHBlzAxLRyq4Pho8rDP6u2W1W42Yf6R5Op7z9JzR/sM2fZLT3XWXfKQTxjk4rJ1uNZz tXuapn2aXf9bId8MCU6aT1JfKrUHgu0GpKyNf/R0irr3cfRjvi4KIR+j5BMtXg== Date: Fri, 24 Apr 2026 16:07:56 -0300 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 12/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: add LPASS CPU audio variant To: Konrad Dybcio , Xilin Wu , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Dmitry Baryshkov , Liam Girdwood , Mark Brown , Judy Hsiao , Srinivas Kandagatla Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-sound@vger.kernel.org References: <20260407-dragon-q6a-feat-fixes-v1-0-14aca49dde3d@radxa.com> <20260407-dragon-q6a-feat-fixes-v1-12-14aca49dde3d@radxa.com> <29a7dd01-7513-4fe5-8546-d57757b3b2d0@oss.qualcomm.com> <88B7BBB9133FBAD1+ccb025ea-4999-4701-bb18-c57a42cabe2f@radxa.com> <2f830f17-4bc5-4ebd-a66b-8068a14a871a@oss.qualcomm.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: <2f830f17-4bc5-4ebd-a66b-8068a14a871a@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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