On 10/11/26 12:00 PM, Jonas Karlman wrote:
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().
What I meant to say is that we should add this documentation to doc/
somewhere so *other* contributors know about these rules too. It's good
to have it written here so there's somewhere we can look at until we
have this written somewhere in the docs. I'm also not asking you to
write this documentation, just to be clear :)
Cheers,
Quentin
