linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ulf.hansson@linaro.org (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/4] mmc: core: Add mmc_regulator_set_vqmmc()
Date: Thu, 19 Mar 2015 12:14:11 +0100	[thread overview]
Message-ID: <CAPDyKFrkznbW7k_=BDo99jJhWzDbUgbeU+MXWB_E_UWXh=56Eg@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=X=1=AnXCGgWWkJDcHLO-MfVqsSB2aJxi3WOgWJhD_ggA@mail.gmail.com>

On 19 March 2015 at 05:09, Doug Anderson <dianders@chromium.org> wrote:
> Ulf,
>
> On Tue, Mar 17, 2015 at 3:23 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> This will get us within .3V of whatever vmmc is.  If vmmc is 3.3V, it
>>> will allow vqmmc of 3.0V - 3.6V.
>>>
>>> This _seems_ sane to me and given any sane system design we should be
>>> fine here, I think.  I can't see someone designing a system where
>>> vqmmc was not within .3V of vmmc, can you?  If we think someone will
>>> actually build a system where vmmc is 3.3V and vqmmc can't go higher
>>> than 2.7V then we'll either need to increase the tolerance here or add
>>> a new asymmetric system call like my original patches did.
>>
>> I know about SoC that supports 3.4V vmmc and 2.9V vqmmc.
>>
>> What I think we need is the option to have a policy here. We need to
>> allow voltage levels stated by the spec and at the same time try chose
>> the one best suited. That's not being accomplished here.
>>
>> Moreover, I wonder whether it's okay (from spec perspective) to have
>> vqmmc at a higher voltage level than vmmc. I don't think that's
>> allowed, but I might be wrong.
>
> OK, so sounds like I need to add a regulator_set_voltage_tol2()
> function that takes in an upper tolerance and a lower.  We can use the
> same rough implementation in the core we have today (if Mark is OK
> with that) with regulator_set_voltage_tol() but just allow it to be
> asymmetric.

Agree. Moreover we need that API to also pick the closest value to
target, when trying the range "target->minimum". I also believe it
would be good to allow both upper and lower limits to be zero.

If Mark disagrees with this approach, we will have to deal with all
the magic inside the mmc core layer. Very much similar how
mmc_regulator_get_ocrmask() is implemented.

Kind regards
Uffe

>
> From what I see in the spec for 3.3V cards are supposed to react to a
> high signal that is .625 * VDD - VDD + .3
>
>
> I might not be able to get to this till next week, though...
>
> -Doug

  reply	other threads:[~2015-03-19 11:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-11 22:15 [PATCH v4 1/4] mmc: dw_mmc: Don't try to enable the CD until we're sure we're not deferring Doug Anderson
2015-03-11 22:15 ` [PATCH v4 2/4] mmc: core: Add mmc_regulator_set_vqmmc() Doug Anderson
2015-03-16 14:05   ` Ulf Hansson
2015-03-16 15:12     ` Doug Anderson
2015-03-17 10:23       ` Ulf Hansson
2015-03-17 10:38         ` Mark Brown
2015-03-17 11:28           ` Ulf Hansson
2015-03-19  4:09         ` Doug Anderson
2015-03-19 11:14           ` Ulf Hansson [this message]
2015-03-19 11:36             ` Mark Brown
2015-03-20 10:55               ` Ulf Hansson
2015-03-20 11:28                 ` Mark Brown
2015-04-07 20:05                   ` Doug Anderson
2015-04-08 11:28                     ` Mark Brown
2015-03-11 22:15 ` [PATCH v4 3/4] mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch Doug Anderson
2015-03-11 22:15 ` [PATCH v4 4/4] ARM: dts: Specify VMMC and VQMMC on rk3288-evb Doug Anderson
2015-03-11 23:30   ` Heiko Stuebner
2015-04-07 21:37     ` Heiko Stübner
2015-03-13 11:32 ` [PATCH v4 1/4] mmc: dw_mmc: Don't try to enable the CD until we're sure we're not deferring Jaehoon Chung
2015-03-13 12:10   ` Heiko Stuebner
2015-03-16  2:09     ` Jaehoon Chung
2015-03-27  5:55 ` Jaehoon Chung
2015-03-27 15:46   ` Doug Anderson

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='CAPDyKFrkznbW7k_=BDo99jJhWzDbUgbeU+MXWB_E_UWXh=56Eg@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).