On 12/15/25 9:44 AM, Patrice CHOTARD wrote:
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.
Thank you. Did you manage to submit it yet ?
