From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] regulator: Enhance AXP209 DT support
Date: Tue, 3 Jun 2014 15:09:38 +0200 [thread overview]
Message-ID: <20140603130938.GI27722@lukather> (raw)
In-Reply-To: <20140528184752.GA22488@sirena.org.uk>
On Wed, May 28, 2014 at 07:47:52PM +0100, Mark Brown wrote:
> On Wed, May 28, 2014 at 07:11:04PM +0200, Maxime Ripard wrote:
>
> > This patchset modifies the regulator core and axp209 regulator driver
> > to be able to set in each regulators sub-node the supply, that should
> > be possible, given that it's documented as such in the bindings, but
>
> It is? We should fix that.
>From Documentation/devicetree/bindings/regulator/regulator.txt:
- <name>-supply: phandle to the parent supply/regulator node
With the example:
xyzreg: regulator at 0 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <2500000>;
regulator-always-on;
vin-supply = <&vin>;
};
If not right, then it's strongly misleading.
>
> > is not at the moment, since whenever looking up the supply in the DT,
> > of_get_regulator will always look into the parent's device of_node
> > pointer.
>
> > This leads to a common pattern accross the regulators to have multiple
> > supply in the main device node, while it would be more intuitive yet
> > follow the documented bindings to look into the regulator sub-nodes
> > first.
>
> No, we've been round this loop several times before. This reduces
> consistency in how we map supplies since the user has to work out which
> subnode the supply is associated with and what it's called there instead
> of being able to just look at the schematic and translate the supply
> name into a property name. It also means you have to map supplies into
> multiple child nodes if the same supply is used in multiple places.
Which might be what your schematics actually show. If you have a
single input pin for each regulator, even if the name changes from one
pin to another, you're still pretty much in this kind of construct.
> The idea is that supplies that happen to be used to supply a regulator
> don't get treated any differently to any other supply and that we do
> that at the physical package level.
In our case, each regulator found in the PMIC has an input of its own,
which is a very similar setup than the one found in a gpio-controlled
regulator for example.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140603/73276233/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Mark Brown <broonie@kernel.org>
Cc: carlo@caione.org, Boris Brezillon <boris@free-electrons.com>,
lgirdwood@gmail.com, lee.jones@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kevin.z.m.zh@gmail.com,
sunny@allwinnertech.com, shuge@allwinnertech.com,
zhuzhenhua@allwinnertech.com
Subject: Re: [PATCH 0/5] regulator: Enhance AXP209 DT support
Date: Tue, 3 Jun 2014 15:09:38 +0200 [thread overview]
Message-ID: <20140603130938.GI27722@lukather> (raw)
In-Reply-To: <20140528184752.GA22488@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]
On Wed, May 28, 2014 at 07:47:52PM +0100, Mark Brown wrote:
> On Wed, May 28, 2014 at 07:11:04PM +0200, Maxime Ripard wrote:
>
> > This patchset modifies the regulator core and axp209 regulator driver
> > to be able to set in each regulators sub-node the supply, that should
> > be possible, given that it's documented as such in the bindings, but
>
> It is? We should fix that.
From Documentation/devicetree/bindings/regulator/regulator.txt:
- <name>-supply: phandle to the parent supply/regulator node
With the example:
xyzreg: regulator@0 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <2500000>;
regulator-always-on;
vin-supply = <&vin>;
};
If not right, then it's strongly misleading.
>
> > is not at the moment, since whenever looking up the supply in the DT,
> > of_get_regulator will always look into the parent's device of_node
> > pointer.
>
> > This leads to a common pattern accross the regulators to have multiple
> > supply in the main device node, while it would be more intuitive yet
> > follow the documented bindings to look into the regulator sub-nodes
> > first.
>
> No, we've been round this loop several times before. This reduces
> consistency in how we map supplies since the user has to work out which
> subnode the supply is associated with and what it's called there instead
> of being able to just look at the schematic and translate the supply
> name into a property name. It also means you have to map supplies into
> multiple child nodes if the same supply is used in multiple places.
Which might be what your schematics actually show. If you have a
single input pin for each regulator, even if the name changes from one
pin to another, you're still pretty much in this kind of construct.
> The idea is that supplies that happen to be used to supply a regulator
> don't get treated any differently to any other supply and that we do
> that at the physical package level.
In our case, each regulator found in the PMIC has an input of its own,
which is a very similar setup than the one found in a gpio-controlled
regulator for example.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-06-03 13:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 17:11 [PATCH 0/5] regulator: Enhance AXP209 DT support Maxime Ripard
2014-05-28 17:11 ` Maxime Ripard
2014-05-28 17:11 ` [PATCH 1/5] regulator: Allow to pass the device node to regulator_dev_lookup Maxime Ripard
2014-05-28 17:11 ` Maxime Ripard
2014-05-28 17:11 ` [PATCH 2/5] regulator: Pass the config " Maxime Ripard
2014-05-28 17:11 ` Maxime Ripard
2014-05-28 17:11 ` [PATCH 3/5] regulator: axp20x: Update the bindings to use a local parent regulator Maxime Ripard
2014-05-28 17:11 ` Maxime Ripard
2014-05-28 18:50 ` Mark Brown
2014-05-28 18:50 ` Mark Brown
2014-06-03 13:12 ` Maxime Ripard
2014-06-03 13:12 ` Maxime Ripard
2014-06-03 14:43 ` Mark Brown
2014-06-03 14:43 ` Mark Brown
2014-06-05 14:27 ` Maxime Ripard
2014-06-05 14:27 ` Maxime Ripard
2014-06-05 15:49 ` Mark Brown
2014-06-05 15:49 ` Mark Brown
2014-06-06 16:05 ` Maxime Ripard
2014-06-06 16:05 ` Maxime Ripard
2014-08-16 13:58 ` Mark Brown
2014-08-16 13:58 ` Mark Brown
2014-05-28 17:11 ` [PATCH 4/5] mfd: axp209x: Drop the parent supplies field Maxime Ripard
2014-05-28 17:11 ` Maxime Ripard
2014-05-29 7:37 ` Lee Jones
2014-05-29 7:37 ` Lee Jones
2014-05-28 17:11 ` [PATCH 5/5] ARM: sun7i: cubieboard2: Enable the AXP209 Maxime Ripard
2014-05-28 17:11 ` Maxime Ripard
2014-05-28 18:47 ` [PATCH 0/5] regulator: Enhance AXP209 DT support Mark Brown
2014-05-28 18:47 ` Mark Brown
2014-06-03 13:09 ` Maxime Ripard [this message]
2014-06-03 13:09 ` Maxime Ripard
2014-06-03 13:56 ` Mark Brown
2014-06-03 13:56 ` Mark Brown
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=20140603130938.GI27722@lukather \
--to=maxime.ripard@free-electrons.com \
--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 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.