Re: [PATCH 1/7] dt-bindings: clock: Add Amlogic S7 SCMI clock IDs
From: Conor Dooley
Date: Mon Nov 09 2026 - 15:03:11 EST
On Mon, Nov 09, 2026 at 09:37:00AM +0100, Jerome Brunet wrote:
> On dim. 08 nov. 2026 at 23:21, Conor Dooley <conor@xxxxxxxxxx> wrote:
>
> > On Fri, Nov 06, 2026 at 09:30:24AM +0100, Carlo Caione wrote:
> >> The S7 firmware exposes clocks through SCMI, including sources needed
> >> by the other clock controllers.
> >>
> >> Define their identifiers so devicetree can reference these
> >> firmware-provided clocks.
> >
> > Are SCMI clock IDs actually suitable for being bindings? Can't the IDs
> > vary here between versions of the firmware?
> > They're also not a "made up" set of indexes, like traditional clocks
> > are, they're real numbers that come from some document akin to
> > interrupts that we do not have bindings for and no driver is likely to
> > reference these definitions either right?
>
> There is no such document available unfortunately. I'm not sure one
> exist to be honest.
The "document" in this case is the source code of the firmware then.
The info might not be printed in the TRM, but it is determined by
something, Carlo had to get the numbers from somewhere?
> Those IDs have been stable ... so far, but sure,
> a FW change could change them.
You'd need to be stupid I think to actually change them, but I'd never
put it past a vendor to do just that.
> The IDs are totally made up, in the very same way the other
> amlogic clock driver IDs are.
I doubt that though? If I decided to add 32 to each number here, so that
PWM_J was 48 and DDR_PHY_OSC was 32, the whole thing would fall apart
because the scmi clk driver would pass that down to the firmware, right?
Don't the scmi spec/binding require that the clock cell contains the ID
used by the scmi firmware to refer to that clock? The rpmi stuff works
like that, so I can only assume that scmi is identical in that regard.
Were these bindings, I can create any elaborate scheme for coming up
with what each number means, and that often happens because you have
PLLs, gates, muxes etc all sharing a sequential numbering scheme,
whereas here you must use the numbers from the version of the firmware
that's currently running.
> Providers and consumer just need a common
> reference to desginate clocks, this is it.
>
> >
> > Is something like this not more suitable for being included as a header
> > in the amlogic dts directory?
>
> If you think it is more appropriate to have them there, it is fine
> by me.
IMO all these SCMI/RPMI etc IDs are not suitable to be bindings
because they can change if the firmware changes.
>
> Carlo if you have to respin with this particular change on the DT side,
> feel free to add
>
> Acked-by: Jerome Brunet <jbrunet@xxxxxxxxxxxx>
>
> >
> >>
> >> Signed-off-by: Carlo Caione <ccaione@xxxxxxxxxxxx>
> >> ---
> >> include/dt-bindings/clock/amlogic,s7-scmi-clkc.h | 27 ++++++++++++++++++++++++
> >> 1 file changed, 27 insertions(+)
> >>
> >> diff --git a/include/dt-bindings/clock/amlogic,s7-scmi-clkc.h b/include/dt-bindings/clock/amlogic,s7-scmi-clkc.h
> >> new file mode 100644
> >> index 000000000000..10d7caa5d1e2
> >> --- /dev/null
> >> +++ b/include/dt-bindings/clock/amlogic,s7-scmi-clkc.h
> >> @@ -0,0 +1,27 @@
> >> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> >> +/*
> >> + * Copyright (c) 2026 BayLibre, SAS.
> >> + */
> >> +
> >> +#ifndef __AMLOGIC_S7_SCMI_CLKC_H
> >> +#define __AMLOGIC_S7_SCMI_CLKC_H
> >> +
> >> +#define CLKID_DDR_PHY_OSC 0
> >> +#define CLKID_USB1_PLL_OSC 1
> >> +#define CLKID_TOP_PLL_OSC 2
> >> +#define CLKID_HDMI_PLL_OSC 3
> >> +#define CLKID_USB0_PHY_PLL_OSC 4
> >> +#define CLKID_USB1_PHY_PLL_OSC 5
> >> +#define CLKID_USB0_PLL_OSC 6
> >> +#define CLKID_ETH_PLL_OSC 7
> >> +#define CLKID_ADC_PLL_OSC 8
> >> +#define CLKID_CPU_CLK 9
> >> +#define CLKID_DSU_CLK 10
> >> +#define CLKID_GP1_PLL 11
> >> +#define CLKID_ACLKM 12
> >> +#define CLKID_PWM_G 13
> >> +#define CLKID_PWM_H 14
> >> +#define CLKID_PWM_I 15
> >> +#define CLKID_PWM_J 16
> >> +
> >> +#endif /* __AMLOGIC_S7_SCMI_CLKC_H */
> >>
> >> --
> >> 2.56.0
> >>
>
> --
> Jerome
Attachment:
signature.asc
Description: PGP signature