public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Matti Vaittinen" <matti.vaittinen@fi.rohmeurope.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Okan Sahin" <okan.sahin@analog.com>,
	"Vincent Whitchurch" <vincent.whitchurch@axis.com>,
	"Mårten Lindahl" <marten.lindahl@axis.com>
Subject: Re: [PATCH 1/3] regulator: don't cache vsel to ensure voltage setting
Date: Thu, 16 May 2024 17:14:47 +0300	[thread overview]
Message-ID: <6f3052a4-e3b9-4ffb-9251-1f469e13a1d4@gmail.com> (raw)
In-Reply-To: <f7cf4ac0-afa2-4f64-818b-1275b1e8a6ee@sirena.org.uk>

Hi Mark,

Added some driver folks to CC. It'd be great to lean how other devices 
avoid having intermediate voltages if range and vsel write is not atomic.

On 5/16/24 14:33, Mark Brown wrote:
> On Thu, May 16, 2024 at 11:53:46AM +0300, Matti Vaittinen wrote:
> 
>> +		/*
>> +		 * Some PMICs treat the vsel_reg same as apply-bit. Force it
>> +		 * to be written even if the old selector were same as the new
>> +		 * (but range changed) by using regmap_write_bits() and not the
>> +		 * regmap_update_bits().
>> +		 */
>> +		ret = regmap_write_bits(rdev->regmap, rdev->desc->vsel_reg,
>> +					rdev->desc->vsel_mask, sel);
> 
> This feels like a special case for those devices, for devices that don't
> have this behaviour it'd be a regression in that it'd increase I/O
> traffic.

I thought most of devices which have pickable voltage ranges and a 
separate register for range and voltage selector would need some 
mechanism to prevent 'intermediate voltages' as writing the vsel and 
range won't be atomic.

Also, the "pickable ranges" is not that widely used, and many of the 
users have the range and vsel selectors in same register (and if they 
don't, they're likely to see unwanted side effects due to non atomic write).

I did actually go through the drivers. These seem to be clear:

atc260x-regulator.c: vsel and range in same register
max77650-regulator.c: vsel and range in same register
tps6287x-regulator.c: According to a data-sheet, this requires a vsel 
write for range change to take effect (just like the device I am working 
with), so the current implementation may be suffering from the bug I am 
trying to solve.

Anyways, following might be unnecessarily impacted:

max77541-regulator.c - but, I briefly looked at the data-sheet, and I am 
not sure the driver operates according to the spec. The spec I found 
stated the range bits must not be changed when the output is enabled.

mt6358-regulator.c: I didn't find proper spec details.

>  At least this should be specialised to only devices that have
> ranges I think?

This operation is the regulator_set_voltage_sel_pickable_regmap() - 
which should be only used for devices which use pickable ranges. 
Furthermore, it's inside the else branch for if (rdev->desc->vsel_reg == 
rdev->desc->vsel_range_reg) meaning the range selection bit is in 
separate register from the voltage selection.

Anyways, thanks for the heads up. I really didn't know we had other 
users which would be affected. I'll consider adding a flag to the 
regulator desc for deciding if the vsel should always be written when 
range changes.

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~


  reply	other threads:[~2024-05-16 14:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16  8:52 [PATCH 0/3] regulator: misc fixes Matti Vaittinen
2024-05-16  8:53 ` [PATCH 1/3] regulator: don't cache vsel to ensure voltage setting Matti Vaittinen
2024-05-16 11:33   ` Mark Brown
2024-05-16 14:14     ` Matti Vaittinen [this message]
2024-05-16  8:54 ` [PATCH 2/3] regulator: bd71828: Don't overwrite runtime voltages Matti Vaittinen
2024-05-16  8:55 ` [PATCH 3/3] regulator: rohm-regulator: warn if unsupported voltage is set Matti Vaittinen
2024-05-16 15:58 ` [PATCH 0/3] regulator: misc fixes 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=6f3052a4-e3b9-4ffb-9251-1f469e13a1d4@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marten.lindahl@axis.com \
    --cc=matthias.bgg@gmail.com \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=okan.sahin@analog.com \
    --cc=vincent.whitchurch@axis.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