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

[Krzysztof Kozlowski <krzk@kernel.org>]

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