public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/5] drivers: Add boot constraints core
Date: Fri, 30 Jun 2017 09:42:11 +0530	[thread overview]
Message-ID: <20170630041211.GX29665@vireshk-i7> (raw)
In-Reply-To: <CAGb2v67hxVciKFLD=8pgfm+UJ1i2Zb0aByTEa556O5uGcX7Oug@mail.gmail.com>

On 30-06-17, 12:05, Chen-Yu Tsai wrote:
> On Fri, Jun 30, 2017 at 11:55 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 30-06-17, 11:33, Chen-Yu Tsai wrote:
> >> AFAIK regulator constraints are supposed to satisfy all users of it.
> >
> > Right.
> >
> >> >> >Let me try with an example. A regulator is shared between LCD and DMA
> >> >> >controller.
> >> >> >
> >> >> >Operable ranges of the regulator: 1.8 - 3.0 V
> >> >> >Range required by LCD: 2.0 - 3.0 V
> >> >> >Range required by DMA: 1.8 - 2.5 V
> >>
> >> So for the example here, the regulator constraint should be 2.5 - 3.0 V,
> >> or the intersection of all voltage requirements.
> >
> > Had a look at regulator_check_consumers() and the range selected by it
> > is the *highest* min_uV and *lowest* max_uV, to find that intersection
> > point.
> >
> > For LCD: min_uV = 2.0 V, max_uV = 3.0 V
> > For DMA: min_uV = 1.8 V, max_uV = 2.5 V
> >
> > Highest min_uV = 2.0 V
> > Lowest max_uV = 2.5 V
> >
> > And so I mentioned the regulator's final range (that satisfies all
> > consumers) is 2 - 2.5 V.
> >
> > Why do you say it should be 2.5 - 3.0 V ?
> 
> You are right. It should be 2.0 - 2.5 V. Haven't had my coffee this
> morning. :(

And I was worrying if I had something else in my coffee :)

> I also want to mention that for DT based platforms, this constraint
> should already be set in the device tree for the regulator, so the
> scenario where DMA comes up and sets a voltage level that LCD cannot
> use should not even be possible.

Yes, such constraints are already present. But the problem (this
series is trying to solve) is that the kernel doesn't know if the LCD
is already powered ON. And so when DMA gets probed first, the kernel
thinks that DMA is the only user of the regulator and the voltage is
set to 1.8-2.5 V. And so this series is somehow trying to make the
kernel aware about the constraints of the LCD controller which was
enabled in the bootloader.

-- 
viresh

  reply	other threads:[~2017-06-30  4:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 10:26 [RFC 0/5] drivers: Add boot constraints core Viresh Kumar
2017-06-28 10:26 ` [RFC 1/5] " Viresh Kumar
2017-06-28 15:55   ` Randy Dunlap
2017-06-29  3:51     ` Viresh Kumar
2017-06-29 12:50       ` Russell King - ARM Linux
2017-06-29 14:49         ` Viresh Kumar
2017-06-28 10:26 ` [RFC 2/5] drivers: boot_constraint: Add support for supply constraints Viresh Kumar
2017-06-28 10:26 ` [RFC 3/5] drivers: boot_constraint: Add boot_constraints_disable kernel parameter Viresh Kumar
2017-06-28 15:51   ` Randy Dunlap
2017-06-28 10:26 ` [RFC 4/5] drivers: boot_constraint: Add debugfs support Viresh Kumar
2017-06-28 15:46   ` Randy Dunlap
2017-06-29  4:11     ` Viresh Kumar
2017-06-28 10:26 ` [RFC 5/5] drivers: Code to test boot constraints Viresh Kumar
2017-06-29 12:40 ` [RFC 0/5] drivers: Add boot constraints core Enrico Weigelt, metux IT consult
2017-06-29 14:47   ` Viresh Kumar
2017-06-29 15:06     ` Enrico Weigelt, metux IT consult
2017-06-30  3:16       ` Viresh Kumar
2017-06-30  3:33         ` Chen-Yu Tsai
2017-06-30  3:55           ` Viresh Kumar
2017-06-30  4:05             ` Chen-Yu Tsai
2017-06-30  4:12               ` Viresh Kumar [this message]
2017-06-30  4:22                 ` Chen-Yu Tsai
2017-06-30  5:12                   ` Viresh Kumar
2017-06-30  6:36                     ` Chen-Yu Tsai
2017-06-30  8:43                       ` Viresh Kumar
2017-06-30 12:10                         ` Mark Brown
2017-07-03  6:15                           ` Viresh Kumar
2017-07-03 15:07                             ` Mark Brown
2017-07-04  6:45                               ` Viresh Kumar
2017-06-30 12:12                   ` Mark Brown
2017-06-29 12:49 ` Russell King - ARM Linux
2017-06-29 13:05   ` Enrico Weigelt, metux IT consult
2017-06-29 14:58   ` Viresh Kumar
2017-06-29 15:43     ` Russell King - ARM Linux
2017-06-29 21:00       ` Stephen Boyd
2017-07-05 22:07         ` Rob Clark
2017-07-07 22:39           ` Stephen Boyd

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=20170630041211.GX29665@vireshk-i7 \
    --to=viresh.kumar@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