From: Sundar R Iyer <sundar.iyer@stericsson.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Deepak Sikri <deepak.sikri79@gmail.com>,
Viresh KUMAR <viresh.kumar@st.com>,
Rajeev KUMAR <rajeev-dlh.kumar@st.com>,
Armando VISCONTI <armando.visconti@st.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Vipin KUMAR <vipin.kumar@st.com>,
Shiraz HASHIM <shiraz.hashim@st.com>,
"linux-pm@lists.linux-foundation.org"
<linux-pm@lists.linux-foundation.org>,
Linus WALLEIJ <linus.walleij@stericsson.com>,
STEricsson_nomadik_linux <STEricsson_nomadik_linux@list.st.com>
Subject: Re: [linux-pm] Power Domain Framework
Date: Mon, 17 May 2010 23:15:32 +0530 [thread overview]
Message-ID: <1274118332.17303.17.camel@bnru01> (raw)
In-Reply-To: <1274115886.2698.22.camel@finisterre.wolfsonmicro.main>
Hello,
> This implementation is assuming that the implementation in hardware only
> has two levels, and that the decision to go to the higher level is done
> by a simple or of requests for the full level from the consumers. I'm
> not convinced that this will be true in general, or that it's always
> going to be true that the different power domains are all isolated from
> each other. There doesn't seem to be any immediate reason why hardware
> won't ever implement more than two modes, and I'm not convinced that the
> straight or of requests will always be sufficient to determine the
Yes. Two modes is not the only level that hardware can support.
An ideal case is Full OPP/Half OPP (which is the normal operating
point)/Retention(which is the least so that the device is on).
> operating mode for the entire power domain. For example, I can see
> hardware requiring that if more than a given number of blocks are
> enabled at any level a higher operating point is selected.
Hmm...very much possible. Need to think on this further.
> Are you sure that this interface is sufficiently general to work with
> all hardware, not just your own? How does this map on to the OMAP or SH
> hardware, for example?
AFAIK and with my experience (and my current memory) with TI Davinci
arch, most of the power domains are simpler ones with on/off and
possibly some retention too. And the latest TI code also exposes domains
with on/off/retention states. So, I think if we make this sturdy, I dont
see any reason why we cannot map any generic architecture. CCing Kevin
for his inputs.
This is one of the most important aspect for such a change in the
regulator framework: bringing in the domain aspect can encourage all
newer (possibly older) architectures to come under a generic umbrella.
Anyways, let me have a bit more on the "number of blocks" thing!
Regards,
Sundar
next prev parent reply other threads:[~2010-05-17 17:46 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 13:46 Power Domain Framework Deepak Sikri
2010-05-10 14:05 ` Mark Brown
2010-05-10 14:05 ` [linux-pm] " Mark Brown
2010-05-16 11:13 ` Sundar
2010-05-17 3:16 ` Mark Brown
[not found] ` <AANLkTimDdBCnRFMDiUkuNKanOzuPNwCpfRv9Gsi03Lsy@mail.gmail.com>
2010-05-17 13:33 ` Fwd: " Sundar
2010-05-17 13:33 ` Fwd: [linux-pm] " Sundar
2010-05-17 14:33 ` Fwd: " Mark Brown
2010-05-17 14:33 ` Fwd: [linux-pm] " Mark Brown
2010-05-17 16:23 ` Sundar
2010-05-17 16:35 ` Sundar R Iyer
2010-05-17 16:35 ` [linux-pm] " Sundar R Iyer
2010-05-17 17:04 ` Mark Brown
2010-05-17 17:04 ` [linux-pm] " Mark Brown
2010-05-17 17:45 ` Sundar R Iyer [this message]
2010-05-17 20:38 ` Linus WALLEIJ
2010-05-17 20:38 ` [linux-pm] " Linus WALLEIJ
2010-05-17 21:18 ` Mark Brown
2010-05-17 21:18 ` [linux-pm] " Mark Brown
2010-05-17 21:46 ` Linus WALLEIJ
2010-05-17 21:46 ` [linux-pm] " Linus WALLEIJ
2010-05-17 22:17 ` Mark Brown
2010-05-17 22:17 ` [linux-pm] " Mark Brown
2010-05-18 6:00 ` Sundar R Iyer
2010-05-18 6:00 ` [linux-pm] " Sundar R Iyer
2010-05-22 4:02 ` Sundar
2010-05-24 3:39 ` [linux-pm] " Mark Brown
2010-05-26 8:33 ` Sundar R IYER
2010-05-26 8:33 ` [linux-pm] " Sundar R IYER
2010-05-26 21:07 ` Mark Brown
2010-05-26 21:07 ` [linux-pm] " Mark Brown
2010-05-27 3:01 ` Paul Mundt
2010-05-27 3:01 ` [linux-pm] " Paul Mundt
2010-05-27 6:51 ` Mark Brown
2010-05-27 6:51 ` [linux-pm] " Mark Brown
2010-05-24 3:39 ` Mark Brown
2010-05-17 17:45 ` Sundar R Iyer
2010-05-17 20:20 ` Fwd: [linux-pm] " Mark Brown
2010-05-17 20:20 ` Fwd: " Mark Brown
2010-05-17 16:23 ` Sundar
2010-05-17 3:16 ` Mark Brown
2010-05-16 11:13 ` Sundar
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=1274118332.17303.17.camel@bnru01 \
--to=sundar.iyer@stericsson.com \
--cc=STEricsson_nomadik_linux@list.st.com \
--cc=armando.visconti@st.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=deepak.sikri79@gmail.com \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=rajeev-dlh.kumar@st.com \
--cc=shiraz.hashim@st.com \
--cc=vipin.kumar@st.com \
--cc=viresh.kumar@st.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.