On 11/20/25 21:38, Marek Vasut wrote:
> 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?
Hi Marek
I reworked drivers/clk/clk-stm32-core.c, clk-stm32mp13.c and clk-stm32mp25.c
and found
one additional issue in drivers/clk/clk_scmi.c.
The serie will be soon submitted on mailing list.
Thanks
Patrice
