Hi Quentin, On 10/9/2026 10:10 AM, Quentin Schulz wrote: > Hi Jonas, > > On 8/4/26 11:44 PM, Jonas Karlman wrote: >> This series takes the initial steps to try and remove use of >> rockchip_get_clk() to get the clock device or rockchip_get_cru() to get >> the CRU base address at runtime for the Rockchip platform. >> >> This series is similar to the "rockchip: Remove unneeded syscon driver >> for RK35xx" [1] series, but focuses on CRU instead of GRF. >> >> The CRU base addresses are fixed and known at compile time, yet drivers >> keep trying to resolve them at runtime delaying some operations by >> several ms. >> > > I would rather use device tree whenever possible, instead of relying on > hardcoded constants. Considering the contexts in which > rockchip_get_cru() and rockchip_get_pmucru() are called (that is, in the > DRAM driver will eventually be called only in DM-less TPL so cannot rely > on DT being present to fetch CRU from it, and in the sysreset driver > which doesn't have a description in the device tree), this here is > acceptable to me as is. But we should think about documenting the > exceptions to the "please get the info from device tree and do not use > hardcoded addresses" rule. A problem for later :)
I agree, we should use values from device tree where possible and appropriate. And as mentioned in the other thread, my acceptable exceptions are CRU, RAM and arch_cpu_init()+board_debug_uart_init() in xPL. With main reason being that anything in TPL (dram init) may or may not have access to DT, DM or otherwise be size constrained. And in SPL typically because of consistency, e.g. code may be shared with TPL, or we may need to do some one-off thing for a specific SoC, e.g. disable JTAG in arch_cpu_init(). Regards, Jonas > > Cheers, > Quentin > >> In this initial part the RK3568 and RK3588 specific helpers are updated >> to use CRU base address constants, similar to the other RK35xx SoCs, and >> the rockchip_get_clk() helper is removed for all RK35xx SoCs. >> >> The changes included in this series have no intended behavior change for >> the affected RK35xx SoCs. >> >> A follow-up series will introduce a rockchip_sysreset_bind() helper that >> passes the CRU base address to the sysreset_rockchip driver, drops the >> call to rockchip_get_cru() along with implementing the get_status() ops. >> >> [1] https://patchwork.ozlabs.org/cover/2280781/ >> >> Jonas Karlman (10): >> rockchip: rk3588: Rename CRU_BASE to RK3588_CRU_BASE >> rockchip: rk3588: Use fixed CRU base address >> rockchip: rk3568: Use fixed CRU and PMU CRU base addresses >> clk: rockchip: rk3568: Use fixed PMU CRU base address for PLL access >> rockchip: rk3568: Remove unused rockchip_get_pmucru() helper >> rockchip: rk3568: Remove unused rockchip_get_clk() helper >> rockchip: rk3588: Remove unused rockchip_get_clk() helper >> rockchip: rk3576: Remove unused rockchip_get_clk() helper >> rockchip: rk3528: Remove unused rockchip_get_clk() helper >> rockchip: rk3506: Remove unused rockchip_get_clk() helper >> >> .../include/asm/arch-rockchip/cru_rk3568.h | 5 ++- >> .../include/asm/arch-rockchip/cru_rk3588.h | 2 +- >> arch/arm/mach-rockchip/rk3506/clk_rk3506.c | 8 +--- >> arch/arm/mach-rockchip/rk3528/clk_rk3528.c | 8 +--- >> arch/arm/mach-rockchip/rk3568/clk_rk3568.c | 44 +------------------ >> arch/arm/mach-rockchip/rk3576/clk_rk3576.c | 8 +--- >> arch/arm/mach-rockchip/rk3588/clk_rk3588.c | 23 +--------- >> .../jaguar_rk3588/jaguar_rk3588.c | 2 +- >> .../tiger_rk3588/tiger_rk3588.c | 2 +- >> drivers/clk/rockchip/clk_rk3568.c | 34 +++----------- >> 10 files changed, 18 insertions(+), 118 deletions(-) >> >
