public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Taras Kondratiuk <taras@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: <lgirdwood@gmail.com>, <rjw@sisk.pl>, <viresh.kumar@linaro.org>,
	<shawn.guo@linaro.org>, <cpufreq@vger.kernel.org>,
	<linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Philip Rakity <prakity@nvidia.com>,
	Eric Miao <eric.y.miao@gmail.com>,
	"grygorii.strashko" <grygorii.strashko@ti.com>,
	Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
Subject: Re: [RFC PATCH 1/2] regulator: core: Add regulator_set_voltage_min()
Date: Tue, 23 Apr 2013 14:44:58 +0300	[thread overview]
Message-ID: <5176743A.9070201@ti.com> (raw)
In-Reply-To: <20130423084838.GB5019@opensource.wolfsonmicro.com>

On 04/23/2013 11:48 AM, Mark Brown wrote:
> On Mon, Apr 22, 2013 at 07:49:37PM +0300, Taras Kondratiuk wrote:
>
>> Yeah. Sure 4kV is not a real request, but
>> max will be limited by system constrains.
>> According to regulator_set_voltage() documentation
>> system constraints should be set before calling this function,
>> so I assume I can rely on them. No?
>> Another possible implementation is below, but prefer initial one.
> I just don't see any reason for this API.  The driver setting the
> voltage ought to have some idea of what the chip limits are too for
> safety.
Let's take an example.
One regulator supplies CPU and GPU inside of SoC.
                       +-------------+
                       | SoC         |
               VDD_CPU |    +-----+  |
             +------------->| CPU |  |
+-------+   |         |    +-----+  |
| Reg X |---+         |             |
+------ +   | VDD_GPU |    +-----+  |
             +------------->| GPU |  |
                       |    +-----+  |
                       +-------------+

GPU voltage is regulated by some devfreq driver.
CPU voltage is regulated by generic cpufreq-cpu0 driver.
Both drivers know only about their operational points.
They don't know anything about chip limits.

I see two options here:
1. Pass somehow chip limits to drivers so they can limit their request.
    Pros: No need for regulator_set_voltage_min()
    Cons: a) Need to pass info about chip limits to driver. New API?
          b) CPU and GPU may have different limits,
             so after very first request voltage may violate
             CPU or GPU range.
2. Define chip limits in Reg X constraints.
    Pros: Limits will be applied to driver's request transparently.
          No need to pass info about limits to driver.
          Limits are set before the first request, so no violation.
    Cons: regulator_set_voltage_min() is needed.

IMHO option #2 is better.
Do you see other ways?

-- 
BR
Taras Kondratiuk | GlobalLogic


  reply	other threads:[~2013-04-23 11:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-19 11:55 [RFC PATCH 0/2] cpufreq/regulator: Limit minimum voltage only Taras Kondratiuk
2013-04-19 11:55 ` [RFC PATCH 1/2] regulator: core: Add regulator_set_voltage_min() Taras Kondratiuk
2013-04-22 13:19   ` Mark Brown
2013-04-22 16:49     ` Taras Kondratiuk
2013-04-23  8:48       ` Mark Brown
2013-04-23 11:44         ` Taras Kondratiuk [this message]
2013-04-23 13:45           ` Mark Brown
2013-04-23 18:45             ` Taras Kondratiuk
2013-04-24  9:38               ` Mark Brown
2013-04-19 11:55 ` [RFC PATCH 2/2] cpufreq: cpufreq-cpu0: Limit minimum voltage only Taras Kondratiuk
2013-04-19 16:21 ` [RFC PATCH 0/2] cpufreq/regulator: " Nishanth Menon
2013-04-20  0:24   ` Kondratiuk, Taras
2013-04-22  6:11     ` Bedia, Vaibhav
2013-04-22 13:25       ` Mark Brown
2013-04-22 16:25       ` Taras Kondratiuk

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=5176743A.9070201@ti.com \
    --to=taras@ti.com \
    --cc=andrii.tseglytskyi@ti.com \
    --cc=broonie@kernel.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=eric.y.miao@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=prakity@nvidia.com \
    --cc=rjw@sisk.pl \
    --cc=shawn.guo@linaro.org \
    --cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox