On 12/12/25 16:36, Marek Vasut wrote:
> On 12/11/25 4:52 PM, Patrice Chotard wrote:
>> During clock's registration, clock's name are used to establish parent -
>> child relation. On STM32MP13, most of SCMI clocks are parent
>> clocks.
>>
>> Since commit fdb1bffe2827 ("clk: scmi: Postpone clock name resolution"),
>> all scmi clocks are named by default "scmi-%zu" until they are enabled,
>> it breaks clocks registration and boot process for STM32MP13 platforms.
>>
>> By resolving SCMI clocks before clocks registration, it solves the issue.
>>
>> Fixes: fdb1bffe2827 ("clk: scmi: Postpone clock name resolution")
>> Signed-off-by: Patrice Chotard <[email protected]>
>
> Shouldn't the relationship between RCC and SCMI clock be described in DT
> using "clock" property and phandles / clock cells ? Once that is in place,
> you should be able to resolve the parent clock using that relationship
> described in DT, without the need to explicitly do these SCMI calls in RCC
> driver.
Hi Marek
I was ready to upstream one implementation when Peng submitted its proposal.
Honestly, Peng Fan's proposal was seductive as it was simple and less prone to
regression.
But yes, everything is present in our DT to resolve the parent clock's name.
I will submit my implementation.
Patrice
