On 11/17/25 5:36 PM, Patrice CHOTARD wrote:
Hello Patrice,
On 11/15/25 00:08, Marek Vasut wrote:
On 11/14/25 4:41 PM, Patrice Chotard wrote:
Since commit fdb1bffe2827 ("clk: scmi: Postpone clock name resolution"),
all clocks which are parent clocks are name "scmi-%zu" which
leads to error during their children clocks registration.
In order to not cancel boot time optimization done in
commit 3547e315c188 ("clk: scmi: Defer issue of SCMI_CLOCK_ATTRIBUTES"),
choice has been done to re-introduce scmi_clk_get_attribute() call
during scmi_clk_probe() under new CLK_SCMI_FORCE_ATTRIBUTE flag.
This restores boot on stm32mp13 and stm32mp2 family boards.
Fixes: fdb1bffe2827 ("clk: scmi: Postpone clock name resolution")
SCMI spec says that clock IDs have to be monotonic and incrementing, without
gaps . This driver registers all SCMI clock for you exactly this way. What
exactly is the problem on STM32 ? Are you maybe missing some reparenting
somewhere else ? Maybe the clock parent resolution should happen when the clock
are first used, just like attributes are now resolved when the clock are first
used ?
Hi Marek
Initially, on STM32 we first registered SCMI clocks with their real names and
then we registered all RCC clocks
in stm32_rcc_init(). For most of these latter clocks, their parent are SCMI
clocks.
After commit fdb1bffe2827 ("clk: scmi: Postpone clock name resolution"), the name of
these SCMI "parent" clocks
becames "scmi-%zu" which makes clk_register() failed as we still try to register RCC
clocks using their parent's "real names".
For example: for STM32MP13, clock "ck_hse" becames "scmi-0", so all clocks which are
"ck_hse"'s child can't be registered.
I don't think any clock driver can depend on SCMI clock shortnames for
clock look up, because the SCMI clock shortnames are an optional hint.
Instead, if some clock registered in this RCC driver have SCMI parent
clock, those SCMI parent clock have to be referred to by SCMI clock
udevice and matching clock identifier (in this case, I assume that would
be SCMI clock ID).
The relationship between this RCC clock and SCMI parent clock can likely
be described in DT using 'clocks = <&scmi_clk N>' , which you already
have in stm32mp131.dtsi:
788 clock-names = "hse", "hsi", "csi", "lse",
"lsi";
789 clocks = <&scmi_clk CK_SCMI_HSE>,
790 <&scmi_clk CK_SCMI_HSI>,
791 <&scmi_clk CK_SCMI_CSI>,
792 <&scmi_clk CK_SCMI_LSE>,
793 <&scmi_clk CK_SCMI_LSI>;
Can you use that for the parent lookup and simply ignore the shortnames?
