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