From: Alex Courbot <acourbot@nvidia.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
Date: Wed, 21 Nov 2012 01:56:36 +0000 [thread overview]
Message-ID: <4316169.5QXVzv7peZ@percival> (raw)
In-Reply-To: <50AB9832.90709@ti.com>
Hi Tomi,
On Tuesday 20 November 2012 22:48:18 Tomi Valkeinen wrote:
> I guess there's a reason, but the above looks a bit inconsistent. For
> gpio you define the gpio resource inside the step. For power and pwm the
> resource is defined before the steps. Why wouldn't "pwm = <&pwm 2
> 5000000>;" work in step2?
That's mostly a framework issue. Most frameworks do not export a function that
allow to dereference a phandle - they expect resources to be declared right
under the device node and accessed by name through foo_get(device, name). So
using phandles in power sequences would require to export these additional
functions and also opens the door to some inconsistencies - for instance, your
PWM phandle could be referenced a second time in the sequence with a different
period - how do you know that these are actually referring the same PWM
device?
> > +When a power sequence is run, its steps is executed one after the other
> > until +one step fails or the end of the sequence is reached.
>
> The document doesn't give any hint of what the driver should do if
> running the power sequence fails. Run the "opposite" power sequence?
> Will that work for all resources? I'm mainly thinking of a case where
> each enable of the resource should be matched by a disable, i.e. you
> can't call disable if no enable was called.
We discussed that issue already (around v5 I think) and the conclusion was
that it should be up to the driver. When we simply enable/disable resources it
is easy to revert, but in the future non-boolean properties will likely be
introduced, and these cannot easily be reverted. Moreover some drivers might
have more complex recovery needs. This deserves more discussion I think, as
I'd like to have some "generic" recovery mechanism that covers most of the
cases.
Alex.
WARNING: multiple messages have this Message-ID (diff)
From: Alex Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: Anton Vorontsov
<cbouatmailru-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
Date: Wed, 21 Nov 2012 10:56:36 +0900 [thread overview]
Message-ID: <4316169.5QXVzv7peZ@percival> (raw)
In-Reply-To: <50AB9832.90709-l0cyMroinI0@public.gmane.org>
Hi Tomi,
On Tuesday 20 November 2012 22:48:18 Tomi Valkeinen wrote:
> I guess there's a reason, but the above looks a bit inconsistent. For
> gpio you define the gpio resource inside the step. For power and pwm the
> resource is defined before the steps. Why wouldn't "pwm = <&pwm 2
> 5000000>;" work in step2?
That's mostly a framework issue. Most frameworks do not export a function that
allow to dereference a phandle - they expect resources to be declared right
under the device node and accessed by name through foo_get(device, name). So
using phandles in power sequences would require to export these additional
functions and also opens the door to some inconsistencies - for instance, your
PWM phandle could be referenced a second time in the sequence with a different
period - how do you know that these are actually referring the same PWM
device?
> > +When a power sequence is run, its steps is executed one after the other
> > until +one step fails or the end of the sequence is reached.
>
> The document doesn't give any hint of what the driver should do if
> running the power sequence fails. Run the "opposite" power sequence?
> Will that work for all resources? I'm mainly thinking of a case where
> each enable of the resource should be matched by a disable, i.e. you
> can't call disable if no enable was called.
We discussed that issue already (around v5 I think) and the conclusion was
that it should be up to the driver. When we simply enable/disable resources it
is easy to revert, but in the future non-boolean properties will likely be
introduced, and these cannot easily be reverted. Moreover some drivers might
have more complex recovery needs. This deserves more discussion I think, as
I'd like to have some "generic" recovery mechanism that covers most of the
cases.
Alex.
WARNING: multiple messages have this Message-ID (diff)
From: acourbot@nvidia.com (Alex Courbot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv9 1/3] Runtime Interpreted Power Sequences
Date: Wed, 21 Nov 2012 10:56:36 +0900 [thread overview]
Message-ID: <4316169.5QXVzv7peZ@percival> (raw)
In-Reply-To: <50AB9832.90709@ti.com>
Hi Tomi,
On Tuesday 20 November 2012 22:48:18 Tomi Valkeinen wrote:
> I guess there's a reason, but the above looks a bit inconsistent. For
> gpio you define the gpio resource inside the step. For power and pwm the
> resource is defined before the steps. Why wouldn't "pwm = <&pwm 2
> 5000000>;" work in step2?
That's mostly a framework issue. Most frameworks do not export a function that
allow to dereference a phandle - they expect resources to be declared right
under the device node and accessed by name through foo_get(device, name). So
using phandles in power sequences would require to export these additional
functions and also opens the door to some inconsistencies - for instance, your
PWM phandle could be referenced a second time in the sequence with a different
period - how do you know that these are actually referring the same PWM
device?
> > +When a power sequence is run, its steps is executed one after the other
> > until +one step fails or the end of the sequence is reached.
>
> The document doesn't give any hint of what the driver should do if
> running the power sequence fails. Run the "opposite" power sequence?
> Will that work for all resources? I'm mainly thinking of a case where
> each enable of the resource should be matched by a disable, i.e. you
> can't call disable if no enable was called.
We discussed that issue already (around v5 I think) and the conclusion was
that it should be up to the driver. When we simply enable/disable resources it
is easy to revert, but in the future non-boolean properties will likely be
introduced, and these cannot easily be reverted. Moreover some drivers might
have more complex recovery needs. This deserves more discussion I think, as
I'd like to have some "generic" recovery mechanism that covers most of the
cases.
Alex.
WARNING: multiple messages have this Message-ID (diff)
From: Alex Courbot <acourbot@nvidia.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Anton Vorontsov <cbouatmailru@gmail.com>,
Stephen Warren <swarren@nvidia.com>,
Thierry Reding <thierry.reding@avionic-design.de>,
Mark Zhang <markz@nvidia.com>,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
David Woodhouse <dwmw2@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.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>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Alexandre Courbot <gnurou@gmail.com>
Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
Date: Wed, 21 Nov 2012 10:56:36 +0900 [thread overview]
Message-ID: <4316169.5QXVzv7peZ@percival> (raw)
In-Reply-To: <50AB9832.90709@ti.com>
Hi Tomi,
On Tuesday 20 November 2012 22:48:18 Tomi Valkeinen wrote:
> I guess there's a reason, but the above looks a bit inconsistent. For
> gpio you define the gpio resource inside the step. For power and pwm the
> resource is defined before the steps. Why wouldn't "pwm = <&pwm 2
> 5000000>;" work in step2?
That's mostly a framework issue. Most frameworks do not export a function that
allow to dereference a phandle - they expect resources to be declared right
under the device node and accessed by name through foo_get(device, name). So
using phandles in power sequences would require to export these additional
functions and also opens the door to some inconsistencies - for instance, your
PWM phandle could be referenced a second time in the sequence with a different
period - how do you know that these are actually referring the same PWM
device?
> > +When a power sequence is run, its steps is executed one after the other
> > until +one step fails or the end of the sequence is reached.
>
> The document doesn't give any hint of what the driver should do if
> running the power sequence fails. Run the "opposite" power sequence?
> Will that work for all resources? I'm mainly thinking of a case where
> each enable of the resource should be matched by a disable, i.e. you
> can't call disable if no enable was called.
We discussed that issue already (around v5 I think) and the conclusion was
that it should be up to the driver. When we simply enable/disable resources it
is easy to revert, but in the future non-boolean properties will likely be
introduced, and these cannot easily be reverted. Moreover some drivers might
have more complex recovery needs. This deserves more discussion I think, as
I'd like to have some "generic" recovery mechanism that covers most of the
cases.
Alex.
next prev parent reply other threads:[~2012-11-21 1:56 UTC|newest]
Thread overview: 158+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-17 10:55 [PATCHv9 0/3] Runtime Interpreted Power Sequences Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` [PATCHv9 1/3] " Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 11:38 ` Anton Vorontsov
2012-11-17 11:38 ` Anton Vorontsov
2012-11-17 11:38 ` Anton Vorontsov
2012-11-19 2:29 ` Alex Courbot
2012-11-19 2:29 ` Alex Courbot
2012-11-19 2:29 ` Alex Courbot
2012-11-19 2:29 ` Alex Courbot
2012-11-19 2:32 ` Anton Vorontsov
2012-11-19 2:32 ` Anton Vorontsov
2012-11-19 2:32 ` Anton Vorontsov
2012-11-20 14:48 ` Tomi Valkeinen
2012-11-20 14:48 ` Tomi Valkeinen
2012-11-20 14:48 ` Tomi Valkeinen
2012-11-20 14:48 ` Tomi Valkeinen
2012-11-21 1:56 ` Alex Courbot [this message]
2012-11-21 1:56 ` Alex Courbot
2012-11-21 1:56 ` Alex Courbot
2012-11-21 1:56 ` Alex Courbot
2012-11-21 8:13 ` Tomi Valkeinen
2012-11-21 8:13 ` Tomi Valkeinen
2012-11-21 8:13 ` Tomi Valkeinen
2012-11-21 8:13 ` Tomi Valkeinen
2012-11-21 8:32 ` Alex Courbot
2012-11-21 8:32 ` Alex Courbot
2012-11-21 8:32 ` Alex Courbot
2012-11-21 8:32 ` Alex Courbot
2012-11-21 8:48 ` Tomi Valkeinen
2012-11-21 8:48 ` Tomi Valkeinen
2012-11-21 8:48 ` Tomi Valkeinen
2012-11-21 8:48 ` Tomi Valkeinen
2012-11-21 10:00 ` Alex Courbot
2012-11-21 10:00 ` Alex Courbot
2012-11-21 10:00 ` Alex Courbot
2012-11-22 13:01 ` Grant Likely
2012-11-22 13:01 ` Grant Likely
2012-11-22 13:01 ` Grant Likely
2012-11-22 13:01 ` Grant Likely
2012-11-20 21:54 ` Grant Likely
2012-11-20 21:54 ` Grant Likely
2012-11-20 21:54 ` Grant Likely
2012-11-20 21:54 ` Grant Likely
2012-11-21 1:31 ` Mark Brown
2012-11-21 1:31 ` Mark Brown
2012-11-21 1:31 ` Mark Brown
2012-11-21 16:44 ` Grant Likely
2012-11-21 16:44 ` Grant Likely
2012-11-21 16:44 ` Grant Likely
2012-11-22 8:57 ` Linus Walleij
2012-11-22 8:57 ` Linus Walleij
2012-11-22 8:57 ` Linus Walleij
2012-11-22 8:57 ` Linus Walleij
2012-11-22 9:55 ` Alexandre Courbot
2012-11-22 9:55 ` Alexandre Courbot
2012-11-22 9:55 ` Alexandre Courbot
2012-11-22 9:55 ` Alexandre Courbot
2012-11-23 1:44 ` Mark Brown
2012-11-23 1:44 ` Mark Brown
2012-11-23 1:44 ` Mark Brown
2012-11-21 4:23 ` Alex Courbot
2012-11-21 4:23 ` Alex Courbot
2012-11-21 4:23 ` Alex Courbot
2012-11-21 11:06 ` Tomi Valkeinen
2012-11-21 11:06 ` Tomi Valkeinen
2012-11-21 11:06 ` Tomi Valkeinen
2012-11-21 11:06 ` Tomi Valkeinen
2012-11-21 11:40 ` Thierry Reding
2012-11-21 11:40 ` Thierry Reding
2012-11-21 11:40 ` Thierry Reding
2012-11-21 11:40 ` Thierry Reding
2012-11-21 12:04 ` Tomi Valkeinen
2012-11-21 12:04 ` Tomi Valkeinen
2012-11-21 12:04 ` Tomi Valkeinen
2012-11-21 13:00 ` Thierry Reding
2012-11-21 13:00 ` Thierry Reding
2012-11-21 13:00 ` Thierry Reding
2012-11-21 13:32 ` Tomi Valkeinen
2012-11-21 13:32 ` Tomi Valkeinen
2012-11-21 13:32 ` Tomi Valkeinen
2012-11-21 13:32 ` Tomi Valkeinen
2012-11-21 15:02 ` Alexandre Courbot
2012-11-21 15:02 ` Alexandre Courbot
2012-11-21 15:02 ` Alexandre Courbot
2012-11-21 15:02 ` Alexandre Courbot
2012-11-21 15:12 ` Thierry Reding
2012-11-21 15:12 ` Thierry Reding
2012-11-21 15:12 ` Thierry Reding
2012-11-22 2:01 ` Alexandre Courbot
2012-11-22 2:01 ` Alexandre Courbot
2012-11-22 2:01 ` Alexandre Courbot
2012-11-22 2:01 ` Alexandre Courbot
2012-11-22 2:06 ` Mark Brown
2012-11-22 2:06 ` Mark Brown
2012-11-22 2:06 ` Mark Brown
2012-11-22 2:06 ` Mark Brown
2012-11-22 3:09 ` Alexandre Courbot
2012-11-22 3:09 ` Alexandre Courbot
2012-11-22 3:09 ` Alexandre Courbot
2012-11-22 3:09 ` Alexandre Courbot
2012-11-22 13:39 ` Grant Likely
2012-11-22 13:39 ` Grant Likely
2012-11-22 13:39 ` Grant Likely
2012-11-22 13:39 ` Grant Likely
2012-11-27 15:19 ` Laurent Pinchart
2012-11-27 15:19 ` Laurent Pinchart
2012-11-27 15:19 ` Laurent Pinchart
2012-11-27 15:08 ` Laurent Pinchart
2012-11-27 15:08 ` Laurent Pinchart
2012-11-27 15:08 ` Laurent Pinchart
2012-11-27 15:08 ` Laurent Pinchart
2012-11-27 15:08 ` Laurent Pinchart
2012-11-27 15:19 ` Tomi Valkeinen
2012-11-27 15:19 ` Tomi Valkeinen
2012-11-27 15:19 ` Tomi Valkeinen
2012-11-27 15:19 ` Tomi Valkeinen
2012-11-27 15:37 ` Laurent Pinchart
2012-11-27 15:37 ` Laurent Pinchart
2012-11-27 15:37 ` Laurent Pinchart
2012-11-27 16:46 ` Mark Brown
2012-11-27 16:46 ` Mark Brown
2012-11-27 16:46 ` Mark Brown
2012-11-27 14:47 ` Laurent Pinchart
2012-11-27 14:47 ` Laurent Pinchart
2012-11-27 14:47 ` Laurent Pinchart
2012-11-27 14:47 ` Laurent Pinchart
2012-11-22 13:39 ` Grant Likely
2012-11-22 13:39 ` Grant Likely
2012-11-22 13:39 ` Grant Likely
2012-11-22 13:39 ` Grant Likely
2012-11-22 21:40 ` Thierry Reding
2012-11-22 21:40 ` Thierry Reding
2012-11-22 21:40 ` Thierry Reding
2012-11-22 21:40 ` Thierry Reding
2012-11-26 11:49 ` Alex Courbot
2012-11-26 11:49 ` Alex Courbot
2012-11-26 11:49 ` Alex Courbot
2012-11-26 11:49 ` Alex Courbot
2012-11-26 15:34 ` Grant Likely
2012-11-26 15:34 ` Grant Likely
2012-11-26 15:34 ` Grant Likely
2012-11-26 15:34 ` Grant Likely
2012-11-17 10:55 ` [PATCHv9 2/3] pwm_backlight: use power sequences Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` [PATCHv9 3/3] Take maintainership of " Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-17 10:55 ` Alexandre Courbot
2012-11-20 21:58 ` [PATCHv9 0/3] Runtime Interpreted Power Sequences Grant Likely
2012-11-20 21:58 ` Grant Likely
2012-11-20 21:58 ` Grant Likely
2012-11-20 21:58 ` Grant Likely
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=4316169.5QXVzv7peZ@percival \
--to=acourbot@nvidia.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.