Re: [PATCH 2/4] arm64: dts: qcom: agatti: add LPASS devices

From: Srinivas Kandagatla

Date: Sun Feb 22 2026 - 04:28:06 EST


On 2/10/26 10:16 AM, Konrad Dybcio wrote:
> On 2/9/26 3:24 PM, Srinivas Kandagatla wrote:
>> From: Alexey Klimov <alexey.klimov@xxxxxxxxxx>
>>
>> The rxmacro, txmacro, vamacro, soundwire nodes, lpass clock
>> controllers are required to support audio playback and
>> audio capture on sm6115 and its derivatives.
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@xxxxxxxxxx>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxxxxxxxx>
>> ---
>
> [...]
>
>> + rxmacro: codec@a600000 {
>> + compatible = "qcom,sm6115-lpass-rx-macro";
>> + reg = <0x0 0xa600000 0x0 0x1000>;
>> +
>> + clocks = <&q6afecc LPASS_CLK_ID_RX_CORE_MCLK
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> + <&q6afecc LPASS_CLK_ID_RX_CORE_NPL_MCLK
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> + <&q6afecc LPASS_HW_DCODEC_VOTE
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> + <&vamacro>;
>> + clock-names = "mclk",
>> + "npl",
>> + "dcodec",
>> + "fsgen";
>> + assigned-clocks = <&q6afecc LPASS_CLK_ID_RX_CORE_MCLK
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> + <&q6afecc LPASS_CLK_ID_RX_CORE_NPL_MCLK
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
>> + assigned-clock-rates = <22579200>,
>> + <22579200>;
>
> Is this necessary?
Not required tbh.
>
>> + #clock-cells = <0>;
>> + clock-output-names = "mclk";
>> + #sound-dai-cells = <1>;
>> + };
>> +
>> + swr1: soundwire@a610000 {
>> + compatible = "qcom,soundwire-v1.6.0";
>> + reg = <0x0 0x0a610000 0x0 0x2000>;
>
> Let's set size=0x10_000 (it's got that much reserved for it)
>
make;s sense
>> + interrupts = <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + clocks = <&rxmacro>;
>> + clock-names = "iface";
>> +
>> + resets = <&lpass_audiocc 0>;
>> + reset-names = "swr_audio_cgcr";
>> +
>> + label = "RX";
>> + qcom,din-ports = <0>;
>> + qcom,dout-ports = <5>;
>> +
>> + qcom,ports-sinterval-low = /bits/ 8 <0x03 0x1f 0x1f 0x07 0x00>;
>> + qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x01 0x00>;
>> + qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00>;
>> + qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff>;
>> + qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff>;
>> + qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff>;
>> + qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff>;
>> + qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0x00>;
>> + qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00>;
>> +
>> + status = "disabled";
>
> No need to disable, I think
Ok
>
>> +
>> + #sound-dai-cells = <1>;
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> + };
>> +
>> +
>> + txmacro: codec@a620000 {
>> + compatible = "qcom,sm6115-lpass-tx-macro";
>> + reg = <0x0 0x0a620000 0x0 0x1000>;
>> +
>> + clocks = <&q6afecc LPASS_CLK_ID_TX_CORE_MCLK
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> + <&q6afecc LPASS_CLK_ID_TX_CORE_NPL_MCLK
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> + <&q6afecc LPASS_HW_DCODEC_VOTE
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
>> + <&vamacro>;..
>
>> + #clock-cells = <0>;
>> + clock-output-names = "mclk";
>> + #sound-dai-cells = <1>;
>> + };
>> +
>> + lpass_audiocc: clock-controller@a6a9000 {
>> + compatible = "qcom,sm6115-lpassaudiocc";
>> + reg = <0x0 0x0a6a9000 0x0 0x1000>;
>
> This region is called 'LPASS_AUDIO_CSR' with the correct size and length
we should.

>
>
>> + #reset-cells = <1>;
>> + };
>> +
>> +
>> + swr0: soundwire@a740000 {
>> + compatible = "qcom,soundwire-v1.6.0";
>> + reg = <0x0 0x0a740000 0x0 0x2000>;
>
> sz=0x10_000
Yes, we can add full range.
>
>> + interrupts = <GIC_SPI 296 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&txmacro>;
>> + clock-names = "iface";
>> +
>> + resets = <&lpasscc 0>;
>> + reset-names = "swr_audio_cgcr";
>> +
>> + label = "VA_TX";
>> + qcom,din-ports = <3>;
>> + qcom,dout-ports = <0>;
>> +
>> + qcoze-cells = <0>;
>> + };
>> +
>> + lpasscc: clock-controller@a7ec000 {
>> + compatible = "qcom,sm6115-lpasscc";
>> + reg = <0x0 0x0a7ec000 0x0 0x1000>;
>
> This isn't quite right.. it's at LPASS_TCSR (0xa7e0000) + 0xc000
>
> Not sure if we're gonna need the rest of it in the future, but it may
> be smart to describe the whole thing.. Too bad I didn't know about it
> when I first submitted that driver...
Yes, the driver needs fixing, we do it correctly for sc8280xp

--srini
>
> Konrad