From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>,
open list <linux-kernel@vger.kernel.org>,
Mike Turquette <mturquette@linaro.org>,
Tero Kristo <t-kristo@ti.com>, Nishanth Menon <nm@ti.com>,
linux-omap <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: [RFC v1 0/1] introduce regulator chain locking scheme
Date: Mon, 15 Apr 2013 16:03:34 +0300 [thread overview]
Message-ID: <1366031015-17073-1-git-send-email-grygorii.strashko@ti.com> (raw)
Hi Mark, Liam, All
Our target is to reuse common DVFS framework proposed by Mike Turquette
in http://lwn.net/Articles/540422/ and cpufreq-cpu0.c for all TI SoC and
minimize creation of any TI specific APIs or modules.
The common DVFS framework solution is based on assumption that Regulator,
connected to DVFS FW or CPU0 CPUFreq, is able to change requested voltage for
the corresponding Voltage domain (like CPU/MPU) by itself.
But most of TI SoCs, which support DVFS, have more complex voltage supply
schema as shown below:
|------------| |------------|
--| RegulatorY |--| CPU DVFS |
|------------| |------------|
\ \
\ \_____________________________
\ \
|-------------------| |---------------| |---------|
--| RegulatorX (PMIC) |--| Regulator AVS |--| ABB LDO |--
|-------------------| |---------------| |---------|
/|\ |
|______________________|
Voltage adjustment
and they need to configure, at least, internal ABB LDO befor/after
reconfiguring external voltage supplier in PMIC.
(as maximum - Regulator AVS (Adaptive voltage scaling) is needed to be
reconfigured after ABB LDO, and Regulator AVS may, finally, reconfigure external
voltage supplier with voltage value which is different from initially requested by DVFS).
for example (Vcur<Vreq):
- DVFS requests voltage change
- AVS converts Vreq to Vreq1 (say calibrated)
- AVS reconfigure RegulatorX (PMIC) to voltage Vreq1
- ABB LDO change type to FBB
This Regulator chaining scema can fit to Regulator framework very well
(from our point of view):
- DVFS: abb->set_voltage(Vreq)
- ABB: if (Vcur<Vreq)
AVS->set_voltage(Vreq)
- AVS: PMIC->set_voltage(Vreq1)
- ABB: if (Vcur<Vreq)
change type to FBB
But there are some limitations:
- the whole Regulator chain need to be locked in case if any part of
it has been accessed from outside;
- child regulator should have access to set/get voltage methods of its
parent (supplier).
The proposed patches allow to remove these restrictions and they are inspired by
http://lwn.net/Articles/540422/.
Related dicussions:
- regulator: query on regulator re-entrance
http://marc.info/?l=linux-omap&m=136513861315970&w=2
- clk: notifier handler for dynamic voltage scaling
https://lkml.org/lkml/2013/2/27/414
Tested on K3.8 OMAP4 SDP/T2 (ABB+vcvp regulator) and
OMAP5 sevm (ABB+smps123(i2c) regulator):
- cpu freq & voltages was scaled.
Could you please review and advise? Does anyone else interested in or have similar problems?
Grygorii Strashko (1):
regulator: core: introduce regulator chain locking scheme
drivers/regulator/core.c | 134 ++++++++++++++++++++++++--------------
include/linux/regulator/driver.h | 2 +
2 files changed, 88 insertions(+), 48 deletions(-)
Regards
Grygorii Strashko
Cc: linux-kernel@vger.kernel.org (open list)
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>
Cc: linux-arm <linux-arm-kernel@lists.infradead.org>
--
1.7.9.5
next reply other threads:[~2013-04-15 13:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-15 13:03 Grygorii Strashko [this message]
2013-04-15 13:03 ` [RFC v1] regulator: core: " Grygorii Strashko
2013-04-15 15:50 ` Mark Brown
2013-04-15 16:21 ` Andrii Tseglytskyi
2013-04-15 16:40 ` Mark Brown
2013-04-18 16:29 ` Grygorii Strashko
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=1366031015-17073-1-git-send-email-grygorii.strashko@ti.com \
--to=grygorii.strashko@ti.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=nm@ti.com \
--cc=t-kristo@ti.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
all inboxes | Powered by JetHome®