Message-ID: <4964374.GXAFRqVoOG@phil>
Date: Wed, 05 Mar 2025 23:21:12 +0100
From: Heiko Stuebner <heiko@...ech.de>
To: Michael Turquette <mturquette@...libre.com>,
 Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 Philipp Zabel <p.zabel@...gutronix.de>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Sugar Zhang <sugar.zhang@...k-chips.com>,
 Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>, kernel@...labora.com,
 linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org,
 Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Subject: Re: [PATCH 2/7] clk: rockchip: add support for GRF gated clocks

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@...labora.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

Powered by blists - more mailing lists