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>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Maciej Purski <m.purski@samsung.com>
Subject: [RFC PATCH v2 0/3] Add coupled regulators mechanism
Date: Wed, 18 Oct 2017 14:46:59 +0200 [thread overview]
Message-ID: <1508330822-8039-1-git-send-email-m.purski@samsung.com> (raw)
In-Reply-To: <CGME20171018124722eucas1p23aa3280d33bfd38650783ac7f52b9909@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.
Open question - which locking model should be used, because
during balancing voltages we need to lock all coupled regulators
and their parents. Unfortunately, some coupled regulators might
have common parents. I can see three possibilities here:
1. (current implementation) Always lock all coupled regulators and additionally
lock parents only for changing voltage of the individual regulator
2. Always lock all coupled regulators and their parents - to avoid deadlock
on common parent, first enumerate locks, then sort them and remove double
entries
3. Always lock all coupled regulators and their parents - to avoid deadlock
on common parent, introduce so called reentrant locks (lock which might
be taken multiple times by the same process).
Best regards,
Maciej Purski
--
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 (3):
regulator: bindings: Add properties for coupled regulators
regulator: core: Parse coupled regulators properties
regulator: core: Balance coupled regulators voltages
.../devicetree/bindings/regulator/regulator.txt | 4 +
drivers/regulator/core.c | 487 ++++++++++++++++++++-
include/linux/regulator/driver.h | 17 +
3 files changed, 492 insertions(+), 16 deletions(-)
--
2.7.4
next parent reply other threads:[~2017-10-18 12:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20171018124722eucas1p23aa3280d33bfd38650783ac7f52b9909@eucas1p2.samsung.com>
2017-10-18 12:46 ` Maciej Purski [this message]
[not found] ` <CGME20171018124727eucas1p255ccce41852d5585640f2d97153d2fa8@eucas1p2.samsung.com>
2017-10-18 12:47 ` [RFC PATCH v2 1/3] regulator: bindings: Add properties for coupled regulators Maciej Purski
2017-10-24 18:58 ` Rob Herring
2017-10-25 7:31 ` Maciej Purski
2017-10-25 12:59 ` Rob Herring
2017-10-25 13:10 ` Maciej Purski
[not found] ` <CGME20171018124735eucas1p2dc60191fb185f18dee16d4b3de8502cf@eucas1p2.samsung.com>
2017-10-18 12:47 ` [RFC PATCH v2 2/3] regulator: core: Parse coupled regulators properties Maciej Purski
2017-11-29 16:25 ` Mark Brown
[not found] ` <CGME20171018124737eucas1p2ed8002fa4910545e9d56a536303ffc12@eucas1p2.samsung.com>
2017-10-18 12:47 ` [RFC PATCH v2 3/3] regulator: core: Balance coupled regulators voltages Maciej Purski
2017-11-29 18:29 ` 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=1508330822-8039-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=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
all inboxes | Powered by JetHome®