linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>

  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).