All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Tim Kryger <tim.kryger@gmail.com>, Mark Brown <broonie@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Chris Ball <chris@printf.net>,
	Seungwon Jeon <tgih.jun@samsung.com>,
	Haijun Zhang <Haijun.Zhang@freescale.com>,
	Doug Anderson <dianders@chromium.org>,
	Olof Johansson <olof@lixom.net>,
	Yuvaraj Kumar C D <yuvaraj.cd@gmail.com>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.
Date: Fri, 15 Aug 2014 09:48:43 +0200	[thread overview]
Message-ID: <53EDBB5B.4000209@collabora.co.uk> (raw)
In-Reply-To: <CAD7vxxLHtk2ywHGoBtDp6x3-5BtDdaFnCdc_pfgMwq63Cg8Qow@mail.gmail.com>

Hello Tim,

On 08/15/2014 07:36 AM, Tim Kryger wrote:
> On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown <broonie@kernel.org> wrote:
> 
>> Right, there's two things going on here.  One is that as you describe we
>> shouldn't be putting constraints in .dtsi files if we don't know they're
>> OK for a given board.  The other thing is that on this particular board
>> it turns out that there's no support for varying the voltages at all so
>> it doesn't make sense to have to specify a range, there's only one value
>> anyway so the software really should be able to figure out that fixed
>> value all by itself.
> 
> If constraints are truly irrelevant when the voltage supplied to
> consumers is fixed, why doesn't regulator_list_voltage honor this
> exemption and skip the voltage filtering that uses (potentially
> unspecified) constraints when output is entirely determined by a
> parent (or grandparent) supply that can't change its voltage?
>

I had a similar thought before and proposed the patch:

"[RFC 3/5] regulator: core: Only apply constraints if available on list
voltage" [0].

But then Mark explained to me that this is wrong since in that case
regulator_list_voltage() will list voltages that can't really be set [1].

But now I wonder why regulator_list_voltage() even list the voltage for
fixed regulators (desc->fixed_uV) since they don't have the ability to
vary voltage. The regulator_list_voltage() documentation says:

"Returns a voltage that can be passed to @regulator_set_voltage(), zero if
this selector code can't be used on this system, or a negative errno."

But in the case of fixed regulators, it is actually listing a voltage that
can't be selected. Although regulator_set_voltage() checks if the desired
voltage is equal to the regulator min_uV and max_uV and just exits in that
case, it feels wrong to list the voltage for a fixed regulators.

regulator_list_voltage() only works because of the way we define the
generic fixed voltage regulators and that is assuming that
"regulator-min-microvolt" and "regulator-max-microvolt" DT properties
being the same means that the regulator is fixed.

This is kind of unfortunate, maybe it would had been better to define it
explicitly using a "regulator-fixed-microvolt" or something. If we had
such a DT property, then constraints wouldn't had been set for fixed
regulators and regulator_list_voltage() wouldn't list its voltage neither.

> It seems odd to make callers be the ones to handle this subtlety.
> 

If regulator_list_voltage() didn't list the voltage for fixed regulators,
then this subtlety should had been handled by callers before but they
didn't because they rely on regulator_list_voltage() to always return a
voltage even for fixed regulators.

> Thanks,
> Tim Kryger
> 

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/7/29/418
[1]: https://lkml.org/lkml/2014/7/29/453

  reply	other threads:[~2014-08-15  7:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-14 12:39 [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty Javier Martinez Canillas
2014-08-14 14:13 ` Tim Kryger
2014-08-14 15:19   ` Mark Brown
2014-08-15  5:36     ` Tim Kryger
2014-08-15  7:48       ` Javier Martinez Canillas [this message]
2014-08-15  9:55         ` Mark Brown
2014-08-15 11:13           ` Javier Martinez Canillas
2014-08-15 14:51           ` Ulf Hansson
2014-08-16 12:59             ` Mark Brown
2014-08-19 11:29             ` Javier Martinez Canillas
2014-08-19 12:43               ` Ulf Hansson
2014-08-19 12:54                 ` Javier Martinez Canillas
2014-08-15 14:19         ` Tim Kryger
2014-08-15 22:29           ` Mark Brown
2014-08-17 17:11             ` Tim Kryger
2014-08-18 13:18               ` Mark Brown
2014-08-15  8:59       ` Mark Brown
2014-08-14 15:29   ` Javier Martinez Canillas
2014-08-19 12:51 ` Ulf Hansson

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=53EDBB5B.4000209@collabora.co.uk \
    --to=javier.martinez@collabora.co.uk \
    --cc=Haijun.Zhang@freescale.com \
    --cc=broonie@kernel.org \
    --cc=chris@printf.net \
    --cc=dianders@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=tgih.jun@samsung.com \
    --cc=tim.kryger@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --cc=yuvaraj.cd@gmail.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.