Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Brian Masney" <bmasney+clk@redhat.com>,
	"Jerome Brunet" <jbrunet+clk@baylibre.com>,
	"Ulf Hansson" <ulfh@kernel.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Marek Vasut" <marek.vasut+renesas@mailbox.org>,
	"Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>,
	"Konrad Dybcio" <konrad.dybcio@oss.qualcomm.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
	"Clément Le Goffic" <clegoffic@baylibre.com>,
	"Sudeep Holla" <sudeep.holla@kernel.org>,
	"Cristian Marussi" <cristian.marussi@arm.com>,
	arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v4 1/8] clk: renesas: r8a78000: Add clk_hw to clk_map
Date: Mon, 19 Oct 2026 19:14:36 +0300	[thread overview]
Message-ID: <20261019161436.GD3705@killaraus.ideasonboard.com> (raw)
In-Reply-To: <20261019152203.GA5830@killaraus.ideasonboard.com>

On Mon, Oct 19, 2026 at 06:22:04PM +0300, Laurent Pinchart wrote:
> On Mon, Oct 19, 2026 at 04:56:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, 19 Oct 2026 at 16:42, Laurent Pinchart wrote:
> > > On Fri, Oct 16, 2026 at 05:55:40PM +0200, Geert Uytterhoeven wrote:
> > > > Prepare for mapping to other than fixed-rate clocks by adding a clk_hw
> > > > pointer to the clk_map structure, and populating it up-front.
> > > >
> > > > Move r8a78000_cpg_priv.fixed_hws into fill_clk_map(), as it is no longer
> > > > needed afterwards, and drop NUM_FIXED_CLKS.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > 
> > > > --- a/drivers/clk/renesas/r8a78000-cpg.c
> > > > +++ b/drivers/clk/renesas/r8a78000-cpg.c
> > > > @@ -16,19 +16,24 @@
> > > >
> > > >  #include <dt-bindings/clock/renesas,r8a78000-cpg.h>
> > > >
> > > > +struct clk_map_in {
> > >
> > > The "_in" suffix isn't very explicit.
> > 
> > I can add a comment...
> 
> How about calling it clk_id_map ?
> 
> > > > +     int dt_id;              /* DT binding clock ID or -1 sentinel */
> > > > +     u32 fw_id;              /* FIXED_CLK() ID */
> > > > +};
> > > > +
> > > >  struct clk_map {
> > > >       int dt_id;              /* DT binding clock ID or -1 sentinel */
> > > >       u32 fw_id;              /* FIXED_CLK() ID */
> > 
> > BTW, do you think it would be worthwhile to reuse clk_map_in here?
> 
> Possibly. I was about to recommend just using a single structure and
> leaving the clk_hw pointer NULL and unused in .rodata, but the memory
> waste isn't very nice, especially if we end up with many entries :-(

Actually, you could even turns clk_map into

struct clk_map {
	const struct clk_id_map *map;
	struct clk_hw *hw;
};

It should consume the same amount of space on 64-bit platforms. Doing
the same in the MDLC driver would save space.

Or, if you want to save more memory, you could drop clk_map and store
the clk_hw in a separate array in r8a78000_cpg_priv, using the same
indices as clk_map_id.

struct r8a78000_cpg_priv {
	struct device *dev;

	const struct clk_id_map *map;
	unsigned int num_map_entries;
	struct clk_hw **clks;

	struct clk_hw *fixed_hws[NUM_FIXED_CLKS];
};

where clks is a dynamically-allocated array fo struct clk_hw pointers,
having the same size as the map array.

Too many options.

> > > > +     struct clk_hw *hw;
> > > >  };
> > 
> > > > @@ -92,35 +94,69 @@ static struct clk_hw *r8a78000_clk_get(struct of_phandle_args *spec,
> > > >       return hw;
> > > >  }
> > > >
> > > > -static int register_fixed_clks(struct r8a78000_cpg_priv *priv)
> > > > +static struct clk_hw **register_fixed_clks(struct device *dev)
> > > >  {
> > > > -     struct device *dev = priv->dev;
> > > > +     unsigned int n = ARRAY_SIZE(fixed_clk_rates);
> > > > +     struct clk_hw **hws, *hw;
> > > >       unsigned long rate;
> > > > -     struct clk_hw *hw;
> > > >       const char *name;
> > > >
> > > > -     for (unsigned int i = 0; i < ARRAY_SIZE(fixed_clk_rates); i++) {
> > > > +     hws = devm_kcalloc(dev, n, sizeof(*hws), GFP_KERNEL);
> > > > +     if (!hws)
> > > > +             return ERR_PTR(-ENOMEM);
> > > > +
> > > > +     for (unsigned int i = 0; i < n; i++) {
> > > >               rate = fixed_clk_rates[i];
> > > >               name = devm_kasprintf(dev, GFP_KERNEL, "cpg-%lu", rate);
> > > >               if (!name)
> > > > -                     return -ENOMEM;
> > > > +                     return ERR_PTR(-ENOMEM);
> > > >
> > > >               hw = devm_clk_hw_register_fixed_rate(dev, name, NULL, 0, rate);
> > > >               if (IS_ERR(hw))
> > > > -                     return PTR_ERR(hw);
> > > > +                     return ERR_CAST(hw);
> > > >
> > > > -             priv->fixed_hws[i] = hw;
> > > > +             hws[i] = hw;
> > > >       }
> > > >
> > > > -     return 0;
> > > > +     return hws;
> > > > +}
> > > > +
> > > > +static const struct clk_map *fill_clk_map(struct r8a78000_cpg_priv *priv,
> > > > +                                       const struct clk_map_in *map_in)
> > > > +{
> > > > +     struct device *dev = priv->dev;
> > > > +     struct clk_hw **fixed_hws;
> > > > +     struct clk_map *map;
> > > > +     unsigned int i;
> > > > +
> > > > +     fixed_hws = register_fixed_clks(dev);
> > > > +     if (IS_ERR(fixed_hws))
> > > > +             return ERR_CAST(fixed_hws);
> > > > +
> > > > +     for (i = 0; map_in[i].dt_id >= 0; i++) { }
> > >
> > > This is avoidable by passing { map, ARRAY_SIZE(map) } as match data
> > > instead of just the map.
> > 
> > True, and I did consider this.
> > The same mechanism is used in the MDLC driver, where using ARRAY_SIZE()
> > would quickly became a bigger burden due to the presence of many
> > more maps.  So for consistency, I kept it the same in both drivers.
> > An initialization macro might make it more manageable, though.
> 
> Something along the line of the following ?
> 
> struct clk_map_in_entry {
> 	int dt_id;		/* DT binding clock ID or -1 sentinel */
> 	u32 fw_id;		/* SCMI firmware clock ID or FIXED_CLK() ID */
> };
> 
> struct clk_map_in {
> 	const struct clk_map_in_entry *entries;
> 	unsigned int size;
> };
> 
> #define CPG_MAP_INIT(_entries) {	\
> 	.entries = _entries,		\
> 	.size = ARRAY_SIZE(_entries),	\
> }
> 
> struct cpg_data {
> 	const struct clk_map_in *default_map;
> 	const struct clk_map_in *fw_map;
> };
> 
> ...
> 
> static const struct clk_map_in_entries r8a78000_cpg_fw_entries[] = {
> 	{ R8A78000_CPG_SGASYNCD4_PERW_BUS,	1661 },
> 	{ R8A78000_CPG_SGASYNCD8_PERW_BUS,	1662 },
> 	{ R8A78000_CPG_SGASYNCD16_PERW_BUS,	1663 },
> 	{ R8A78000_CPG_MSO_SCP_MAIN,		1459 },
> 	{ R8A78000_CPG_MSOCK_PERW_BUS,		1667 },
> };
> 
> static const clk_map_in r8a78000_cpg_fw = CPG_MAP_INIT(r8a78000_cpg_fw_entries);
> 
> static const struct cpg_data r8a78000_cpg_data = {
> 	.default_map = r8a78000_cpg_default,
> 	.fw_map = r8a78000_cpg_fw,
> };
> 
> > > > +
> > > > +     map = devm_kcalloc(dev, i + 1, sizeof(*map), GFP_KERNEL);
> > > > +     if (!map)
> > > > +             return ERR_PTR(-ENOMEM);
> > > > +
> > > > +     for (i = 0; ; i++) {
> > > > +             map[i].dt_id = map_in[i].dt_id;
> > > > +             if (map[i].dt_id < 0)
> > > > +                     break;
> > > > +
> > > > +             map[i].fw_id = map_in[i].fw_id;
> > > > +             map[i].hw = fixed_hws[map[i].fw_id];
> > > > +     }
> > > > +
> > > > +     devm_kfree(dev, fixed_hws);
> > >
> > > Why not plain kcalloc/kfree ?
> > 
> > To avoid having to free it manually at multiple (three) locations,
> > both in the error paths and the success path?
> 
> Isn't __free() your friend ?
> 
> > >
> > > > +     return map;
> > > >  }

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2026-10-19 16:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 15:55 [PATCH v4 0/8] R-Car X5H Ironhide CPG/MDLC SCMI remapping support Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 1/8] clk: renesas: r8a78000: Add clk_hw to clk_map Geert Uytterhoeven
2026-10-17 17:28   ` Marek Vasut
2026-10-18 13:51     ` Geert Uytterhoeven
2026-10-18 14:04       ` Marek Vasut
2026-10-19 14:42   ` Laurent Pinchart
2026-10-19 14:56     ` Geert Uytterhoeven
2026-10-19 15:22       ` Laurent Pinchart
2026-10-19 16:14         ` Laurent Pinchart [this message]
2026-10-19 16:37           ` Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 2/8] clk: renesas: r8a78000: Add SCMI remapping support Geert Uytterhoeven
2026-10-19 15:56   ` Laurent Pinchart
2026-10-19 16:15     ` Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 3/8] reset: Extract __reset_control_get_from_provider() Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 4/8] reset: Add reset_control_get_from_provider_exclusive() Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 5/8] pmdomain: Make genpd_get_from_provider() return -EPROBE_DEFER Geert Uytterhoeven
2026-10-19 16:05   ` Laurent Pinchart
2026-10-19 16:32     ` Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 6/8] pmdomain: Make genpd_get_from_provider() public Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 7/8] pmdomain: renesas: r8a78000: Add SCMI remapping support Geert Uytterhoeven
2026-10-16 15:55 ` [PATCH v4 8/8] arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, clock, and reset Geert Uytterhoeven
2026-10-17 11:17 ` [PATCH v4 0/8] R-Car X5H Ironhide CPG/MDLC SCMI remapping support Wolfram Sang

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=20261019161436.GD3705@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=bmasney+clk@redhat.com \
    --cc=clegoffic@baylibre.com \
    --cc=conor+dt@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=jbrunet+clk@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=p.zabel@pengutronix.de \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sudeep.holla@kernel.org \
    --cc=ulfh@kernel.org \
    --cc=vkoul@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox