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

[Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>]

Hi Geert,

On Wed, Aug 05, 2026 at 02:02:42PM +0200, Geert Uytterhoeven wrote:
> Hi Tommaso,
> 
> On Wed, 5 Aug 2026 at 13:56, Tommaso Merciai
> <tommaso.merciai.xr@bp.renesas.com> wrote:
> > On Tue, Aug 04, 2026 at 08:20:29AM +0200, Krzysztof Kozlowski wrote:
> > > On 03/08/2026 19:19, Tommaso Merciai wrote:
> > > > Hi Krzysztof,
> > > > Thanks for your review.
> > > >
> > > > On Mon, Aug 03, 2026 at 03:32:48PM +0200, Krzysztof Kozlowski wrote:
> > > >> On 03/08/2026 15:28, Tommaso Merciai wrote:
> > > >>> r9a09g047e57-smarc.dts set clock-frequency for the audio_clkout output,
> > > >>> but the binding never declared it, so dtbs_check fails:
> > > >>>
> > > >>>   sound@13c00000 (renesas,r9a09g047-sound): Unevaluated properties
> > > >>>   are not allowed ('clock-frequency' was unexpected)
> > > >>
> > > >> Maybe the DTS is wrong, because property was rejected? Did you check
> > > >> this? You cannot document ABI post-factum if it was rejected.
> > > >>
> > > >>
> > > >>>
> > > >>> clock-cells is fixed to 0, so only a single audio_clkout applies.
> > > >>>
> > > >>> Fixes: a86fd3c20218 ("ASoC: dt-bindings: sound: Add DT binding for RZ/G3E sound")
> > > >>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > > >>> ---
> > > >>>  .../devicetree/bindings/sound/renesas,r9a09g047-sound.yaml     | 3 +++
> > > >>>  1 file changed, 3 insertions(+)
> > > >>>
> > > >>> diff --git a/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> > > >>> index d7fa16554698..6e2b2c93b4b7 100644
> > > >>> --- a/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> > > >>> +++ b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> > > >>> @@ -42,6 +42,9 @@ properties:
> > > >>>    "#clock-cells":
> > > >>>      const: 0
> > > >>>
> > > >>> +  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].
> >
> > 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.

Below is an example from arch/arm64/boot/dts/renesas/ulcb.dtsi. There
audio_clk_a is 22579200, a multiple of 44.1 kHz, and the audio_clk_b input
comes from the cs2000, which is set to 24576000, a multiple of 48 kHz.

The codec consuming AUDIO_CLKOUT needs 11289600 for the 44.1 kHz family
and 12288000 for the 48 kHz one, which is what clock-frequency describes.

Hence it is not a fixed rate clock.


From arch/arm64/boot/dts/renesas/ulcb.dtsi:
---
&audio_clk_a {
	clock-frequency = <22579200>;
};

cs2000: clock-controller@4f {
	clocks = <&audio_clkout>, <&x12_clk>;
	clock-names = "clk_in", "ref_clk";

	assigned-clocks = <&cs2000>;
	assigned-clock-rates = <24576000>;
};

ak4613: codec@10 {
	clocks = <&rcar_sound 3>;
};

&rcar_sound {
	pinctrl-0 = <&sound_pins>, <&sound_clk_pins>;
	pinctrl-names = "default";

	/* audio_clkout0/1/2/3 */
	#clock-cells = <1>;
	clock-frequency = <12288000 11289600>;

	status = "okay";

	/* update <audio_clk_b> to <cs2000> */
	clocks = <&cpg CPG_MOD 1005>,
		 <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
		 <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
		 <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
		 <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
		 <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
		 <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
		 <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
		 <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
		 <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
		 <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
		 <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
		 <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
		 <&audio_clk_a>, <&cs2000>,
		 <&audio_clk_c>,
		 <&cpg CPG_MOD 922>;
};


Kind regards,
Tommaso

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
>