Re: [PATCH v5 1/3] ASoC: dt-bindings: qcom,q6apm-lpass-dais: Document DAI subnode
From: Krzysztof Kozlowski
Date: Thu Jul 16 2026 - 02:19:30 EST
On 15/07/2026 08:58, Mohammad Rafi Shaik wrote:
>
>
> On 7/15/2026 11:35 AM, Krzysztof Kozlowski wrote:
>> On Tue, Jul 14, 2026 at 08:22:48PM +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.
>>>
>>> On platforms such as Monaco and Lemans, third-party codecs are hardware
>>> wired to the SoC and do not always have an in-tree codec driver to manage
>>> their clocks. For these designs, clock line enablement must be driven
>>> from the platform side, and this series provides the necessary support
>>> for that.
>>>
>>> On QAIF-based platforms such as Shikra and Hawi, responsibility for voting
>>> I2S MCLK and BCLK has moved from the DSP to the kernel. This series
>>> introduces the required device tree binding support to represent and
>>> vote for these clocks from the kernel.
>>>
>>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxxxxxxxx>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxxxxxxxx>
>>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@xxxxxxxxxxxxxxxx>
>>> ---
>>> .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 89 +++++++++++++++++++
>>> 1 file changed, 89 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>>> index 2fb95544d..b37c62ccd 100644
>>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>>> @@ -21,6 +21,82 @@ properties:
>>> '#sound-dai-cells':
>>> const: 1
>>>
>>> + '#address-cells':
>>> + const: 1
>>> +
>>> + '#size-cells':
>>> + const: 0
>>> +
>>> +# Digital Audio Interfaces
>>> +patternProperties:
>>> + '^dai@[0-9a-f]+$':
>>> + type: object
>>> + description:
>>> + Q6DSP Digital Audio Interfaces.
>>> +
>>> + properties:
>>> + reg:
>>> + maxItems: 1
>>> + description:
>>> + Digital Audio Interface ID
>>> +
>>> + clocks:
>>> + minItems: 1
>>> + maxItems: 2
>>> + description: MI2S clocks (mclk, bclk and/or eclk).
>>> +
>>> + clock-names:
>>> + minItems: 1
>>> + maxItems: 2
>>> +
>>> + allOf:
>>> + - oneOf:
>>> + - properties:
>>
>> Please don't do such stuff. Did you find it somewhere? If yes, then
>> where - so we can remove it?
>>
>
> It was not copied from another binding.
>
> It was my attempt to model the valid clock combinations.
>
>> I gave you the close-to-exact syntax I expect. It was nothing like this.
>
> clocks:
> minItems: 1
> maxItems: 3
>
>
> clock-names:
> minItems: 1
> maxItems: 3
> items:
> enum:
> - mclk
> - bclk
> - eclk
But I did not wrote anything like that.
>
> The enum version does not enforce the positional relationship between
> clocks and clock-names,
So you do not use my code, but something completely different and does
not work, therefore you come up with another approach.
I don't know what to advise, but repeating myself seems pointless.
Previous review stays valid.
>
> which is why I tried the oneOf approach.
>
> My concern with the suggested syntax is that mclk is not mandatory for
> all platforms.
>
> For example, HAWI only requires bclk and does not use mclk, so requiring
> mclk as the first clock-name would reject valid DTs.
Luckily I did not require mclk as first, so I do not understand why you
refer to something like that.
Best regards,
Krzysztof