From: Stephen Warren <swarren@wwwdotorg.org>
To: Alex Courbot <acourbot@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>,
Thierry Reding <thierry.reding@avionic-design.de>,
Simon Glass <sjg@chromium.org>,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Arnd Bergmann <arnd@arndb.de>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
Date: Tue, 31 Jul 2012 10:34:34 -0600 [thread overview]
Message-ID: <5018091A.2020606@wwwdotorg.org> (raw)
In-Reply-To: <5017B434.2010706@nvidia.com>
On 07/31/2012 04:32 AM, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
...
>> If the nodes have a unit address (i.e. end in "@n"), which they will
>> have to if all named "step" and there's more than one of them, then they
>> will need a matching reg property. Equally, the parent node will need
>> #address-cells and #size-cells too. So, the last couple lines would be:
>>
>> power-on-sequence {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> step@0 {
>> reg = <0>;
>
> That's precisely what I would like to avoid - I don't need the steps to
> be numbered and I certainly have no use for a reg property. Isn't there
> a way to make it simpler?
You may be able to get away without using the reg values in the code.
However, to have a semantically correct device tree, you really do need
all of those properties.
That said, I think you might need to use the reg values in code. I
believe there's no guarantee of the order in which nodes enumerate in
device tree, so you need to look at the reg property in order to find
the order in which to execute the nodes/steps.
... although perhaps the desire to avoid a dependency on DT ordering
applies more to the order in which devices instantiated from DT get
probed, rather than the order of low-level node enumeration, so I may be
wrong here. I've definitely seen Grant caution people not to rely on
device probe order, but perhaps he didn't make the same comment about
node order.
next prev parent reply other threads:[~2012-07-31 16:34 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-27 12:05 [RFC][PATCH v3 0/3] Power sequences with PWM and DT support Alexandre Courbot
2012-07-27 12:05 ` [RFC][PATCH v3 1/3] runtime interpreted power sequences Alexandre Courbot
2012-07-27 18:19 ` Greg Kroah-Hartman
2012-07-30 1:51 ` Alex Courbot
2012-07-30 2:40 ` Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences) Anton Vorontsov
2012-07-30 20:59 ` Rafael J. Wysocki
2012-08-01 0:51 ` Anton Vorontsov
2012-08-06 8:45 ` Pihet-XID, Jean
2012-07-27 18:20 ` [RFC][PATCH v3 1/3] runtime interpreted power sequences Greg Kroah-Hartman
2012-07-30 11:00 ` Simon Glass
2012-07-31 8:37 ` Alex Courbot
2012-07-31 9:13 ` Thierry Reding
2012-07-31 10:11 ` Alex Courbot
2012-07-31 10:46 ` Thierry Reding
2012-07-31 14:23 ` Mark Brown
2012-07-30 11:33 ` Thierry Reding
2012-07-31 9:51 ` Alex Courbot
2012-07-31 10:19 ` Thierry Reding
2012-08-01 2:50 ` Alex Courbot
2012-08-01 7:17 ` Thierry Reding
2012-07-31 14:11 ` Mark Brown
2012-07-30 15:44 ` Rob Herring
2012-07-30 15:47 ` Mark Brown
2012-07-31 9:16 ` Thierry Reding
2012-07-30 22:26 ` Stephen Warren
2012-07-31 10:15 ` Alex Courbot
2012-07-30 22:45 ` Stephen Warren
2012-07-31 10:32 ` Alex Courbot
2012-07-31 10:56 ` Thierry Reding
2012-07-31 12:22 ` Mitch Bradley
2012-07-31 12:38 ` Thierry Reding
2012-07-31 12:55 ` Mitch Bradley
2012-08-01 1:47 ` Alex Courbot
2012-08-01 2:15 ` Mitch Bradley
2012-08-01 1:42 ` Alex Courbot
2012-07-31 14:13 ` Mark Brown
2012-07-31 14:22 ` Thierry Reding
2012-07-31 14:26 ` Mark Brown
2012-07-31 14:32 ` Thierry Reding
2012-07-31 15:39 ` Mark Brown
2012-07-31 16:19 ` Greg Kroah-Hartman
2012-07-31 16:22 ` Mark Brown
2012-07-31 16:42 ` Greg Kroah-Hartman
2012-07-31 16:50 ` Mark Brown
2012-08-01 7:41 ` Thierry Reding
2012-08-01 13:26 ` Mark Brown
2012-08-01 13:38 ` Thierry Reding
2012-08-01 13:55 ` Mark Brown
2012-08-01 14:01 ` Thierry Reding
2012-07-31 16:34 ` Stephen Warren [this message]
2012-08-02 8:00 ` Alex Courbot
2012-08-02 8:21 ` Thierry Reding
2012-08-02 8:27 ` Alex Courbot
2012-08-02 8:45 ` Thierry Reding
2012-08-02 9:20 ` Alex Courbot
2012-08-02 18:11 ` Mark Brown
2012-08-03 1:15 ` Alex Courbot
2012-08-04 14:12 ` Mark Brown
2012-08-06 2:27 ` Alex Courbot
2012-08-06 16:16 ` Stephen Warren
2012-08-07 5:10 ` Alex Courbot
2012-07-27 12:05 ` [RFC][PATCH v3 2/3] pwm_backlight: use " Alexandre Courbot
2012-07-27 12:05 ` [RFC][PATCH v3 3/3] tegra: add pwm backlight device tree nodes Alexandre Courbot
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=5018091A.2020606@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=acourbot@nvidia.com \
--cc=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
--cc=thierry.reding@avionic-design.de \
/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
Powered by JetHome