All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Sugar Zhang <sugar.zhang@rock-chips.com>,
	Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	kernel@collabora.com, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-sound@vger.kernel.org,
	Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Subject: Re: [PATCH v2 02/11] clk: rockchip: introduce auxiliary GRFs
Date: Thu, 01 May 2025 14:38:25 +0200	[thread overview]
Message-ID: <2240109.Mh6RI2rZIc@diego> (raw)
In-Reply-To: <20250410-rk3576-sai-v2-2-c64608346be3@collabora.com>

Hi Nicolas,

Am Donnerstag, 10. April 2025, 21:39:54 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> 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 hasmap 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>

like the concept and also implementation :-) .

> ---
>  drivers/clk/rockchip/clk-rk3328.c |  6 +++---
>  drivers/clk/rockchip/clk-rk3568.c |  2 +-
>  drivers/clk/rockchip/clk-rk3576.c | 32 ++++++++++++++++++++++----------

the only "hair in the soup" are some missing socs ;-) .

As you're changing the MUXGRF type, you should adapt all socs using it
please. Missing rk3288 and rv1126 it seems - ARM32, which may have helped
these slipping through.


Heiko




WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Sugar Zhang <sugar.zhang@rock-chips.com>,
	Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: devicetree@vger.kernel.org,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rockchip@lists.infradead.org, kernel@collabora.com,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 02/11] clk: rockchip: introduce auxiliary GRFs
Date: Thu, 01 May 2025 14:38:25 +0200	[thread overview]
Message-ID: <2240109.Mh6RI2rZIc@diego> (raw)
In-Reply-To: <20250410-rk3576-sai-v2-2-c64608346be3@collabora.com>

Hi Nicolas,

Am Donnerstag, 10. April 2025, 21:39:54 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> 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 hasmap 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>

like the concept and also implementation :-) .

> ---
>  drivers/clk/rockchip/clk-rk3328.c |  6 +++---
>  drivers/clk/rockchip/clk-rk3568.c |  2 +-
>  drivers/clk/rockchip/clk-rk3576.c | 32 ++++++++++++++++++++++----------

the only "hair in the soup" are some missing socs ;-) .

As you're changing the MUXGRF type, you should adapt all socs using it
please. Missing rk3288 and rv1126 it seems - ARM32, which may have helped
these slipping through.


Heiko



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-05-01 12:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-10 19:39 [PATCH v2 00/11] Add RK3576 SAI Audio Controller Support Nicolas Frattaroli
2025-04-10 19:39 ` Nicolas Frattaroli
2025-04-10 19:39 ` [PATCH v2 01/11] dt-bindings: clock: rk3576: add IOC gated clocks Nicolas Frattaroli
2025-04-10 19:39   ` Nicolas Frattaroli
2025-04-10 19:39 ` [PATCH v2 02/11] clk: rockchip: introduce auxiliary GRFs Nicolas Frattaroli
2025-04-10 19:39   ` Nicolas Frattaroli
2025-05-01 12:38   ` Heiko Stübner [this message]
2025-05-01 12:38     ` Heiko Stübner
2025-04-10 19:39 ` [PATCH v2 03/11] clk: rockchip: introduce GRF gates Nicolas Frattaroli
2025-04-10 19:39   ` Nicolas Frattaroli
2025-04-10 19:39 ` [PATCH v2 04/11] clk: rockchip: add GATE_GRFs for SAI MCLKOUT to rk3576 Nicolas Frattaroli
2025-04-10 19:39   ` Nicolas Frattaroli
2025-04-10 19:39 ` [PATCH v2 05/11] ASoC: dt-bindings: add schema for rockchip SAI controllers Nicolas Frattaroli
2025-04-10 19:39   ` Nicolas Frattaroli
2025-04-14  7:26   ` Krzysztof Kozlowski
2025-04-14  7:26     ` Krzysztof Kozlowski
2025-04-10 19:39 ` [PATCH v2 06/11] ASoC: rockchip: add Serial Audio Interface (SAI) driver Nicolas Frattaroli
2025-04-10 19:39   ` Nicolas Frattaroli
2025-04-10 19:39 ` [PATCH v2 07/11] arm64: dts: rockchip: Add RK3576 SAI nodes Nicolas Frattaroli
2025-04-10 19:39   ` Nicolas Frattaroli
2025-04-10 19:40 ` [PATCH v2 08/11] arm64: dts: rockchip: Add RK3576 HDMI audio Nicolas Frattaroli
2025-04-10 19:40   ` Nicolas Frattaroli
2025-04-10 19:40 ` [PATCH v2 09/11] arm64: dts: rockchip: Add analog audio on RK3576 Sige5 Nicolas Frattaroli
2025-04-10 19:40   ` Nicolas Frattaroli
2025-04-10 19:40 ` [PATCH v2 10/11] arm64: dts: rockchip: Enable HDMI audio on Sige5 Nicolas Frattaroli
2025-04-10 19:40   ` Nicolas Frattaroli
2025-04-10 19:40 ` [PATCH v2 11/11] arm64: defconfig: Enable Rockchip SAI Nicolas Frattaroli
2025-04-10 19:40   ` Nicolas Frattaroli
2025-04-23 13:49 ` (subset) [PATCH v2 00/11] Add RK3576 SAI Audio Controller Support Mark Brown
2025-04-23 13:49   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2240109.Mh6RI2rZIc@diego \
    --to=heiko@sntech.de \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=p.zabel@pengutronix.de \
    --cc=perex@perex.cz \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=sugar.zhang@rock-chips.com \
    --cc=tiwai@suse.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.