Re: [PATCH 2/7] clk: rockchip: add support for GRF gated clocks

[Heiko Stuebner <heiko@sntech.de>]

Hey,

Am Mittwoch, 5. März 2025, 22:24:22 MEZ schrieb Nicolas Frattaroli:
> Certain Rockchip SoCs, the RK3576 in particular, have some clocks that
> are essentially gated behind an additional GRF write. Downstream uses an
> additional entirely separate clock driver that maps over the same
> address range as ioc_grf in the DT.
> 
> Instead, this implementation introduces a new gate type, GRF gates.
> These gates function quite like regular gates. In effect, this means
> they'll only be enabled if the clock is used, which I feel is a more
> appropriate way to describe this compared to doing it in, say, pinctrl,
> or even in the drivers of the respective clock consumers such as SAI.
> 
> It should be noted that RK3588 has similar GRF-gated clocks, but has
> gotten away with not having to deal with any of this because the clocks
> are ungated by the hardware's register reset value by default. The
> RK3576 is not so lucky, and the hardware's reset value gates them
> instead, which means we'll have to ungate them somewhere.
> 
> In order to facilitate the GRF gating on RK3576, we introduce the
> concept of auxiliary GRFs. The RK3576 has several defined GRF nodes, and
> so far it could get away with just using one for MUXGRF by reassigning
> the clock provider's grf member.
> 
> However, with the IOC GRF gated clocks, we now also need access to the
> IOC GRF, so we can't get away with this anymore. Instead, we add a
> hashtable to the clock provider struct, keyed by a grf type enum. The
> clock branches can then specify through the use of a new member of that
> enum's type (with corresponding changes to relevant macros) which GRF
> range they would like to use.
> 
> The SoC-specific clk_init can then populate the hashtable with the GRFs
> that it needs. This way, GRF-dependent clock branches don't have to be
> registered in a different step than everything else, as they would need
> to be had I extended the branch struct to instead take a pointer to a
> GRF, which isn't available at the time most of our branches are defined.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

I only did a short look through the patch and didn't see anything
glaringly wrong, but this wants to be at least 3 patches:
- add the handling (hash-table etc) for multiple grfs
  (including adapting the grf-mux)
- adding the grf-gate clock-type
- adding the rk3576 grf-gates


Heiko