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@xxxxxxxxxxxxx> 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