From: Stephen Warren <swarren@wwwdotorg.org>
To: Alexandre 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 <l.krishna@samsung.com>,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-pm@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v6 1/4] Runtime Interpreted Power Sequences
Date: Wed, 12 Sep 2012 16:07:13 -0600 [thread overview]
Message-ID: <50510791.8080302@wwwdotorg.org> (raw)
In-Reply-To: <1347443867-18868-2-git-send-email-acourbot@nvidia.com>
On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequences are board-specific, and do not belong to a particular
> driver - therefore they have been performed by board-specific hook
> functions to far.
>
> With the advent of the device tree and of ARM kernels that are not
> board-tied, we cannot rely on these board-specific hooks anymore but
> need a way to implement these sequences in a portable manner. This patch
> introduces a simple interpreter that can execute such power sequences
> encoded either as platform data or within the device tree.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> diff --git a/Documentation/power/power_seq.txt b/Documentation/power/power_seq.txt
> +Sometimes, you may want to browse the list of resources allocated by a sequence,
> +for instance to ensure that a resource of a given type is present. The
> +power_seq_set_resources() function returns a list head that can be used with
> +the power_seq_for_each_resource() macro to browse all the resources of a set:
> +
> + struct list_head *power_seq_set_resources(struct power_seq_set *seqs);
I don't think you need to include that prototype here?
> + power_seq_for_each_resource(pos, seqs)
> +
> +Here "pos" will be a pointer to a struct power_seq_resource. This structure
> +contains the type of the resource, the information used for identifying it, and
> +the resolved resource itself.
> diff --git a/drivers/power/power_seq/Makefile b/drivers/power/power_seq/Makefile
> new file mode 100644
> index 0000000..f77a359
> --- /dev/null
> +++ b/drivers/power/power_seq/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_POWER_SEQ) += power_seq.o
Don't you need to compile all the power_seq_*.c too?
Oh, I see the following in power_seq.c:
> +#include "power_seq_delay.c"
> +#include "power_seq_regulator.c"
> +#include "power_seq_pwm.c"
> +#include "power_seq_gpio.c"
It's probably better just to compile them separately and link them.
> diff --git a/drivers/power/power_seq/power_seq.c b/drivers/power/power_seq/power_seq.c
> +struct power_seq_step {
> + /* Copy of the platform data */
> + struct platform_power_seq_step pdata;
I'd reword the comment to "Copy of the step", and name the field "step".
> +static const struct power_seq_res_ops power_seq_types[POWER_SEQ_NUM_TYPES] = {
> + [POWER_SEQ_DELAY] = POWER_SEQ_DELAY_TYPE,
> + [POWER_SEQ_REGULATOR] = POWER_SEQ_REGULATOR_TYPE,
> + [POWER_SEQ_PWM] = POWER_SEQ_PWM_TYPE,
> + [POWER_SEQ_GPIO] = POWER_SEQ_GPIO_TYPE,
> +};
Ah, I see why you're using #include now.
> +MODULE_LICENSE("GPL");
s/GPL/GPL v2/ given the license header.
> diff --git a/drivers/power/power_seq/power_seq_gpio.c b/drivers/power/power_seq/power_seq_gpio.c
> +static int power_seq_res_alloc_gpio(struct device *dev,
> + struct platform_power_seq_step *pstep,
> + struct power_seq_resource *res)
> +{
> + int err;
> +
> + err = devm_gpio_request_one(dev, pstep->gpio.gpio,
> + GPIOF_OUT_INIT_LOW, dev_name(dev));
Hmm. The INIT_LOW part of that might be somewhat presumptive. I would
suggest simply requesting the GPIO here, and using
gpio_direction_output() in power_seq_step_run_gpio(), thus deferring the
decision of what value to set the GPIO to until a real sequence is
actually run.
> diff --git a/drivers/power/power_seq/power_seq_pwm.c b/drivers/power/power_seq/power_seq_pwm.c
> diff --git a/drivers/power/power_seq/power_seq_regulator.c b/drivers/power/power_seq/power_seq_regulator.c
> diff --git a/include/linux/power_seq.h b/include/linux/power_seq.h
> +#include <net/irda/parameters.h>
That looks out of place.
> +/**
> + * struct power_seq_resource - resource used by a power sequence set
> + * @pdata: Pointer to the platform data used to resolve this resource
> + * @regulator: Resolved regulator if of type POWER_SEQ_REGULATOR
> + * @pwm: Resolved PWM if of type POWER_SEQ_PWM
> + * @list: Used to link resources together
> + */
I think that kerneldoc is stale.
> +struct power_seq_resource {
> + enum power_seq_res_type type;
> + /* resolved resource and identifier */
> + union {
> + struct {
> + struct regulator *regulator;
> + const char *id;
> + } regulator;
> + struct {
> + struct pwm_device *pwm;
> + const char *id;
> + } pwm;
> + struct {
> + int gpio;
> + } gpio;
> + };
> + struct list_head list;
> +};
Aside from those minor issues, this all looks reasonable to me, so,
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
next prev parent reply other threads:[~2012-09-12 22:07 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 9:57 [PATCH v6 0/4] Runtime Interpreted Power Sequences Alexandre Courbot
[not found] ` <1347443867-18868-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-09-12 9:57 ` [PATCH v6 1/4] " Alexandre Courbot
2012-09-12 22:07 ` Stephen Warren [this message]
2012-09-13 6:02 ` Alex Courbot
2012-09-13 15:44 ` Stephen Warren
[not found] ` <1347443867-18868-2-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-09-13 5:45 ` Tomi Valkeinen
2012-09-13 6:08 ` Alex Courbot
2012-09-13 6:22 ` Tomi Valkeinen
2012-09-13 6:36 ` Alex Courbot
2012-09-13 6:54 ` Tomi Valkeinen
2012-09-13 7:00 ` Sascha Hauer
[not found] ` <20120913070012.GC6180-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-09-13 7:03 ` Tomi Valkeinen
2012-09-13 7:18 ` Sascha Hauer
[not found] ` <20120913071829.GE6180-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-09-13 7:27 ` Tomi Valkeinen
2012-09-13 7:21 ` Alex Courbot
2012-09-13 7:29 ` Thierry Reding
2012-09-13 7:50 ` Sascha Hauer
2012-09-13 8:21 ` Alex Courbot
2012-09-13 8:26 ` Thierry Reding
[not found] ` <20120913072920.GA11459-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-09-13 8:00 ` Tomi Valkeinen
2012-09-13 8:32 ` Thierry Reding
2012-09-13 7:08 ` Alex Courbot
2012-09-13 15:37 ` Stephen Warren
2012-09-13 8:09 ` Mark Brown
2012-09-12 9:57 ` [PATCH v6 3/4] tegra: dt: add label to tegra20's PWM Alexandre Courbot
2012-09-12 9:57 ` [PATCH v6 2/4] pwm_backlight: use power sequences Alexandre Courbot
2012-09-12 22:15 ` Stephen Warren
2012-09-12 9:57 ` [PATCH v6 4/4] tegra: ventana: add pwm backlight DT nodes Alexandre Courbot
[not found] ` <1347443867-18868-5-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-09-12 21:23 ` Stephen Warren
2012-09-12 21:27 ` [PATCH v6 0/4] Runtime Interpreted Power Sequences Stephen Warren
[not found] ` <5050FE28.2080502-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-09-12 21:33 ` Anton Vorontsov
2012-09-13 5:53 ` Alex Courbot
2012-09-13 5:50 ` Tomi Valkeinen
2012-09-13 6:23 ` Alex Courbot
2012-09-13 6:25 ` Mark Brown
2012-09-13 6:42 ` Alex Courbot
2012-09-13 7:19 ` Mark Brown
2012-09-13 7:26 ` Alex Courbot
2012-09-13 7:29 ` Mark Brown
2012-09-13 15:24 ` Stephen Warren
2012-09-19 3:01 ` Mark Brown
[not found] ` <5051FAC5.40501-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-03 8:24 ` Alex Courbot
[not found] ` <506BF62F.6040308-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-10-03 15:30 ` Stephen Warren
2012-09-13 6:42 ` Tomi Valkeinen
2012-09-13 6:48 ` Tomi Valkeinen
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=50510791.8080302@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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=l.krishna@samsung.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: 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;
as well as URLs for NNTP newsgroup(s).