devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maciej Purski <m.purski@samsung.com>
To: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Cc: Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Doug Anderson <dianders@chromium.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Maciej Purski <m.purski@samsung.com>
Subject: [PATCH v4 0/7] Add coupled regulators mechanism
Date: Mon, 22 Jan 2018 15:30:05 +0100	[thread overview]
Message-ID: <1516631412-17542-1-git-send-email-m.purski@samsung.com> (raw)
In-Reply-To: CGME20180122143019eucas1p213b852c98cde3fb8a77b96ab0d372ee6@eucas1p2.samsung.com

Hi all,

this patchset adds a new mechanism to the framework - regulators' coupling.

On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires 
higher voltage, there might occur a situation that the spread between 
devices' voltages is so high, that there is a risk of changing
'high' and 'low' states on the interconnection between devices powered
by those regulators. 

Algorithmicaly the problem was solved by: 
Inderpal Singh <inderpal.s@samsung.com>
Doug Anderson <dianders@chromium.org>

The discussion on that subject can be found here:
https://lkml.org/lkml/2014/4/29/28

Therefore this patchset is an attempt to apply the idea to regulators core
as concluded in the discussion by Mark Brown and Doug Anderson.

This feature is required to enable support for generic CPUfreq 
and devfreq drivers for the mentioned boards. 

Note on the locking model:
When balancing voltage of a group of coupled regulators, we lock all
of them for the whole operation. When voltage of an individual regulator
is about to change, its suppliers are additionally locked.

The current assumption is that an uncoupled regulator is a special case
of a coupled one, so they should share a common voltage setting path.


Best regards,

	Maciej Purski

---
Changes in v4:
- make paths for coupled and uncoupled regulators common
- coupling descriptors are now always present in regulator_dev
- fail to probe if data inconsistency is detected
- retry to resolve coupling regultors in late init call
- rebase on top of linux-next 20180119
- fix commit messages
- split patches to make the patchset easier to review

Changes in v3:
- move dts parsing code to of_regulator.c, in order to the so,
  add a new commit in which of_regulator_find_by_node() is moved
  to of_regulator.c as well
- improve error messages
- move max_spread variable to constraints
- perform resolving of coupled regulators under a list mutex
- remove useless locking functions
- some minor refactorization
- improve commit messages

Changes in RFC v2:
- allow coupling n regulators (in fact up to constant value, now
  set to 10)
- change algorithm to be more readable
- introduce better locking
- add more comments
- split first patch into two
- update commit messages
- change sequence of the patches

Maciej Purski (7):
  regulator: core: Move of_find_regulator_by_node() to of_regulator.c
  regulator: core: Refactor regulator_list_voltage()
  regulator: bindings: Add properties for coupled regulators
  regulator: core: Parse coupled regulators properties
  regulator: core: Resolve coupled regulators
  regulator: core: Add voltage balancing mechanism
  regulator: core: Change voltage setting path

 .../devicetree/bindings/regulator/regulator.txt    |   5 +
 drivers/regulator/core.c                           | 416 ++++++++++++++++++---
 drivers/regulator/internal.h                       |  15 +
 drivers/regulator/of_regulator.c                   | 163 ++++++++
 include/linux/regulator/driver.h                   |  18 +
 include/linux/regulator/machine.h                  |   4 +
 6 files changed, 575 insertions(+), 46 deletions(-)

-- 
2.7.4

       reply	other threads:[~2018-01-22 14:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180122143019eucas1p213b852c98cde3fb8a77b96ab0d372ee6@eucas1p2.samsung.com>
2018-01-22 14:30 ` Maciej Purski [this message]
     [not found]   ` <CGME20180122143029eucas1p284202b6e60a86b428b3aa1e6eef62bda@eucas1p2.samsung.com>
2018-01-22 14:30     ` [PATCH v4 1/7] regulator: core: Move of_find_regulator_by_node() to of_regulator.c Maciej Purski
     [not found]   ` <CGME20180122143030eucas1p2eb1054dd14902eb0be83e5c9efb11d98@eucas1p2.samsung.com>
2018-01-22 14:30     ` [PATCH v4 2/7] regulator: core: Refactor regulator_list_voltage() Maciej Purski
2018-01-26 17:35       ` Applied "regulator: core: Refactor regulator_list_voltage()" to the regulator tree Mark Brown
     [not found]   ` <CGME20180122143031eucas1p205647b3821760ad7e7a3bef5f8873d14@eucas1p2.samsung.com>
     [not found]     ` <1516631412-17542-1-git-send-email-m.purski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2018-01-22 14:30       ` [PATCH v4 3/7] regulator: bindings: Add properties for coupled regulators Maciej Purski
2018-01-22 14:30       ` [PATCH v4 6/7] regulator: core: Add voltage balancing mechanism Maciej Purski
2018-03-02 12:55         ` Applied "regulator: core: Add voltage balancing mechanism" to the regulator tree Mark Brown
2018-05-17 16:41         ` Mark Brown
2018-01-22 14:30       ` [PATCH v4 7/7] regulator: core: Change voltage setting path Maciej Purski
     [not found]   ` <CGME20180122143032eucas1p229e2ec741318df3e716e736796bbb9c1@eucas1p2.samsung.com>
2018-01-22 14:30     ` [PATCH v4 4/7] regulator: core: Parse coupled regulators properties Maciej Purski
     [not found]   ` <CGME20180122143033eucas1p2adb3b39af238b2449486389d214a3a68@eucas1p2.samsung.com>
2018-01-22 14:30     ` [PATCH v4 5/7] regulator: core: Resolve coupled regulators Maciej Purski
2018-03-02 12:55       ` Applied "regulator: core: Resolve coupled regulators" to the regulator tree Mark Brown
2018-01-26 17:31   ` [PATCH v4 0/7] Add coupled regulators mechanism Mark Brown
2018-03-01 19:38   ` 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=1516631412-17542-1-git-send-email-m.purski@samsung.com \
    --to=m.purski@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@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).