From: Thierry Reding <thierry.reding@avionic-design.de>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Alexandre Courbot <acourbot@nvidia.com>,
Stephen Warren <swarren@nvidia.com>,
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-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
Date: Thu, 16 Aug 2012 19:49:02 +0000 [thread overview]
Message-ID: <20120816194902.GA31405@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <502D3E29.1010501@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]
On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote:
> On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
> > diff --git a/Documentation/power/power_seq.txt b/Documentation/power/power_seq.txt
>
> > +Usage by Drivers and Resources Management
> > +-----------------------------------------
> > +Power sequences make use of resources that must be properly allocated and
> > +managed. The power_seq_build() function builds a power sequence from the
> > +platform data. It also takes care of resolving and allocating the resources
> > +referenced by the sequence if needed:
> > +
> > + struct power_seq *power_seq_build(struct device *dev, struct list_head *ress,
> > + struct platform_power_seq *pseq);
> > +
> > +The 'dev' argument is the device in the name of which the resources are to be
> > +allocated.
> > +
> > +The 'ress' argument is a list to which the resolved resources are appended. This
> > +avoids allocating a resource referenced in several power sequences multiple
> > +times.
>
> I see in other parts of the thread, there has been discussion re:
> needing the separate ress parameter, and requiring the driver to pass
> this in to multiple power_seq_build calls.
>
> The way the pinctrl subsystem solved this was to have a single function
> that parsed all pinctrl setting (c.f. all power sequences) at once, and
> return a single handle. Later, the driver passes this handle
> pinctrl_lookup_state(), along with the requested state (c.f. sequence
> name) to search for, and finally passes that handle to
> pinctrl_select_state(). Doing something similar here would result in:
>
> struct power_seqs *power_seq_get(struct device *dev);
> void power_seq_put(struct power_seqs *seqs);
> struct power_seq *power_seq_lookup(struct power_seqs *seqs,
> const char *name);
> int power_seq_executestruct power_seq *seq);
>
> struct power_seqs *devm_power_seq_get(struct device *dev);
> void devm_power_seq_put(struct power_seqs *seqs);
Hehe, this looks very much like what I had in mind when I proposed this
during the last version of this series. The nice thing about this is
that the API is very much in line with how other subsystems work.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@avionic-design.de>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Alexandre Courbot <acourbot@nvidia.com>,
Stephen Warren <swarren@nvidia.com>,
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-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
Date: Thu, 16 Aug 2012 21:49:02 +0200 [thread overview]
Message-ID: <20120816194902.GA31405@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <502D3E29.1010501@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]
On Thu, Aug 16, 2012 at 12:38:33PM -0600, Stephen Warren wrote:
> On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
> > diff --git a/Documentation/power/power_seq.txt b/Documentation/power/power_seq.txt
>
> > +Usage by Drivers and Resources Management
> > +-----------------------------------------
> > +Power sequences make use of resources that must be properly allocated and
> > +managed. The power_seq_build() function builds a power sequence from the
> > +platform data. It also takes care of resolving and allocating the resources
> > +referenced by the sequence if needed:
> > +
> > + struct power_seq *power_seq_build(struct device *dev, struct list_head *ress,
> > + struct platform_power_seq *pseq);
> > +
> > +The 'dev' argument is the device in the name of which the resources are to be
> > +allocated.
> > +
> > +The 'ress' argument is a list to which the resolved resources are appended. This
> > +avoids allocating a resource referenced in several power sequences multiple
> > +times.
>
> I see in other parts of the thread, there has been discussion re:
> needing the separate ress parameter, and requiring the driver to pass
> this in to multiple power_seq_build calls.
>
> The way the pinctrl subsystem solved this was to have a single function
> that parsed all pinctrl setting (c.f. all power sequences) at once, and
> return a single handle. Later, the driver passes this handle
> pinctrl_lookup_state(), along with the requested state (c.f. sequence
> name) to search for, and finally passes that handle to
> pinctrl_select_state(). Doing something similar here would result in:
>
> struct power_seqs *power_seq_get(struct device *dev);
> void power_seq_put(struct power_seqs *seqs);
> struct power_seq *power_seq_lookup(struct power_seqs *seqs,
> const char *name);
> int power_seq_executestruct power_seq *seq);
>
> struct power_seqs *devm_power_seq_get(struct device *dev);
> void devm_power_seq_put(struct power_seqs *seqs);
Hehe, this looks very much like what I had in mind when I proposed this
during the last version of this series. The nice thing about this is
that the API is very much in line with how other subsystems work.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-08-16 19:49 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 6:08 [PATCH v4 0/3] Runtime Interpreted Power Sequences Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
2012-08-16 6:08 ` [PATCH v4 1/3] " Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
2012-08-16 7:42 ` Thierry Reding
2012-08-16 7:42 ` Thierry Reding
[not found] ` <20120816074232.GA17917-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-16 9:19 ` Alex Courbot
2012-08-16 9:19 ` Alex Courbot
2012-08-16 9:19 ` Alex Courbot
2012-08-16 9:52 ` Thierry Reding
2012-08-16 9:52 ` Thierry Reding
2012-08-16 10:33 ` Alex Courbot
2012-08-16 10:33 ` Alex Courbot
2012-08-16 10:52 ` Thierry Reding
2012-08-16 10:52 ` Thierry Reding
2012-08-16 14:14 ` Mark Brown
2012-08-16 14:14 ` Mark Brown
2012-08-16 18:38 ` Stephen Warren
2012-08-16 18:38 ` Stephen Warren
[not found] ` <502D3E29.1010501-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-08-16 18:47 ` Mark Brown
2012-08-16 18:47 ` Mark Brown
2012-08-16 18:47 ` Mark Brown
[not found] ` <20120816184703.GP15365-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-08-16 18:57 ` Stephen Warren
2012-08-16 18:57 ` Stephen Warren
2012-08-16 18:57 ` Stephen Warren
[not found] ` <502D428F.1010901-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-08-16 19:35 ` Stephen Warren
2012-08-16 19:35 ` Stephen Warren
2012-08-16 19:35 ` Stephen Warren
2012-08-16 21:10 ` Mitch Bradley
2012-08-16 21:10 ` Mitch Bradley
2012-08-16 21:10 ` Mitch Bradley
2012-08-17 23:04 ` Mark Brown
2012-08-17 23:04 ` Mark Brown
2012-08-16 19:49 ` Thierry Reding [this message]
2012-08-16 19:49 ` Thierry Reding
2012-08-17 8:52 ` Alex Courbot
2012-08-17 8:52 ` Alex Courbot
[not found] ` <1345097337-24170-2-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-21 7:44 ` Tomi Valkeinen
2012-08-21 7:44 ` Tomi Valkeinen
2012-08-21 7:44 ` Tomi Valkeinen
2012-08-21 8:22 ` Alex Courbot
2012-08-21 8:22 ` Alex Courbot
2012-08-21 8:33 ` Thierry Reding
2012-08-21 8:33 ` Thierry Reding
2012-08-21 8:53 ` Alex Courbot
2012-08-21 8:53 ` Alex Courbot
2012-08-21 8:57 ` Tomi Valkeinen
2012-08-21 8:57 ` Tomi Valkeinen
2012-08-21 9:13 ` Thierry Reding
2012-08-21 9:13 ` Thierry Reding
[not found] ` <20120821091306.GA4819-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-08-21 9:54 ` Tomi Valkeinen
2012-08-21 9:54 ` Tomi Valkeinen
2012-08-21 9:54 ` Tomi Valkeinen
2012-08-21 16:57 ` Mark Brown
2012-08-21 16:57 ` Mark Brown
[not found] ` <20120821165738.GY7995-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-08-22 5:42 ` Thierry Reding
2012-08-22 5:42 ` Thierry Reding
2012-08-22 5:42 ` Thierry Reding
2012-08-24 9:24 ` Alex Courbot
2012-08-24 9:24 ` Alex Courbot
2012-08-24 10:34 ` Tomi Valkeinen
2012-08-24 10:34 ` Tomi Valkeinen
2012-08-16 6:08 ` [PATCH v4 2/3] pwm_backlight: use power sequences Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
2012-08-16 18:42 ` Stephen Warren
2012-08-16 18:42 ` Stephen Warren
2012-08-16 6:08 ` [PATCH v4 3/3] tegra: add pwm backlight device tree nodes Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
2012-08-16 6:08 ` Alexandre Courbot
[not found] ` <1345097337-24170-4-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-16 18:45 ` Stephen Warren
2012-08-16 18:45 ` Stephen Warren
2012-08-16 18:45 ` Stephen Warren
[not found] ` <1345097337-24170-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-08-16 21:47 ` [PATCH v4 0/3] Runtime Interpreted Power Sequences Rafael J. Wysocki
2012-08-16 21:47 ` Rafael J. Wysocki
2012-08-16 21:47 ` Rafael J. Wysocki
2012-08-17 8:54 ` Alex Courbot
2012-08-17 8:54 ` Alex 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=20120816194902.GA31405@avionic-0098.mockup.avionic-design.de \
--to=thierry.reding@avionic-design.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-tegra@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.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.