From: "Heiko Stübner" <heiko@sntech.de> 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>, Mark Brown <broonie@opensource.wolfsonmicro.com>, Anton Vorontsov <cbou@mail.ru>, David Woodhouse <dwmw2@infradead.org>, Arnd Bergmann <arnd@arndb.de>, Leela Krishna Amudala <leelakrishna.a@gmail.com>, "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>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org> Subject: Re: [PATCH v5 1/4] Runtime Interpreted Power Sequences Date: Fri, 7 Sep 2012 11:08:41 +0200 [thread overview] Message-ID: <201209071108.42083.heiko@sntech.de> (raw) In-Reply-To: <1887927.1deN8M9siP@percival> Am Freitag, 7. September 2012, 10:04:24 schrieb Alex Courbot: > > For your power_seq_run function you write that it simply returns an error > > code on failure and looking through it I also just found the error return > > statement. This would leave a device half turned on. > > > > So I'm wondering, if it shouldn't turn off all the things it turned on > > until the step that produced the error. All your possible step types > > (execpt the delay) are booleans, so it should be possible to simply > > negate them when backtracking through the previous steps. > > Indeed, I think you raised an important point. Right now all step types are > invertible, but we cannot rely on that statement to be true forever. For > instance, one short-term improvement will be to allow finer regulator > control, like voltage setting. In this case, how can we go back to the > initial state without recording it? > > If e.g. the power on sequence fails at step N (of M steps for that > sequence), one could try playing the corresponding power off sequence > (either completely of from step M - N), but then again we cannot rely on > sequences to be perfectly symetrical. Maybe this is more something for the > calling driver to check for and control? Am Freitag, 7. September 2012, 10:15:03 schrieb Mark Brown: > On Fri, Sep 07, 2012 at 05:04:24PM +0900, Alex Courbot wrote: > > If e.g. the power on sequence fails at step N (of M steps for that > > sequence), one could try playing the corresponding power off sequence > > (either completely of from step M - N), but then again we cannot rely on > > sequences to be perfectly symetrical. Maybe this is more something for > > the calling driver to check for and control? > > That had been my thought too - depending on what the sequence is for it > may be that the corrective action is something very different to > reversing the sequence, for example a device reset may be required. If I understood the description correctly, the power sequence should be transparent to the driver, as it implements board specific actions and shouldn't bother the driver with it to much. Therefore my thoughts went along the lines how gpio_request_array handles this, always producing a sane state at the end. Recording the previous state, could be done by making a copy of the current sequence, and just noting the previous values (including voltages etc) in the respective entries. And in the error case running this new sequence from the error point instead to power down again. As both Alex and Mark wrote, reversing the sequence might be the action of choice only for some devices, but others might need to run a completely different powerdown sequence and still others would need special handling. Would it be possible to encode this in the sequence definition, something like on-error = "reverse" on-error = "sequence" error-seq = <&other_sequence> on-error = "driver" with better names and types of course. This would keep the power sequence transparent to most drivers and only the real esoteric ones would need to do their special handling on their own. Heiko
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de> 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>, Mark Brown <broonie@opensource.wolfsonmicro.com>, Anton Vorontsov <cbou@mail.ru>, David Woodhouse <dwmw2@infradead.org>, Arnd Bergmann <arnd@arndb.de>, Leela Krishna Amudala <leelakrishna.a@gmail.com>, "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>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org> Subject: Re: [PATCH v5 1/4] Runtime Interpreted Power Sequences Date: Fri, 07 Sep 2012 09:08:41 +0000 [thread overview] Message-ID: <201209071108.42083.heiko@sntech.de> (raw) In-Reply-To: <1887927.1deN8M9siP@percival> Am Freitag, 7. September 2012, 10:04:24 schrieb Alex Courbot: > > For your power_seq_run function you write that it simply returns an error > > code on failure and looking through it I also just found the error return > > statement. This would leave a device half turned on. > > > > So I'm wondering, if it shouldn't turn off all the things it turned on > > until the step that produced the error. All your possible step types > > (execpt the delay) are booleans, so it should be possible to simply > > negate them when backtracking through the previous steps. > > Indeed, I think you raised an important point. Right now all step types are > invertible, but we cannot rely on that statement to be true forever. For > instance, one short-term improvement will be to allow finer regulator > control, like voltage setting. In this case, how can we go back to the > initial state without recording it? > > If e.g. the power on sequence fails at step N (of M steps for that > sequence), one could try playing the corresponding power off sequence > (either completely of from step M - N), but then again we cannot rely on > sequences to be perfectly symetrical. Maybe this is more something for the > calling driver to check for and control? Am Freitag, 7. September 2012, 10:15:03 schrieb Mark Brown: > On Fri, Sep 07, 2012 at 05:04:24PM +0900, Alex Courbot wrote: > > If e.g. the power on sequence fails at step N (of M steps for that > > sequence), one could try playing the corresponding power off sequence > > (either completely of from step M - N), but then again we cannot rely on > > sequences to be perfectly symetrical. Maybe this is more something for > > the calling driver to check for and control? > > That had been my thought too - depending on what the sequence is for it > may be that the corrective action is something very different to > reversing the sequence, for example a device reset may be required. If I understood the description correctly, the power sequence should be transparent to the driver, as it implements board specific actions and shouldn't bother the driver with it to much. Therefore my thoughts went along the lines how gpio_request_array handles this, always producing a sane state at the end. Recording the previous state, could be done by making a copy of the current sequence, and just noting the previous values (including voltages etc) in the respective entries. And in the error case running this new sequence from the error point instead to power down again. As both Alex and Mark wrote, reversing the sequence might be the action of choice only for some devices, but others might need to run a completely different powerdown sequence and still others would need special handling. Would it be possible to encode this in the sequence definition, something like on-error = "reverse" on-error = "sequence" error-seq = <&other_sequence> on-error = "driver" with better names and types of course. This would keep the power sequence transparent to most drivers and only the real esoteric ones would need to do their special handling on their own. Heiko
next prev parent reply other threads:[~2012-09-07 9:08 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-31 11:34 [PATCH v5 0/4] Runtime Interpreted Power Sequences Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot [not found] ` <1346412846-17102-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2012-08-31 11:34 ` [PATCH v5 1/4] " Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot 2012-09-05 17:19 ` Stephen Warren 2012-09-05 17:19 ` Stephen Warren 2012-09-07 8:21 ` Alex Courbot 2012-09-07 8:21 ` Alex Courbot 2012-09-07 8:21 ` Alex Courbot 2012-09-06 14:14 ` Heiko Stübner 2012-09-06 14:14 ` Heiko Stübner [not found] ` <201209061614.54022.heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> 2012-09-07 8:04 ` Alex Courbot 2012-09-07 8:04 ` Alex Courbot 2012-09-07 8:04 ` Alex Courbot 2012-09-07 8:15 ` Mark Brown 2012-09-07 8:15 ` Mark Brown 2012-09-07 9:08 ` Heiko Stübner [this message] 2012-09-07 9:08 ` Heiko Stübner 2012-09-07 9:08 ` Heiko Stübner [not found] ` <201209071108.42083.heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> 2012-09-07 16:36 ` Stephen Warren 2012-09-07 16:36 ` Stephen Warren 2012-09-07 16:36 ` Stephen Warren 2012-08-31 11:34 ` [PATCH v5 2/4] pwm_backlight: use power sequences Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot [not found] ` <1346412846-17102-3-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2012-09-05 17:25 ` Stephen Warren 2012-09-05 17:25 ` Stephen Warren 2012-09-05 17:25 ` Stephen Warren 2012-09-07 8:28 ` Alex Courbot 2012-09-07 8:28 ` Alex Courbot 2012-09-07 8:28 ` Alex Courbot 2012-09-07 8:29 ` Mark Brown 2012-09-07 8:29 ` Mark Brown 2012-09-07 8:29 ` Mark Brown [not found] ` <20120907082835.GC17749-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 2012-09-07 8:34 ` Alex Courbot 2012-09-07 8:34 ` Alex Courbot 2012-09-07 8:34 ` Alex Courbot 2012-08-31 11:34 ` [PATCH v5 3/4] tegra: dt: add label to tegra20's PWM Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot 2012-08-31 11:34 ` [PATCH v5 4/4] tegra: ventana: add pwm backlight DT nodes Alexandre Courbot 2012-08-31 11:34 ` Alexandre Courbot 2012-08-31 11:34 ` 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=201209071108.42083.heiko@sntech.de \ --to=heiko@sntech.de \ --cc=acourbot@nvidia.com \ --cc=arnd@arndb.de \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=cbou@mail.ru \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=dwmw2@infradead.org \ --cc=grant.likely@secretlab.ca \ --cc=leelakrishna.a@gmail.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@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: linkBe 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.