Re: [PATCH 1/3] ASoC: dt-bindings: renesas,r9a09g047-sound: Document audio_clkout clock-frequency

[Krzysztof Kozlowski <krzk@kernel.org>]

On 05/08/2026 15:05, Tommaso Merciai wrote:
>>>>>>> +  clock-frequency:
>>>>>>> +    description: for audio_clkout
>>>>>>
>>>>>> Incomplete, missing type/ref, constraints.
>>>>>
>>>>> renesas,r9a09g047-sound is handled by sound/soc/renesas/rcar/core.c [1],
>>>>> and "clock-frequency" is read by rsnd_adg_get_clkout() [2]. The same
>>>>> property is already documented for R-Car in
>>>>> Documentation/devicetree/bindings/sound/renesas,rsnd.yaml [3].
>>>>
>>>> But was the property rejected? I am repeating myself...
>>>
>>> Looking into this further, I found that you already asked to drop this
>>> property during the v5 review [1].

So my review was applied to the bindings only and undocumented ABI came
in? Great, cannot stress how happy I am.


>>>
>>> Thanks for pointing it out.
>>>
>>> For context: the sound module contains an audio clock generator (ADG) which
>>> generates an output clock from the external audio clocks and outputs it in
>>> to the AUDIO_CLKOUT pin, that mostly supply master clock to codec.
>>>
>>> "clock-frequency" is array of the possible rates provided by
>>> AUDIO_CLKOUT to the codec master clock.
>>> Based on the playback rate it will request either 44.1kHz or 48kHz.
>>>
>>> I will drop "clock-frequency" property from r9a09g047e57-smarc.dts, where
>>> AUDIO_CLKOUT output pin is not wired.
>>>
>>> But for boards that populates AUDIO_CLKOUT we need this property,
>>> Could you suggest how to model this properly?
>>
>> Isn't this output the single clock output of the sound module's clock
>> provider (#clocks-cells = <0>)? Hence can't the consumer driver set
>> the clock rate?
> 
> Yes you are correct.
> 
>>
>> If the consumer driver cannot set the clock rate, but depends on a
>> fixed clock rate, it can configure this in DT using assigned-clocks
>> and assigned-clock-rates, right?
> 
> The clock driven on the AUDIO_CLKOUT pin does not have a fixed rate.
> Depending on the playback rate it is a multiple of either 44.1 kHz or
> 48 kHz.

So the playback rate of 44.1 sets one frequency and playback rate of 48
sets other. Feels pretty dynamic so job for the drivers? I miss the
point why drivers cannot request proper rate.


Best regards,
Krzysztof