diff options
author | Nicolas Frattaroli <nicolas.frattaroli@collabora.com> | 2025-05-02 13:03:08 +0200 |
---|---|---|
committer | Heiko Stuebner <heiko@sntech.de> | 2025-05-05 22:39:24 +0200 |
commit | 70a114daf2077472e58b3cac23ba8998e35352f4 (patch) | |
tree | 6293c9ca08f034af5f318fe914ef95bcd37e93eb /scripts/lib/kdoc/kdoc_output.py | |
parent | 6657acc83c81d8edaa2a5ad4e38dfd716f892d53 (diff) |
clk: rockchip: introduce auxiliary GRFs
The MUXGRF clock branch type depends on having access to some sort of
GRF as a regmap to be registered. So far, we could easily get away with
only ever having one GRF stowed away in the context.
However, newer Rockchip SoCs, such as the RK3576, have several GRFs
which are relevant for clock purposes. It already depends on the pmu0
GRF for MUXGRF reasons, but could get away with not refactoring this
because it didn't need the sysgrf at all, so could overwrite the pointer
in the clock provider to the pmu0 grf regmap handle.
In preparation for needing to finally access more than one GRF per SoC,
let's untangle this. Introduce an auxiliary GRF hashmap, and a GRF type
enum. The hashmap is keyed by the enum, and clock branches now have a
struct member to store the value of that enum, which defaults to the
system GRF.
The SoC-specific _clk_init function can then insert pointers to GRF
regmaps into the hashmap based on the grf type.
During clock branch registration, we then pick the right GRF for each
branch from the hashmap if something other than the sys GRF is
requested.
The reason for doing it with this grf type indirection in the clock
branches is so that we don't need to define the MUXGRF branches in a
separate step, just to have a direct pointer to a regmap available
already.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250502-rk3576-sai-v3-2-376cef19dd7c@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_output.py')
0 files changed, 0 insertions, 0 deletions