Extend the qcom,q6apm-lpass-dais device tree binding to explicitly
describe Digital Audio Interface (DAI) child nodes.
Add #address-cells and #size-cells to allow representation of multiple
DAI instances as child nodes, and define a dai@<id> pattern to document
per-DAI properties such as the interface ID and associated clocks.
Qualcomm platforms like talos integrate third-party audio codecs or use
different external audio paths. These designs often require additional
configuration such as explicit MI2S MCLK settings for audio to work.
Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
---
.../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
index 2fb95544d..1d770cbcb 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
@@ -21,6 +21,34 @@ properties:
'#sound-dai-cells':
const: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+# Digital Audio Interfaces
+patternProperties:
+ '^dai@[0-9]+$':
+ type: object
+ description:
+ Q6DSP Digital Audio Interfaces.
+
+ properties:
+ reg:
+ description:
+ Digital Audio Interface ID
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ additionalProperties: false
+
required:
- compatible
- '#sound-dai-cells'
@@ -29,7 +57,18 @@ unevaluatedProperties: false
examples:
- |
- dais {
+ #include <dt-bindings/sound/qcom,q6afe.h>
+
+ bedais {
compatible = "qcom,q6apm-lpass-dais";
#sound-dai-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dai@16 {
+ reg = <PRIMARY_MI2S_RX>;
+ clocks = <&q6prmcc LPASS_CLK_ID_MCLK_1
+ LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "mclk";
+ };
};
--
2.34.1On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote:
> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly
> describe Digital Audio Interface (DAI) child nodes.
>
> Add #address-cells and #size-cells to allow representation of multiple
> DAI instances as child nodes, and define a dai@<id> pattern to document
> per-DAI properties such as the interface ID and associated clocks.
>
> Qualcomm platforms like talos integrate third-party audio codecs or use
> different external audio paths. These designs often require additional
> configuration such as explicit MI2S MCLK settings for audio to work.
>
> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> ---
> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
> index 2fb95544d..1d770cbcb 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
> @@ -21,6 +21,34 @@ properties:
> '#sound-dai-cells':
> const: 1
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +# Digital Audio Interfaces
> +patternProperties:
> + '^dai@[0-9]+$':
> + type: object
> + description:
> + Q6DSP Digital Audio Interfaces.
> +
> + properties:
> + reg:
> + description:
> + Digital Audio Interface ID
> +
> + clocks:
> + minItems: 1
> + maxItems: 3
> +
> + clock-names:
> + minItems: 1
> + maxItems: 3
No, this is just way too generic. There is no such syntax in the kernel
and this should stop you right there. You are not allowed to add your
own style.
I don't think DAI is here a separate device needing its own resources
expressed in DT. This is still part of ADSP so you just described in DT
internal routing between two services on ADSP.
> +
> + additionalProperties: false
> +
> required:
> - compatible
> - '#sound-dai-cells'
> @@ -29,7 +57,18 @@ unevaluatedProperties: false
>
> examples:
> - |
> - dais {
Why?
> + #include <dt-bindings/sound/qcom,q6afe.h>
> +
> + bedais {
> compatible = "qcom,q6apm-lpass-dais";
> #sound-dai-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dai@16 {
> + reg = <PRIMARY_MI2S_RX>;
> + clocks = <&q6prmcc LPASS_CLK_ID_MCLK_1
> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
So one entry, not three.
> + clock-names = "mclk";
> + };
> };
> --
> 2.34.1
>
On 3/10/2026 3:25 PM, Krzysztof Kozlowski wrote:
> On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote:
>> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly
>> describe Digital Audio Interface (DAI) child nodes.
>>
>> Add #address-cells and #size-cells to allow representation of multiple
>> DAI instances as child nodes, and define a dai@<id> pattern to document
>> per-DAI properties such as the interface ID and associated clocks.
>>
>> Qualcomm platforms like talos integrate third-party audio codecs or use
>> different external audio paths. These designs often require additional
>> configuration such as explicit MI2S MCLK settings for audio to work.
>>
>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
>> ---
>> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++-
>> 1 file changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>> index 2fb95544d..1d770cbcb 100644
>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>> @@ -21,6 +21,34 @@ properties:
>> '#sound-dai-cells':
>> const: 1
>>
>> + '#address-cells':
>> + const: 1
>> +
>> + '#size-cells':
>> + const: 0
>> +
>> +# Digital Audio Interfaces
>> +patternProperties:
>> + '^dai@[0-9]+$':
>> + type: object
>> + description:
>> + Q6DSP Digital Audio Interfaces.
>> +
>> + properties:
>> + reg:
>> + description:
>> + Digital Audio Interface ID
>> +
>> + clocks:
>> + minItems: 1
>> + maxItems: 3
>> +
>> + clock-names:
>> + minItems: 1
>> + maxItems: 3
>
> No, this is just way too generic. There is no such syntax in the kernel
> and this should stop you right there. You are not allowed to add your
> own style.
>
> I don't think DAI is here a separate device needing its own resources
> expressed in DT. This is still part of ADSP so you just described in DT
> internal routing between two services on ADSP.
>
Thanks for reviewing.
I’d like to clarify that this is not intended to model the DAI as a
separate physical device or to describe internal ADSP routing.
Requirement is to allow the kernel to send clock‑voting requests to the
ADSP. LPASS MCLK routing is not enabled by default on the ADSP, so the
kernel must explicitly request the ADSP to enable the relevant LPASS
MCLKs, which is a real hardware control requirement.
These clocks are LPASS‑owned, and driving them via a third‑party codec
is not appropriate. The intent of adding clock capabilities at the DAI
level is to allow the kernel to associate LPASS clock votes with a
specific DAI instance during stream activity.
While the DAI itself is not a physical device, some DT representation is
required to describe per‑DAI LPASS clock requirements.
I’m open to considering alternative representations, but removing this
entirely would leave no generic way for the kernel to handle correct
LPASS MCLK voting.
>> +
>> + additionalProperties: false
>> +
>> required:
>> - compatible
>> - '#sound-dai-cells'
>> @@ -29,7 +57,18 @@ unevaluatedProperties: false
>>
>> examples:
>> - |
>> - dais {
>
> Why?
>
I renamed the example node to bedais to mirror the node naming used in
Actual DT (q6apmbedai: bedais { ... }).
However, I understand the binding does not require any specific node
name; only the compatible and required properties/child nodes matter.
The rename was done purely to align the actual DT node naming used in
practice and improve cross-referencing clarity.
>> + #include <dt-bindings/sound/qcom,q6afe.h>
>> +
>> + bedais {
>> compatible = "qcom,q6apm-lpass-dais";
>> #sound-dai-cells = <1>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + dai@16 {
>> + reg = <PRIMARY_MI2S_RX>;
>> + clocks = <&q6prmcc LPASS_CLK_ID_MCLK_1
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
>
> So one entry, not three.
>
ACK,
I will add three clock entries for better clarity.
Best Regards,
Rafi.
>> + clock-names = "mclk";
>> + };
>> };
>> --
>> 2.34.1
>>
On 17/03/2026 06:27, Mohammad Rafi Shaik wrote: > > > On 3/10/2026 3:25 PM, Krzysztof Kozlowski wrote: >> On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote: >>> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly >>> describe Digital Audio Interface (DAI) child nodes. >>> >>> Add #address-cells and #size-cells to allow representation of multiple >>> DAI instances as child nodes, and define a dai@<id> pattern to document >>> per-DAI properties such as the interface ID and associated clocks. >>> >>> Qualcomm platforms like talos integrate third-party audio codecs or use >>> different external audio paths. These designs often require additional >>> configuration such as explicit MI2S MCLK settings for audio to work. >>> >>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> >>> --- >>> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++- >>> 1 file changed, 40 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>> index 2fb95544d..1d770cbcb 100644 >>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>> @@ -21,6 +21,34 @@ properties: >>> '#sound-dai-cells': >>> const: 1 >>> >>> + '#address-cells': >>> + const: 1 >>> + >>> + '#size-cells': >>> + const: 0 >>> + >>> +# Digital Audio Interfaces >>> +patternProperties: >>> + '^dai@[0-9]+$': >>> + type: object >>> + description: >>> + Q6DSP Digital Audio Interfaces. >>> + >>> + properties: >>> + reg: >>> + description: >>> + Digital Audio Interface ID >>> + >>> + clocks: >>> + minItems: 1 >>> + maxItems: 3 >>> + >>> + clock-names: >>> + minItems: 1 >>> + maxItems: 3 >> >> No, this is just way too generic. There is no such syntax in the kernel >> and this should stop you right there. You are not allowed to add your >> own style. >> >> I don't think DAI is here a separate device needing its own resources >> expressed in DT. This is still part of ADSP so you just described in DT >> internal routing between two services on ADSP. >> > > Thanks for reviewing. > > I’d like to clarify that this is not intended to model the DAI as a > separate physical device or to describe internal ADSP routing. If you do not want to represent the physical device, then I don't think it should be represented at all. > > Requirement is to allow the kernel to send clock‑voting requests to the > ADSP. LPASS MCLK routing is not enabled by default on the ADSP, so the > kernel must explicitly request the ADSP to enable the relevant LPASS > MCLKs, which is a real hardware control requirement. > > These clocks are LPASS‑owned, and driving them via a third‑party codec > is not appropriate. The intent of adding clock capabilities at the DAI > level is to allow the kernel to associate LPASS clock votes with a > specific DAI instance during stream activity. > > While the DAI itself is not a physical device, some DT representation is > required to describe per‑DAI LPASS clock requirements. DT's purpose is not to describe software constructs, thus DT is not the answer to your requirement of mapping clocks to specific DAI needs. Every person adding software properties made "some DT representation is required" claim. > > I’m open to considering alternative representations, but removing this > entirely would leave no generic way for the kernel to handle correct > LPASS MCLK voting. I imagine that, since this is software construct, the software knows which DAI needs which clock. Clocks are strictly defined, thus driver should handle all this. Best regards, Krzysztof
On 3/17/2026 12:41 PM, Krzysztof Kozlowski wrote: > On 17/03/2026 06:27, Mohammad Rafi Shaik wrote: >> >> >> On 3/10/2026 3:25 PM, Krzysztof Kozlowski wrote: >>> On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote: >>>> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly >>>> describe Digital Audio Interface (DAI) child nodes. >>>> >>>> Add #address-cells and #size-cells to allow representation of multiple >>>> DAI instances as child nodes, and define a dai@<id> pattern to document >>>> per-DAI properties such as the interface ID and associated clocks. >>>> >>>> Qualcomm platforms like talos integrate third-party audio codecs or use >>>> different external audio paths. These designs often require additional >>>> configuration such as explicit MI2S MCLK settings for audio to work. >>>> >>>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> >>>> --- >>>> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++- >>>> 1 file changed, 40 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>> index 2fb95544d..1d770cbcb 100644 >>>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>> @@ -21,6 +21,34 @@ properties: >>>> '#sound-dai-cells': >>>> const: 1 >>>> >>>> + '#address-cells': >>>> + const: 1 >>>> + >>>> + '#size-cells': >>>> + const: 0 >>>> + >>>> +# Digital Audio Interfaces >>>> +patternProperties: >>>> + '^dai@[0-9]+$': >>>> + type: object >>>> + description: >>>> + Q6DSP Digital Audio Interfaces. >>>> + >>>> + properties: >>>> + reg: >>>> + description: >>>> + Digital Audio Interface ID >>>> + >>>> + clocks: >>>> + minItems: 1 >>>> + maxItems: 3 >>>> + >>>> + clock-names: >>>> + minItems: 1 >>>> + maxItems: 3 >>> >>> No, this is just way too generic. There is no such syntax in the kernel >>> and this should stop you right there. You are not allowed to add your >>> own style. >>> >>> I don't think DAI is here a separate device needing its own resources >>> expressed in DT. This is still part of ADSP so you just described in DT >>> internal routing between two services on ADSP. >>> >> >> Thanks for reviewing. >> >> I’d like to clarify that this is not intended to model the DAI as a >> separate physical device or to describe internal ADSP routing. > > If you do not want to represent the physical device, then I don't think > it should be represented at all. > >> >> Requirement is to allow the kernel to send clock‑voting requests to the >> ADSP. LPASS MCLK routing is not enabled by default on the ADSP, so the >> kernel must explicitly request the ADSP to enable the relevant LPASS >> MCLKs, which is a real hardware control requirement. >> >> These clocks are LPASS‑owned, and driving them via a third‑party codec >> is not appropriate. The intent of adding clock capabilities at the DAI >> level is to allow the kernel to associate LPASS clock votes with a >> specific DAI instance during stream activity. >> >> While the DAI itself is not a physical device, some DT representation is >> required to describe per‑DAI LPASS clock requirements. > > DT's purpose is not to describe software constructs, thus DT is not the > answer to your requirement of mapping clocks to specific DAI needs. > Every person adding software properties made "some DT representation is > required" claim. > >> >> I’m open to considering alternative representations, but removing this >> entirely would leave no generic way for the kernel to handle correct >> LPASS MCLK voting. > > I imagine that, since this is software construct, the software knows > which DAI needs which clock. Clocks are strictly defined, thus driver > should handle all this. > No, the MCLK connection is not fixed to a specific DAI. The LPASS MCLKs LPASS_CLK_ID_MCLK_1 … LPASS_CLK_ID_MCLK_5 are hard‑wired connection, each physically routed to an external codec on the board. Because of this, the clock that must be voted depends purely on the hardware wiring, not on which DAI (Primary/Secondary/Tertiary/Quaternary MI2S) is used. In other words, DAI ↔ MCLK is not a fixed mapping. Examples: On Talos‑EVK, the speaker is connected via Primary MI2S, but the corresponding MCLK line wired to the codec is LPASS_CLK_ID_MCLK_2. On Kodiak, the customer connected an SGTL5000 codec via Quaternary MI2S, yet the required MCLK is still LPASS_CLK_ID_MCLK_2. Instead, the kernel must vote for the MCLK that is physically connected to the external codec on that specific board. Thanks & Regards, Rafi. > > Best regards, > Krzysztof
On 26/03/2026 10:57, Mohammad Rafi Shaik wrote: > > > On 3/17/2026 12:41 PM, Krzysztof Kozlowski wrote: >> On 17/03/2026 06:27, Mohammad Rafi Shaik wrote: >>> >>> >>> On 3/10/2026 3:25 PM, Krzysztof Kozlowski wrote: >>>> On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote: >>>>> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly >>>>> describe Digital Audio Interface (DAI) child nodes. >>>>> >>>>> Add #address-cells and #size-cells to allow representation of multiple >>>>> DAI instances as child nodes, and define a dai@<id> pattern to document >>>>> per-DAI properties such as the interface ID and associated clocks. >>>>> >>>>> Qualcomm platforms like talos integrate third-party audio codecs or use >>>>> different external audio paths. These designs often require additional >>>>> configuration such as explicit MI2S MCLK settings for audio to work. >>>>> >>>>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>>>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> >>>>> --- >>>>> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++- >>>>> 1 file changed, 40 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>>> index 2fb95544d..1d770cbcb 100644 >>>>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>>> @@ -21,6 +21,34 @@ properties: >>>>> '#sound-dai-cells': >>>>> const: 1 >>>>> >>>>> + '#address-cells': >>>>> + const: 1 >>>>> + >>>>> + '#size-cells': >>>>> + const: 0 >>>>> + >>>>> +# Digital Audio Interfaces >>>>> +patternProperties: >>>>> + '^dai@[0-9]+$': >>>>> + type: object >>>>> + description: >>>>> + Q6DSP Digital Audio Interfaces. >>>>> + >>>>> + properties: >>>>> + reg: >>>>> + description: >>>>> + Digital Audio Interface ID >>>>> + >>>>> + clocks: >>>>> + minItems: 1 >>>>> + maxItems: 3 >>>>> + >>>>> + clock-names: >>>>> + minItems: 1 >>>>> + maxItems: 3 >>>> >>>> No, this is just way too generic. There is no such syntax in the kernel >>>> and this should stop you right there. You are not allowed to add your >>>> own style. >>>> >>>> I don't think DAI is here a separate device needing its own resources >>>> expressed in DT. This is still part of ADSP so you just described in DT >>>> internal routing between two services on ADSP. >>>> >>> >>> Thanks for reviewing. >>> >>> I’d like to clarify that this is not intended to model the DAI as a >>> separate physical device or to describe internal ADSP routing. >> >> If you do not want to represent the physical device, then I don't think >> it should be represented at all. >> >>> >>> Requirement is to allow the kernel to send clock‑voting requests to the >>> ADSP. LPASS MCLK routing is not enabled by default on the ADSP, so the >>> kernel must explicitly request the ADSP to enable the relevant LPASS >>> MCLKs, which is a real hardware control requirement. >>> >>> These clocks are LPASS‑owned, and driving them via a third‑party codec >>> is not appropriate. The intent of adding clock capabilities at the DAI >>> level is to allow the kernel to associate LPASS clock votes with a >>> specific DAI instance during stream activity. >>> >>> While the DAI itself is not a physical device, some DT representation is >>> required to describe per‑DAI LPASS clock requirements. >> >> DT's purpose is not to describe software constructs, thus DT is not the >> answer to your requirement of mapping clocks to specific DAI needs. >> Every person adding software properties made "some DT representation is >> required" claim. >> >>> >>> I’m open to considering alternative representations, but removing this >>> entirely would leave no generic way for the kernel to handle correct >>> LPASS MCLK voting. >> >> I imagine that, since this is software construct, the software knows >> which DAI needs which clock. Clocks are strictly defined, thus driver >> should handle all this. >> > > No, the MCLK connection is not fixed to a specific DAI. > > The LPASS MCLKs > LPASS_CLK_ID_MCLK_1 … LPASS_CLK_ID_MCLK_5 > > are hard‑wired connection, each physically routed to an external codec > on the board. > > Because of this, the clock that must be voted depends purely on the > hardware wiring, not on which DAI (Primary/Secondary/Tertiary/Quaternary > MI2S) is used. If they are routed to external codecs, then they are already present in these nodes and duplicating them here is not necessary. > > In other words, DAI ↔ MCLK is not a fixed mapping. > > Examples: > On Talos‑EVK, the speaker is connected via Primary MI2S, but the > corresponding MCLK line wired to the codec is LPASS_CLK_ID_MCLK_2. > > On Kodiak, the customer connected an SGTL5000 codec via Quaternary MI2S, > yet the required MCLK is still LPASS_CLK_ID_MCLK_2. > > Instead, the kernel must vote for the MCLK that is physically connected > to the external codec on that specific board. No, the external codec driver must vote for that MCLK. Best regards, Krzysztof
On 3/26/2026 3:40 PM, Krzysztof Kozlowski wrote: > On 26/03/2026 10:57, Mohammad Rafi Shaik wrote: >> >> >> On 3/17/2026 12:41 PM, Krzysztof Kozlowski wrote: >>> On 17/03/2026 06:27, Mohammad Rafi Shaik wrote: >>>> >>>> >>>> On 3/10/2026 3:25 PM, Krzysztof Kozlowski wrote: >>>>> On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote: >>>>>> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly >>>>>> describe Digital Audio Interface (DAI) child nodes. >>>>>> >>>>>> Add #address-cells and #size-cells to allow representation of multiple >>>>>> DAI instances as child nodes, and define a dai@<id> pattern to document >>>>>> per-DAI properties such as the interface ID and associated clocks. >>>>>> >>>>>> Qualcomm platforms like talos integrate third-party audio codecs or use >>>>>> different external audio paths. These designs often require additional >>>>>> configuration such as explicit MI2S MCLK settings for audio to work. >>>>>> >>>>>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>>>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> >>>>>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> >>>>>> --- >>>>>> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++- >>>>>> 1 file changed, 40 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>>>> index 2fb95544d..1d770cbcb 100644 >>>>>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>>>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml >>>>>> @@ -21,6 +21,34 @@ properties: >>>>>> '#sound-dai-cells': >>>>>> const: 1 >>>>>> >>>>>> + '#address-cells': >>>>>> + const: 1 >>>>>> + >>>>>> + '#size-cells': >>>>>> + const: 0 >>>>>> + >>>>>> +# Digital Audio Interfaces >>>>>> +patternProperties: >>>>>> + '^dai@[0-9]+$': >>>>>> + type: object >>>>>> + description: >>>>>> + Q6DSP Digital Audio Interfaces. >>>>>> + >>>>>> + properties: >>>>>> + reg: >>>>>> + description: >>>>>> + Digital Audio Interface ID >>>>>> + >>>>>> + clocks: >>>>>> + minItems: 1 >>>>>> + maxItems: 3 >>>>>> + >>>>>> + clock-names: >>>>>> + minItems: 1 >>>>>> + maxItems: 3 >>>>> >>>>> No, this is just way too generic. There is no such syntax in the kernel >>>>> and this should stop you right there. You are not allowed to add your >>>>> own style. >>>>> >>>>> I don't think DAI is here a separate device needing its own resources >>>>> expressed in DT. This is still part of ADSP so you just described in DT >>>>> internal routing between two services on ADSP. >>>>> >>>> >>>> Thanks for reviewing. >>>> >>>> I’d like to clarify that this is not intended to model the DAI as a >>>> separate physical device or to describe internal ADSP routing. >>> >>> If you do not want to represent the physical device, then I don't think >>> it should be represented at all. >>> >>>> >>>> Requirement is to allow the kernel to send clock‑voting requests to the >>>> ADSP. LPASS MCLK routing is not enabled by default on the ADSP, so the >>>> kernel must explicitly request the ADSP to enable the relevant LPASS >>>> MCLKs, which is a real hardware control requirement. >>>> >>>> These clocks are LPASS‑owned, and driving them via a third‑party codec >>>> is not appropriate. The intent of adding clock capabilities at the DAI >>>> level is to allow the kernel to associate LPASS clock votes with a >>>> specific DAI instance during stream activity. >>>> >>>> While the DAI itself is not a physical device, some DT representation is >>>> required to describe per‑DAI LPASS clock requirements. >>> >>> DT's purpose is not to describe software constructs, thus DT is not the >>> answer to your requirement of mapping clocks to specific DAI needs. >>> Every person adding software properties made "some DT representation is >>> required" claim. >>> >>>> >>>> I’m open to considering alternative representations, but removing this >>>> entirely would leave no generic way for the kernel to handle correct >>>> LPASS MCLK voting. >>> >>> I imagine that, since this is software construct, the software knows >>> which DAI needs which clock. Clocks are strictly defined, thus driver >>> should handle all this. >>> >> >> No, the MCLK connection is not fixed to a specific DAI. >> >> The LPASS MCLKs >> LPASS_CLK_ID_MCLK_1 … LPASS_CLK_ID_MCLK_5 >> >> are hard‑wired connection, each physically routed to an external codec >> on the board. >> >> Because of this, the clock that must be voted depends purely on the >> hardware wiring, not on which DAI (Primary/Secondary/Tertiary/Quaternary >> MI2S) is used. > > If they are routed to external codecs, then they are already present in > these nodes and duplicating them here is not necessary. > >> >> In other words, DAI ↔ MCLK is not a fixed mapping. >> >> Examples: >> On Talos‑EVK, the speaker is connected via Primary MI2S, but the >> corresponding MCLK line wired to the codec is LPASS_CLK_ID_MCLK_2. >> >> On Kodiak, the customer connected an SGTL5000 codec via Quaternary MI2S, >> yet the required MCLK is still LPASS_CLK_ID_MCLK_2. >> >> Instead, the kernel must vote for the MCLK that is physically connected >> to the external codec on that specific board. > > No, the external codec driver must vote for that MCLK. > I agree that when the MCLK provider is external, it is appropriate for the codec driver to manage that clock. However, in this case the MCLK provider is the LPASS/DSP subsystem itself, and the external codec is only a consumer. LPASS MCLKs configurations inside the DSP can be lost or reprogrammed during DSP power collapse or subsystem restart (SSR). Without visibility into LPASS lifecycle(SSR) events, a third‑party codec driver cannot reliably perform clock voting or restoration, resulting in broken or inconsistent audio behavior. For these reasons, MCLK voting needs to remain owned by the LPASS/HLOS drivers, which have awareness of DSP power state and board wiring, Thanks & Regards, Rafi. > Best regards, > Krzysztof
On 27/03/2026 14:16, Mohammad Rafi Shaik wrote: >> >>> >>> In other words, DAI ↔ MCLK is not a fixed mapping. >>> >>> Examples: >>> On Talos‑EVK, the speaker is connected via Primary MI2S, but the >>> corresponding MCLK line wired to the codec is LPASS_CLK_ID_MCLK_2. >>> >>> On Kodiak, the customer connected an SGTL5000 codec via Quaternary MI2S, >>> yet the required MCLK is still LPASS_CLK_ID_MCLK_2. >>> >>> Instead, the kernel must vote for the MCLK that is physically connected >>> to the external codec on that specific board. >> >> No, the external codec driver must vote for that MCLK. >> > > I agree that when the MCLK provider is external, it is appropriate for > the codec driver to manage that clock. However, in this case the MCLK > provider is the LPASS/DSP subsystem itself, and the external codec is > only a consumer. > > LPASS MCLKs configurations inside the DSP can be lost or reprogrammed > during DSP power collapse or subsystem restart (SSR). > > Without visibility into LPASS lifecycle(SSR) events, a third‑party codec > driver cannot reliably perform clock voting or restoration, resulting in > broken or inconsistent audio behavior. > > For these reasons, MCLK voting needs to remain owned by the LPASS/HLOS > drivers, which have awareness of DSP power state and board wiring, Sounds like you just brought driver model as the arguments here, so not correct for DT. But even if we speak about drivers, then I think I also assumption that only clock consumer driver can manage the clock is not true. The provider, so LPASS/DSP knows what is happening with entire audio so it tracks the usage of its clocks and can perform clock disable/unprepare/prepare/restoration or whatever there is needed. Anyway, that's not important here. First argument is - you just wrote stuff for drivers and that we don't want. Best regards, Krzysztof
On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote:
> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly
> describe Digital Audio Interface (DAI) child nodes.
>
> Add #address-cells and #size-cells to allow representation of multiple
> DAI instances as child nodes, and define a dai@<id> pattern to document
> per-DAI properties such as the interface ID and associated clocks.
Is there a physical device being represented by this DAI subnode?
>
> Qualcomm platforms like talos integrate third-party audio codecs or use
> different external audio paths. These designs often require additional
> configuration such as explicit MI2S MCLK settings for audio to work.
>
> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> ---
> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
> index 2fb95544d..1d770cbcb 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
> @@ -21,6 +21,34 @@ properties:
> '#sound-dai-cells':
> const: 1
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +# Digital Audio Interfaces
> +patternProperties:
> + '^dai@[0-9]+$':
> + type: object
> + description:
> + Q6DSP Digital Audio Interfaces.
> +
> + properties:
> + reg:
> + description:
> + Digital Audio Interface ID
> +
> + clocks:
> + minItems: 1
> + maxItems: 3
> +
> + clock-names:
> + minItems: 1
> + maxItems: 3
> +
> + additionalProperties: false
> +
> required:
> - compatible
> - '#sound-dai-cells'
> @@ -29,7 +57,18 @@ unevaluatedProperties: false
>
> examples:
> - |
> - dais {
> + #include <dt-bindings/sound/qcom,q6afe.h>
> +
> + bedais {
> compatible = "qcom,q6apm-lpass-dais";
> #sound-dai-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dai@16 {
What is @16 in this case? What kind of address or ID correspondings to
the PRIMARY_MI2S_RX?
> + reg = <PRIMARY_MI2S_RX>;
> + clocks = <&q6prmcc LPASS_CLK_ID_MCLK_1
> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
> + clock-names = "mclk";
> + };
> };
> --
> 2.34.1
>
--
With best wishes
Dmitry
On 3/10/2026 1:25 AM, Dmitry Baryshkov wrote:
> On Mon, Mar 09, 2026 at 04:42:57PM +0530, Mohammad Rafi Shaik wrote:
>> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly
>> describe Digital Audio Interface (DAI) child nodes.
>>
>> Add #address-cells and #size-cells to allow representation of multiple
>> DAI instances as child nodes, and define a dai@<id> pattern to document
>> per-DAI properties such as the interface ID and associated clocks.
>
> Is there a physical device being represented by this DAI subnode?
>
No, the dai@<id> subnode does not represent a separate physical device.
It models an individual LPASS/Q6DSP DAI hw interface instance (for
example, primary mi2s, secondary mi2s, etc.), so that per‑DAI resources
and configuration can be described.
Per‑port description is required because different DAIs may need
different clock inputs (MCLK, BCLK, ECLK) and can be wired differently
depending on the board design. By representing each DAI instance as a
child node, the relevant clocks can be bound to the specific DAI port
that uses them.
Thus, the subnode is used to describe the resources and configuration of
a DAI hw instance, not a standalone physical device.
>>
>> Qualcomm platforms like talos integrate third-party audio codecs or use
>> different external audio paths. These designs often require additional
>> configuration such as explicit MI2S MCLK settings for audio to work.
>>
>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
>> ---
>> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 41 ++++++++++++++++++-
>> 1 file changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>> index 2fb95544d..1d770cbcb 100644
>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>> @@ -21,6 +21,34 @@ properties:
>> '#sound-dai-cells':
>> const: 1
>>
>> + '#address-cells':
>> + const: 1
>> +
>> + '#size-cells':
>> + const: 0
>> +
>> +# Digital Audio Interfaces
>> +patternProperties:
>> + '^dai@[0-9]+$':
>> + type: object
>> + description:
>> + Q6DSP Digital Audio Interfaces.
>> +
>> + properties:
>> + reg:
>> + description:
>> + Digital Audio Interface ID
>> +
>> + clocks:
>> + minItems: 1
>> + maxItems: 3
>> +
>> + clock-names:
>> + minItems: 1
>> + maxItems: 3
>> +
>> + additionalProperties: false
>> +
>> required:
>> - compatible
>> - '#sound-dai-cells'
>> @@ -29,7 +57,18 @@ unevaluatedProperties: false
>>
>> examples:
>> - |
>> - dais {
>> + #include <dt-bindings/sound/qcom,q6afe.h>
>> +
>> + bedais {
>> compatible = "qcom,q6apm-lpass-dais";
>> #sound-dai-cells = <1>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + dai@16 {
>
> What is @16 in this case? What kind of address or ID correspondings to
> the PRIMARY_MI2S_RX?
>
yes, The @16 value corresponds to the LPASS/Q6DSP DAI ID for
PRIMARY_MI2S_RX.
(defined in :
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h)
Best Regards,
Rafi.
>> + reg = <PRIMARY_MI2S_RX>;
>> + clocks = <&q6prmcc LPASS_CLK_ID_MCLK_1
>> + LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
>> + clock-names = "mclk";
>> + };
>> };
>> --
>> 2.34.1
>>
>
© 2016 - 2026 Red Hat, Inc.