From: marvin24@gmx.de (Marc Dietrich)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: dt: tegra: paz00: add regulators
Date: Sun, 24 Jun 2012 15:27:42 +0200 [thread overview]
Message-ID: <27366523.LjLfRK1TqH@ax5200p> (raw)
In-Reply-To: <20120624123151.GZ4037@opensource.wolfsonmicro.com>
On Sunday 24 June 2012 13:31:51 Mark Brown wrote:
> On Sun, Jun 24, 2012 at 02:01:58PM +0200, Marc Dietrich wrote:
> > On Sunday 24 June 2012 12:03:06 Mark Brown wrote:
> > > > > + regulator-name = "+3.3vs_ldo0";
> > > > > + regulator-max-microvolt = <3300000>;
> > >
> > > This is one example, it looks like the rail needs to be fixed to 3.3V.
> >
> > I think nowhere in the code a regulator (beside sm*) is programmed to some
> > different value that the maximum given here (this is not the maximum the
> > regulator can provide). I never understood why the kernel code always sets
> > the regulator to the maximum value if no other value was specified. IMHO,
> > there should be some initial value, e.g. regulator-default-microvolt, as
> > the original driver (from 2.6.32 ages) did. This way the maximum value
> > can be set
> That's *never* been in mainline, and nobody even bothered trying to
> submit it.
which was the best thing to do ;-)
> > to the hw limits, but maybe this is a bit dangerous.
>
> One of two things should be happening. Either a single voltage is
> specified (in which case that voltage will be configured in the
I'm not an expert on this, but it seems to me that only sm0 and sm1 should be
changeable (and some rail called vdd_aon, which seems to be ldo2 in case of
paz00 connected to the rtc). So, all others can be constant voltage. Maybe
Stephen can comment on the actual requirements (also for the other boards
which may have similar layout).
Marc
> hardware and consumer drivers can't change anything) or a voltage range
> is specified (in which case the consumers are expected to manage the
> voltage and the most the API should do is bring the voltage within the
> limits given, though I don't think that's actually implemented yet).
> Specifying an initial value within the range should at best be redundant
> as the drivers that are actively managing their voltages will be
> overriding it anyway.
>
> We certainly shouldn't be specifying the limits of the regulator itself
> as normally the board design will be much more constrained than the
> regulator itself and like I said it's stupid to have to cut'n'paste the
> numbers out of the driver into the machine constraints. We should
> instead be specifying the constraints the system is designed to operate
> in. Chances are that if nothing is able to actively manage the voltage
> it's not in fact safe to change the voltage at all and therefore the
> constraints should specify only one voltage.
>
> In the above case the fact that the supply is named "+3.3vs_ldo0" seems
> like a fairly clear sign that the board has been designed for this to
> operate at 3.3V which makes the fact that the constraints go down to
> 1.25V seem at best odd.
next prev parent reply other threads:[~2012-06-24 13:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 23:14 [PATCH 1/3] ARM: dt: tegra: seaboard: add regulators Stephen Warren
2012-06-22 23:14 ` [PATCH 2/3] ARM: dt: tegra: ventana: " Stephen Warren
2012-06-22 23:14 ` [PATCH 3/3] ARM: dt: tegra: paz00: " Stephen Warren
2012-06-23 16:35 ` Marc Dietrich
2012-06-24 11:03 ` Mark Brown
2012-06-24 12:01 ` Marc Dietrich
2012-06-24 12:31 ` Mark Brown
2012-06-24 13:27 ` Marc Dietrich [this message]
2012-06-25 8:46 ` Mark Brown
2012-06-25 10:45 ` Marc Dietrich
2012-06-25 11:07 ` Thierry Reding
2012-06-26 22:35 ` Stephen Warren
2012-06-26 23:02 ` Mark Brown
2012-06-26 23:16 ` Stephen Warren
2012-06-29 17:32 ` Stephen Warren
2012-06-30 11:45 ` Mark Brown
2012-06-25 6:24 ` [PATCH 1/3] ARM: dt: tegra: seaboard: " Laxman Dewangan
2012-06-25 15:12 ` Stephen Warren
2012-06-25 15:24 ` Laxman Dewangan
2012-06-25 15:36 ` Stephen Warren
2012-06-25 22:26 ` Mark Brown
2012-06-25 23:09 ` Stephen Warren
2012-06-26 6:38 ` Laxman Dewangan
2012-06-26 8:52 ` Mark Brown
2012-07-10 11:59 ` Laxman Dewangan
2012-07-10 13:44 ` Mark Brown
2012-07-10 13:44 ` Laxman Dewangan
2012-07-10 13:53 ` Mark Brown
2012-07-10 15:04 ` Laxman Dewangan
2012-07-10 15:42 ` Mark Brown
2012-07-10 16:39 ` Laxman Dewangan
2012-07-10 16:52 ` Mark Brown
2012-07-10 16:53 ` Laxman Dewangan
2012-07-10 17:01 ` Mark Brown
2012-07-11 10:02 ` Laxman Dewangan
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=27366523.LjLfRK1TqH@ax5200p \
--to=marvin24@gmx.de \
--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).