On 1/30/24 17:47, Sebastian Reichel wrote: > Hi Dmitry, > > On Fri, Jan 26, 2024 at 10:36:13PM +0300, Dmitry Osipenko wrote: >> On 1/26/24 21:18, Sebastian Reichel wrote: >>> Recent Rockchip SoCs have a new hardware block called Native Interface >>> Unit (NIU), which gates clocks to devices behind them. These effectively >>> need two parent clocks. >>> >>> GATE_LINK type clocks handle the second parent via 'linkedclk' by using >>> runtime PM clocks. To make that possible a new platform device is created >>> for every clock handled in this way. >>> >>> Note, that before this patch clk_rk3588_probe() has never been called, >>> because CLK_OF_DECLARE marks the DT node as processed. This patch replaces >>> that with CLK_OF_DECLARE_DRIVER and thus the probe function is used now. >>> This is necessary to have 'struct device' available. >>> >>> Also instead of builtin_platform_driver_probe, the driver has been >>> switched to use core_initcall, since it should be fully probed before >>> the Rockchip PM domain driver (and that is using postcore_initcall). >> >> Why clk driver needs to be fully probed before PD? The PD driver >> shouldn't probe until all clk providers that it uses are registered, and >> then both clk and PD should be registered at the default level. > > The error handling in the rockchip PD driver needs rework to > properly handle -EPROBE_DEFER, which I consider a separate series. > > Note, that the driver currently has 'builtin_platform_driver_probe', > but does not actually probe anything. All clocks are registered via > CLK_OF_DECLARE, which happens even before core_initcall. So this > does not make things worse. > > Also the OF node is marked as initialized by the early clocks > (CLK_OF_DECLARE_DRIVER) via the call to of_clk_add_provider(). This > is necessary, since otherwise the early clocks cannot be referenced > and we need the early clocks for the timer registration (so it's not > possible to move all the clocks to late init). This effectively > results in fw_devlink not working properly. It will tell PM domain > driver too early, that it may start probing (so a bunch of useless > -EPROBE_DEFER will happen). Thanks for the clarification! Definitely will be good to improve the probe defer handling in the future. And indeed, it can be done separately from this patchset. -- Best regards, Dmitry
