Re: [PATCH v1 1/4] ASoC: dt-bindings: qcom,q6apm-lpass-dais: Document DAI subnode

[Krzysztof Kozlowski <krzk@kernel.org>]

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