public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Josua Mayer <josua@solid-run.com>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Jon Nettleton <jon@solid-run.com>,
	Mikhail Anikin <mikhail.anikin@solid-run.com>,
	Yazan Shhady <yazan.shhady@solid-run.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH RFC 2/2] regulator: raa215300: add support for configurable 32kHz clock output
Date: Sun, 3 May 2026 14:49:04 +0000	[thread overview]
Message-ID: <01bf5fdd-17f9-4ee6-95a7-561f715ec387@solid-run.com> (raw)
In-Reply-To: <afadX4IC9o-zj6qC@sirena.co.uk>

Am 03.05.26 um 02:57 schrieb Mark Brown:
> On Sat, May 02, 2026 at 06:07:05PM +0200, Josua Mayer wrote:
>> Renesas RA215300 PMIC can be configured to output a 32kHz clock on its
>> multi-purpose MPIO2 pin.
>> There are in total 6 configurable multi-purpose pins, however only one
>> of them supports outputting a clock in one specific configuration.
> So there should be some pinmux support here then?  This is starting to
> sound like a MFD...

If we want to treat it like an MFD, then the logical sub-devices would be:

1. pinmux/pinconf
2. clock
3. gpi, gpo

Then there is the RTC, which is not a sub-device because it has its own i2c
bus address, but its power controls inside the raa215300.

And there are some more complex regulator status and configuration registers.

Implemented is only the RTC ... and I would like to add the clock,
as it is used for Bluetooth on a SolidRun board.

My own particular use-case would also be satisfied by implementing
pinmux instead, as I need the 32kHz rate which is default.

>
>> +#define RAA215300_MPIO2_POWER_OFF_DELAY			GENMASK(6, 0)
>> +#define RAA215300_REG_MPIO2_CONFIG			0x8c
>
>> +static void raa215300_clk_unprepare(struct clk_hw *hw)
>> +{
>> +	struct raa215300_clk *clk = to_raa215300_clk(hw);
>> +	const u8 dis_val = RAA215300_MPIO2_CONFIG_TYPE_HIGH_IMPEDANCE |
>> +			   RAA215300_MPIO2_CONFIG_FUNCTION_NONE;
>> +
>> +	regmap_write(clk->regmap, RAA215300_REG_MPIO2_CONFIG, dis_val);
>> +}
Considering I use the pin configuration register to enable and disable the clock,
one might argue that if a pinmux driver exists, then the clock is always on
and does not support prepare/unprepare.

This would allow me to skip implemeting a clock subdevice,
and instead only implement a pinconf/mux driver.

Any opinions?

>> +static unsigned long raa215300_clk_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
>> +{
>> +	struct raa215300_clk *clk = to_raa215300_clk(hw);
>> +	unsigned int val;
>> +
>> +	regmap_read(clk->regmap, RAA215300_REG_MPIO2_POWER_OFF, &val);
>> +	val &= RAA215300_MPIO2_POWER_OFF_DELAY;
>> +
>> +	return 32768 >> val;
>> +}
> Given the mask above val could be up to 127?  If nothing else it'd be
> good to have some validation.
Does it need validation if the mask is good?
>
>> +		/* register mpio2 32k clkout in common clk framework */
>> +		raa215300_register_clk(dev, regmap);
> You should check the return value here.
Ack.

  reply	other threads:[~2026-05-03 14:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-02 16:07 [PATCH RFC 0/2] regulator: raa215300: add support for configurable 32kHz clock output Josua Mayer
2026-05-02 16:07 ` [PATCH RFC 1/2] regulator: dt-bindings: raa215300: add " Josua Mayer
2026-05-03  0:57   ` Mark Brown
2026-05-03 14:32     ` Josua Mayer
2026-05-04  8:56   ` Geert Uytterhoeven
2026-05-02 16:07 ` [PATCH RFC 2/2] regulator: raa215300: add support for configurable 32kHz " Josua Mayer
2026-05-03  0:57   ` Mark Brown
2026-05-03 14:49     ` Josua Mayer [this message]
2026-05-03 15:13       ` Josua Mayer
2026-05-03  9:24 ` [PATCH RFC 0/2] " Biju Das

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=01bf5fdd-17f9-4ee6-95a7-561f715ec387@solid-run.com \
    --to=josua@solid-run.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=jon@solid-run.com \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mikhail.anikin@solid-run.com \
    --cc=robh@kernel.org \
    --cc=yazan.shhady@solid-run.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