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

[Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>]

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