All of lore.kernel.org
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data
Date: Wed, 14 Jul 2010 17:20:49 +0100	[thread overview]
Message-ID: <20100714162048.GA27512@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20100714160941.GC1689@bnru01.bnr.st.com>

On Wed, Jul 14, 2010 at 09:39:42PM +0530, Sundar R IYER wrote:

> > For *all* supplies?

> Yes. whatever supplies I have listed here all can be enabled/disabled by
> their consumers. Sorry to ask, but please help me to understand the
> emphasis of the question. There are other supplies, which are controlled
> outside the kernel and so I haven't exposed them here.

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.

> > some of the consumers on a shared supply are hooked up and doing enables
> > and disables, for example.  What happens when they cause the supply to
> > be disabled but another consumer is running?

> Again, sorry to ask(this is confusing :() - but isn't this managed by
> the core? It is the core's responsibility to effectively disable a
> supply when none of the consumers are using it; and to block a disable
> even when a single consumer is still using it.

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.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Sundar R IYER <sundar.iyer@stericsson.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 17:20:49 +0100	[thread overview]
Message-ID: <20100714162048.GA27512@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20100714160941.GC1689@bnru01.bnr.st.com>

On Wed, Jul 14, 2010 at 09:39:42PM +0530, Sundar R IYER wrote:

> > For *all* supplies?

> Yes. whatever supplies I have listed here all can be enabled/disabled by
> their consumers. Sorry to ask, but please help me to understand the
> emphasis of the question. There are other supplies, which are controlled
> outside the kernel and so I haven't exposed them here.

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.

> > some of the consumers on a shared supply are hooked up and doing enables
> > and disables, for example.  What happens when they cause the supply to
> > be disabled but another consumer is running?

> Again, sorry to ask(this is confusing :() - but isn't this managed by
> the core? It is the core's responsibility to effectively disable a
> supply when none of the consumers are using it; and to block a disable
> even when a single consumer is still using it.

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.

  reply	other threads:[~2010-07-14 16:20 UTC|newest]

Thread overview: 68+ 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 ` Sundar Iyer
2010-07-13 14:09 ` [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data Sundar Iyer
2010-07-13 14:09   ` Sundar Iyer
2010-07-13 14:18   ` Mark Brown
2010-07-13 14:18     ` Mark Brown
2010-07-13 14:41     ` Sundar R IYER
2010-07-13 14:41       ` Sundar R IYER
2010-07-13 14:56       ` Mark Brown
2010-07-13 14:56         ` Mark Brown
2010-07-13 15:08         ` Sundar R IYER
2010-07-13 15:08           ` Sundar R IYER
2010-07-13 15:09           ` Mark Brown
2010-07-13 15:09             ` Mark Brown
2010-07-13 16:13             ` Sundar R IYER
2010-07-13 16:13               ` Sundar R IYER
2010-07-13 20:38               ` Mark Brown
2010-07-13 20:38                 ` Mark Brown
2010-07-14 14:50                 ` Sundar R IYER
2010-07-14 14:50                   ` Sundar R IYER
2010-07-14 14:57                   ` Mark Brown
2010-07-14 14:57                     ` Mark Brown
2010-07-14 15:36                     ` Sundar R IYER
2010-07-14 15:36                       ` Sundar R IYER
2010-07-14 15:47                       ` Mark Brown
2010-07-14 15:47                         ` Mark Brown
2010-07-14 16:09                         ` Sundar R IYER
2010-07-14 16:09                           ` Sundar R IYER
2010-07-14 16:20                           ` Mark Brown [this message]
2010-07-14 16:20                             ` Mark Brown
2010-07-14 16:47                             ` Sundar R IYER
2010-07-14 16:47                               ` Sundar R IYER
2010-07-14 17:03                               ` Mark Brown
2010-07-14 17:03                                 ` Mark Brown
2010-07-14 17:36                                 ` Sundar R IYER
2010-07-14 17:36                                   ` Sundar R IYER
2010-07-14 18:42                                   ` Mark Brown
2010-07-14 18:42                                     ` Mark Brown
2010-07-14 22:51                                     ` Linus Walleij
2010-07-14 22:51                                       ` Linus Walleij
2010-07-15  9:09                                       ` Mark Brown
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:17   ` Mark Brown
2010-07-13 14:34   ` Sundar R IYER
2010-07-13 14:34     ` Sundar R IYER
2010-07-13 14:57     ` Mark Brown
2010-07-13 14:57       ` Mark Brown
2010-07-13 14:58     ` Mark Brown
2010-07-13 14:58       ` Mark Brown
2010-07-13 15:11       ` Sundar R IYER
2010-07-13 15:11         ` Sundar R IYER
2010-07-13 15:12         ` Mark Brown
2010-07-13 15:12           ` Mark Brown
2010-07-13 16:18           ` Sundar R IYER
2010-07-13 16:18             ` Sundar R IYER
2010-07-13 20:40             ` Mark Brown
2010-07-13 20:40               ` Mark Brown
2010-07-15 10:29               ` Liam Girdwood
2010-07-15 10:29                 ` Liam Girdwood
2010-10-27 16:25 ` Thiago Farina
2010-10-27 16:25   ` Thiago Farina
2010-10-27 17:33   ` Mark Brown
2010-10-27 17:33     ` Mark Brown
2010-10-27 17:42     ` Thiago Farina
2010-10-27 17:42       ` Thiago Farina
2010-10-27 17:56       ` Mark Brown
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=20100714162048.GA27512@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.