mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: sundar.iyer@stericsson.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 10:04:46 -0700	[thread overview]
Message-ID: <1274115886.2698.22.camel@finisterre.wolfsonmicro.main> (raw)
In-Reply-To: <1274114107.20589.64.camel@bnru01> (sfid-20100517_173524_963855_B42F2966)

On Mon, 2010-05-17 at 22:05 +0530, Sundar R Iyer wrote:

> +/* locks held by regulator_set_operating_point() */
> +static int _regulator_set_operating_point(struct regulator_dev *rdev,
> +		unsigned int opp)
> +{
> +	int ret, regulator_curr_opp = 0;
> +
> +	if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_OPP)) {
> +		printk(KERN_ERR "%s: operation not allowed for %s\n",
> +				__func__, rdev->desc->name);
> +		return -EPERM;
> +	}
> +
> +	/* sanity checks */
> +	if (!rdev->desc->ops->set_operating_point) {
> +		return -EINVAL;
> +	}
> +
> +	if (rdev->desc->ops->get_operating_point)
> +		regulator_curr_opp = rdev->desc->ops->get_operating_point(rdev);
> +
> +	/* we have no issues with upgrading the opp */
> +	if (opp == REGULATOR_OPERATINGPOINT_FULL) {
> +		if (rdev->constraints->opp_constraint_count < 1) {
> +			if (rdev->supply)
> +				ret = _regulator_set_operating_point(rdev->supply, opp);
> +			ret = rdev->desc->ops->set_operating_point(rdev, opp);
> +		}
> +		rdev->constraints->opp_constraint_count++;
> +	}

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
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.

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?


  reply	other threads:[~2010-05-17 17:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTinZU1D1rMOBQDi47tRhXrOXwduQIdni7bCXdce0@mail.gmail.com>
2010-05-10 14:05 ` 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 14:33           ` Mark Brown
2010-05-17 16:23             ` Sundar
2010-05-17 16:35               ` Sundar R Iyer
2010-05-17 17:04                 ` Mark Brown [this message]
2010-05-17 17:45                   ` Sundar R Iyer
2010-05-17 20:38                     ` Linus WALLEIJ
2010-05-17 21:18                       ` Mark Brown
2010-05-17 21:46                         ` Linus WALLEIJ
2010-05-17 22:17                           ` Mark Brown
2010-05-18  6:00                             ` Sundar R Iyer
     [not found]                               ` <AANLkTinTdTp_X4lGtZ0hCaVJN5GmvI0tXR1RTRkRNkjN@mail.gmail.com>
2010-05-24  3:39                                 ` Mark Brown
2010-05-26  8:33                                   ` Sundar R IYER
2010-05-26 21:07                                     ` Mark Brown
2010-05-27  3:01                                       ` Paul Mundt
2010-05-27  6:51                                         ` Mark Brown
2010-05-17 20:20               ` Fwd: " 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=1274115886.2698.22.camel@finisterre.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=STEricsson_nomadik_linux@list.st.com \
    --cc=armando.visconti@st.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=sundar.iyer@stericsson.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 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®