Re: [PATCH 1/3] ASoC: dt-bindings: renesas,r9a09g047-sound: Document audio_clkout clock-frequency
Tommaso Merciai <[email protected]> Wed, 5 Aug 2026 15:05:45 +0200
| Newsgroups | org.kernel.vger.linux-renesas-soc,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sound |
|---|---|
| Message-ID | <anM1KUoFC1ltRsje@tom-desktop> |
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 > <[email protected]> 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 <[email protected]> > > > >>> --- > > > >>> .../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 -- [email protected] > > 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 >