linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh+dt@kernel.org,
	mark.rutland@arm.com, lee.jones@linaro.org, lgirdwood@gmail.com,
	broonie@kernel.org, mazziesaccount@gmail.com,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, mikko.mutanen@fi.rohmeurope.com,
	heikki.haikola@fi.rohmeurope.com
Subject: Re: [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver
Date: Wed, 30 May 2018 12:05:12 +0300	[thread overview]
Message-ID: <20180530090512.GC13528@localhost.localdomain> (raw)
In-Reply-To: <cover.1527669443.git.matti.vaittinen@fi.rohmeurope.com>

Hello All,

I would like to ask for an educated opinion from more experienced
regulator driver developers.

On Wed, May 30, 2018 at 11:41:13AM +0300, Matti Vaittinen wrote:
> Patch series adding support for ROHM BD71837 PMIC.
> 
> BD71837 is a programmable Power Management IC for powering single-core,
> dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
> low BOM cost and compact solution footprint. It integrates 8 buck
> regulators and 7 LDO’s to provide all the power rails required by the
> SoC and the commonly used peripherals.
> 
> The driver aims to not limit the usage of PMIC. Thus the buck and LDO
> naming is generic and not tied to any specific purposes. However there
> is following limitations which make it mostly suitable for use cases
> where the processor where PMIC driver is running is powered by the PMIC:
> 
> - The PMIC is not re-initialized if it resets. PMIC may reset as a
>   result of voltage monitoring (over/under voltage) or due to reset
>   request. Driver is only initializing PMIC at probe. This is not
>   problem as long as processor controlling PMIC is powered by PMIC.
> 
> - The PMIC internal state machine is ignored by driver. Driver assumes
>   the PMIC is wired so that it is always in "run" state when controlled
>   by the driver.
> 
> Changelog v4
> - remove mutex from regulator state check as core prevents simultaneous
>   accesses
> - allow voltage change for bucks 1 to 4 when regulator is enabled

This chip has 8 bucks. 4 of then support DVS (dynamic voltage scaling).
Other 4 can be used on PWM or PFM switching mode. When PWM is used
voltages can be changed without disabling regulator. On PFM this should
not be done. These latter 4 regulators can be forced to PWM mode via
control bit in register. This driver does not support controlling this
mode though. So this driver version just checks if regulator is enabled
before changing the voltage and if it is the voltage change fails with
-EBUSY

My question is whether it would be good idea to also read the 'force
PWM' bit when voltage is changed and allow the change if PWM mode is
forced to be used? Problem is that the check and voltage change can't be
atomic so there is a chance someone changes the mode (bypassing the
driver and regulator core) after this check but before we get to modify
the voltage. Furthermore, I doubt the 'force PWM' is widely used (but I
can't say for sure as I can't imagine all use cases) as it is not so
power efficient.

But as I am really inexperienced on this area I would like to get
opinions from people who know this field of industry better...

Br,
	Matti Vaittinen

  parent reply	other threads:[~2018-05-30  9:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-30  8:41 [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver Matti Vaittinen
2018-05-30  8:41 ` [PATCH v4 1/6] mfd: bd71837: mfd driver for ROHM BD71837 PMIC Matti Vaittinen
2018-05-30  8:42 ` [PATCH v4 2/6] mfd: bd71837: Devicetree bindings " Matti Vaittinen
2018-05-31  3:01   ` Rob Herring
2018-05-31  7:17     ` Matti Vaittinen
2018-05-31 10:23       ` Matti Vaittinen
2018-05-31 14:07         ` Rob Herring
2018-05-31 14:57           ` Stephen Boyd
2018-06-01 10:51             ` Matti Vaittinen
2018-06-02  6:30               ` Stephen Boyd
2018-06-01  6:25           ` Matti Vaittinen
2018-06-01 17:32             ` Rob Herring
2018-06-04 11:32               ` Matti Vaittinen
2018-06-05 15:46                 ` Rob Herring
2018-06-06  7:34                   ` Matti Vaittinen
2018-06-06 15:16                     ` Rob Herring
2018-06-07 11:12                       ` Matti Vaittinen
2018-06-15 13:20                         ` Matti Vaittinen
2018-05-30  8:42 ` [PATCH v4 3/6] regulator: bd71837: Devicetree bindings for BD71837 regulators Matti Vaittinen
2018-05-31  3:04   ` Rob Herring
2018-05-31  7:21     ` Matti Vaittinen
2018-05-31 14:00       ` Rob Herring
2018-05-30  8:42 ` [PATCH v4 4/6] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC Matti Vaittinen
2018-05-31  3:05   ` Rob Herring
2018-05-30  8:43 ` [PATCH v4 5/6] clk: bd71837: Add driver for BD71837 PMIC clock Matti Vaittinen
2018-05-31 15:10   ` Stephen Boyd
2018-06-01  7:31     ` Matti Vaittinen
2018-06-01 17:11       ` Stephen Boyd
2018-05-30  8:43 ` [PATCH v4 6/6] regulator: bd71837: BD71837 PMIC regulator driver Matti Vaittinen
2018-05-30 11:02   ` Applied "regulator: bd71837: BD71837 PMIC regulator driver" to the regulator tree Mark Brown
2018-05-30 11:14     ` Matti Vaittinen
2018-05-30 11:17       ` Mark Brown
2018-05-30 12:58         ` Matti Vaittinen
2018-05-30 14:34           ` Mark Brown
2018-05-30  9:05 ` Matti Vaittinen [this message]
2018-05-30 11:00   ` [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver Mark Brown
2018-05-30 12:56     ` Matti Vaittinen
2018-05-30 15:41       ` 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=20180530090512.GC13528@localhost.localdomain \
    --to=mazziesaccount@gmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heikki.haikola@fi.rohmeurope.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=mikko.mutanen@fi.rohmeurope.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).