From: Sundar R IYER <sundar.iyer@stericsson.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "lrg@slimlogic.co.uk" <lrg@slimlogic.co.uk>,
"sameo@linux.intel.com" <sameo@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
STEricsson_nomadik_linux <STEricsson_nomadik_linux@list.st.com>,
Linus WALLEIJ <linus.walleij@stericsson.com>,
Bengt JONSSON <bengt.g.jonsson@stericsson.com>
Subject: Re: [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data
Date: Wed, 14 Jul 2010 22:17:09 +0530 [thread overview]
Message-ID: <20100714164708.GD1689@bnru01.bnr.st.com> (raw)
In-Reply-To: <20100714162048.GA27512@rakim.wolfsonmicro.main>
> Are you positive that in your system it is sensible for consumers to
> enable and disable all the supplies? Usually there are restrictions on
> what can sensibly be done on a given system. For example, disabling the
> CPU core or RAM supplies from software would normally not work terribly
> well.
As I said earlier, there are other supplies which I havent exposed here,
simply because,
1. they are controlled out of the kernel, which makes it meaningless
to include them for kernel modules
2. Even if those were included, the risk of mis-controlling them due
to bad SW is very high as you say and hence safely out of SW control.
I assure you that such supplies are *not* included in this list.
> CPU core or RAM supplies from software would normally not work terribly
Also, usually the deepest(lowest) power state for the CPU core is
~0V(atleast on our platform); which can be possible only by switching
off the supplies to the core; thus effectively resulting in being
controlled by SW. Further, I dont see the point of running full supplies
to the RAM in a system idle state, when it is okay for the RAM to be
powered @ a half rating OIW accountable to the idle state latencies.
> Right, but think about the case I'm talking about: if you've only hooked
> up some but not all of the consumers then the core has no idea about the
> consumers you didn't hook up. You can only do power control when *all*
> the consumers needed are configured.
I see your point. But from an other perspective - it is *not* neccessary
to have power control only when *all* consumers are in. For eg: we have
2 peripherals sharing one of the VAUX supplies. At this moment, both the
peripherals drivers are integrated with the regulator APIs; which means
the core handles most of the work regarding control. If, one of the
peripherals isnt included in the final configuration, still, IMO, it
*does* make sense that the other active peripheral optimally manage the
supply control; which is gauranteed by the core. IOW & IMO, a consumer
that hasnt hooked up to the regulator and thus is *aware* that it isnt
sourced can be safely assumed to be non-existent.
Regards,
Sundar
next prev parent reply other threads:[~2010-07-14 16:47 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-13 14:09 [PATCH v2 1/2] regulator: add support for regulators on the ab8500 MFD Sundar Iyer
2010-07-13 14:09 ` [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data Sundar Iyer
2010-07-13 14:18 ` Mark Brown
2010-07-13 14:41 ` Sundar R IYER
2010-07-13 14:56 ` Mark Brown
2010-07-13 15:08 ` Sundar R IYER
2010-07-13 15:09 ` Mark Brown
2010-07-13 16:13 ` Sundar R IYER
2010-07-13 20:38 ` Mark Brown
2010-07-14 14:50 ` Sundar R IYER
2010-07-14 14:57 ` Mark Brown
2010-07-14 15:36 ` Sundar R IYER
2010-07-14 15:47 ` Mark Brown
2010-07-14 16:09 ` Sundar R IYER
2010-07-14 16:20 ` Mark Brown
2010-07-14 16:47 ` Sundar R IYER [this message]
2010-07-14 17:03 ` Mark Brown
2010-07-14 17:36 ` Sundar R IYER
2010-07-14 18:42 ` Mark Brown
2010-07-14 22:51 ` Linus Walleij
2010-07-15 9:09 ` Mark Brown
2010-07-13 14:17 ` [PATCH v2 1/2] regulator: add support for regulators on the ab8500 MFD Mark Brown
2010-07-13 14:34 ` Sundar R IYER
2010-07-13 14:57 ` Mark Brown
2010-07-13 14:58 ` Mark Brown
2010-07-13 15:11 ` Sundar R IYER
2010-07-13 15:12 ` Mark Brown
2010-07-13 16:18 ` Sundar R IYER
2010-07-13 20:40 ` Mark Brown
2010-07-15 10:29 ` Liam Girdwood
2010-10-27 16:25 ` Thiago Farina
2010-10-27 17:33 ` Mark Brown
2010-10-27 17:42 ` Thiago Farina
2010-10-27 17:56 ` 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=20100714164708.GD1689@bnru01.bnr.st.com \
--to=sundar.iyer@stericsson.com \
--cc=STEricsson_nomadik_linux@list.st.com \
--cc=bengt.g.jonsson@stericsson.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=sameo@linux.intel.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
Powered by JetHome