All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
Date: Sat, 17 Nov 2012 11:38:50 +0000	[thread overview]
Message-ID: <20121117113849.GA5228@lizard> (raw)
In-Reply-To: <1353149747-31871-2-git-send-email-acourbot@nvidia.com>

On Sat, Nov 17, 2012 at 07:55:45PM +0900, Alexandre Courbot wrote:
> Some device drivers (e.g. panel or backlights) need to follow precise
> sequences for powering on and off, involving GPIOs, regulators, PWMs
> and other power-related resources, with a defined powering order and
> delays to respect between steps. These sequences are device-specific,
> and do not belong to a particular driver - therefore they have been
> performed by board-specific hook functions so 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. It also
> introduces first support for regulator, GPIO and PWM resources.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
> Tested-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---

This looks almost perfect!

Just a few final notes, again mostly about the build system bits.

[...]
> diff --git a/drivers/power/power_seq/Kconfig b/drivers/power/power_seq/Kconfig
> new file mode 100644
> index 0000000..0ece819
> --- /dev/null
> +++ b/drivers/power/power_seq/Kconfig
> @@ -0,0 +1,2 @@
> +config POWER_SEQ
> +	tristate

This really needs a proper Kconfig description and a help text, shortly
describing the purpose of the subsystem.

> diff --git a/drivers/power/power_seq/Makefile b/drivers/power/power_seq/Makefile
> new file mode 100644
> index 0000000..964b91e
> --- /dev/null
> +++ b/drivers/power/power_seq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQ)		+= power_seq.o
> +power_seq-y			:= core.o delay.o regulator.o gpio.o pwm.o
> diff --git a/drivers/power/power_seq/core.c b/drivers/power/power_seq/core.c
> new file mode 100644
> index 0000000..d51b9b8
> --- /dev/null
> +++ b/drivers/power/power_seq/core.c
> @@ -0,0 +1,362 @@
> +/*
> + * core.c - power sequence interpreter for platform devices and device tree

We usually don't write file names in the comments.

> + *
> + * Author: Alexandre Courbot <acourbot@nvidia.com>
> + *
[...]
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(power_seq_run);
> +
> +/* defined in power_seq_*.c files */

Why not place the decls into the _priv.h file?.. I understand that this
might be a temporary stuff until we have something better for ops
registration, but still, I believe it belongs to the header file.

> +extern const struct power_seq_res_ops power_seq_delay_ops;
> +extern const struct power_seq_res_ops power_seq_gpio_ops;
> +extern const struct power_seq_res_ops power_seq_regulator_ops;
> +extern const struct power_seq_res_ops power_seq_pwm_ops;
> +
> +static const struct power_seq_res_ops *power_seq_ops[POWER_SEQ_NUM_TYPES] = {
> +	[POWER_SEQ_DELAY] = &power_seq_delay_ops,
> +	[POWER_SEQ_REGULATOR] = &power_seq_regulator_ops,
> +	[POWER_SEQ_PWM] = &power_seq_gpio_ops,
> +	[POWER_SEQ_GPIO] = &power_seq_pwm_ops,
> +};
> +
> +MODULE_AUTHOR("Alexandre Courbot <acourbot@nvidia.com>");
> +MODULE_DESCRIPTION("Runtime Interpreted Power Sequences");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/power/power_seq/delay.c b/drivers/power/power_seq/delay.c
> new file mode 100644
> index 0000000..de6810b
> --- /dev/null
> +++ b/drivers/power/power_seq/delay.c
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (c) 2012 NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + */
> +
> +#include "power_seq_priv.h"
> +#include <linux/delay.h>

Things should not depend on _priv.h's includes. I.e. I see this file uses
of_ routines, so it should include <linux/of.h>. <linux/delay.h> for
udelay_range(), etc.

Also, usually we place "private" headers at the very end, not at the
beginning.

> +
> +#ifdef CONFIG_OF
> +static int of_power_seq_parse_delay(struct device_node *node,
> +				    struct power_seq *seq,
> +				    unsigned int step_nbr,
> +				    struct power_seq_resource *res)
> +{
> +	struct power_seq_step *step = &seq->steps[step_nbr];
> +	int err;
> +
> +	err = of_property_read_u32(node, "delay",
> +				   &step->delay.delay);
> +	if (err < 0)
> +		power_seq_err(seq, step_nbr, "error reading delay property\n");
> +
> +	return err;
> +}
> +#else
> +#define of_power_seq_parse_delay NULL
> +#endif

[...]
> +#define power_seq_err(seq, step_nbr, format, ...)			\
> +	dev_err(seq->set->dev, "%s[%d]: " format, seq->id, step_nbr,	\
> +	##__VA_ARGS__);
> +
> +#ifdef CONFIG_OF
> +int of_power_seq_parse_enable_properties(struct device_node *node,
> +					 struct power_seq *seq,
> +					 unsigned int step_nbr, bool *enable);

Um, I believe you don't need CONFIG_OF here. (If it's about 'struct
device_node', then as I see it in of.h, the header always declares it,
even for the !OF case.)

> +#endif
> +
> +/**
[...]
> +++ b/drivers/power/power_seq/regulator.c
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright (c) 2012 NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + */
> +
> +#include "power_seq_priv.h"
> +
> +#ifdef CONFIG_REGULATOR

Would be really great if you could get rid of the #ifdefs in the .c files.

To do so, in the makefile you could write something like this:

power_seq-$(CONFIG_REGULATOR) += regulator.o

And in the header file (as explained above), you'd have

#ifdef CONFIG_REGULATOR
#define ...REGULATOR_OPS &power_seq_regulator_ops
#else
#define ...REGULATOR_OPS NULL
#endif

Or something along these lines...

Thanks,
Anton.

WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: 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-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org, linux-pm@vger.kernel.org,
	Alexandre Courbot <gnurou@gmail.com>
Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences
Date: Sat, 17 Nov 2012 03:38:50 -0800	[thread overview]
Message-ID: <20121117113849.GA5228@lizard> (raw)
In-Reply-To: <1353149747-31871-2-git-send-email-acourbot@nvidia.com>

On Sat, Nov 17, 2012 at 07:55:45PM +0900, Alexandre Courbot wrote:
> Some device drivers (e.g. panel or backlights) need to follow precise
> sequences for powering on and off, involving GPIOs, regulators, PWMs
> and other power-related resources, with a defined powering order and
> delays to respect between steps. These sequences are device-specific,
> and do not belong to a particular driver - therefore they have been
> performed by board-specific hook functions so 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. It also
> introduces first support for regulator, GPIO and PWM resources.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
> Tested-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---

This looks almost perfect!

Just a few final notes, again mostly about the build system bits.

[...]
> diff --git a/drivers/power/power_seq/Kconfig b/drivers/power/power_seq/Kconfig
> new file mode 100644
> index 0000000..0ece819
> --- /dev/null
> +++ b/drivers/power/power_seq/Kconfig
> @@ -0,0 +1,2 @@
> +config POWER_SEQ
> +	tristate

This really needs a proper Kconfig description and a help text, shortly
describing the purpose of the subsystem.

> diff --git a/drivers/power/power_seq/Makefile b/drivers/power/power_seq/Makefile
> new file mode 100644
> index 0000000..964b91e
> --- /dev/null
> +++ b/drivers/power/power_seq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQ)		+= power_seq.o
> +power_seq-y			:= core.o delay.o regulator.o gpio.o pwm.o
> diff --git a/drivers/power/power_seq/core.c b/drivers/power/power_seq/core.c
> new file mode 100644
> index 0000000..d51b9b8
> --- /dev/null
> +++ b/drivers/power/power_seq/core.c
> @@ -0,0 +1,362 @@
> +/*
> + * core.c - power sequence interpreter for platform devices and device tree

We usually don't write file names in the comments.

> + *
> + * Author: Alexandre Courbot <acourbot@nvidia.com>
> + *
[...]
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(power_seq_run);
> +
> +/* defined in power_seq_*.c files */

Why not place the decls into the _priv.h file?.. I understand that this
might be a temporary stuff until we have something better for ops
registration, but still, I believe it belongs to the header file.

> +extern const struct power_seq_res_ops power_seq_delay_ops;
> +extern const struct power_seq_res_ops power_seq_gpio_ops;
> +extern const struct power_seq_res_ops power_seq_regulator_ops;
> +extern const struct power_seq_res_ops power_seq_pwm_ops;
> +
> +static const struct power_seq_res_ops *power_seq_ops[POWER_SEQ_NUM_TYPES] = {
> +	[POWER_SEQ_DELAY] = &power_seq_delay_ops,
> +	[POWER_SEQ_REGULATOR] = &power_seq_regulator_ops,
> +	[POWER_SEQ_PWM] = &power_seq_gpio_ops,
> +	[POWER_SEQ_GPIO] = &power_seq_pwm_ops,
> +};
> +
> +MODULE_AUTHOR("Alexandre Courbot <acourbot@nvidia.com>");
> +MODULE_DESCRIPTION("Runtime Interpreted Power Sequences");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/power/power_seq/delay.c b/drivers/power/power_seq/delay.c
> new file mode 100644
> index 0000000..de6810b
> --- /dev/null
> +++ b/drivers/power/power_seq/delay.c
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (c) 2012 NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + */
> +
> +#include "power_seq_priv.h"
> +#include <linux/delay.h>

Things should not depend on _priv.h's includes. I.e. I see this file uses
of_ routines, so it should include <linux/of.h>. <linux/delay.h> for
udelay_range(), etc.

Also, usually we place "private" headers at the very end, not at the
beginning.

> +
> +#ifdef CONFIG_OF
> +static int of_power_seq_parse_delay(struct device_node *node,
> +				    struct power_seq *seq,
> +				    unsigned int step_nbr,
> +				    struct power_seq_resource *res)
> +{
> +	struct power_seq_step *step = &seq->steps[step_nbr];
> +	int err;
> +
> +	err = of_property_read_u32(node, "delay",
> +				   &step->delay.delay);
> +	if (err < 0)
> +		power_seq_err(seq, step_nbr, "error reading delay property\n");
> +
> +	return err;
> +}
> +#else
> +#define of_power_seq_parse_delay NULL
> +#endif

[...]
> +#define power_seq_err(seq, step_nbr, format, ...)			\
> +	dev_err(seq->set->dev, "%s[%d]: " format, seq->id, step_nbr,	\
> +	##__VA_ARGS__);
> +
> +#ifdef CONFIG_OF
> +int of_power_seq_parse_enable_properties(struct device_node *node,
> +					 struct power_seq *seq,
> +					 unsigned int step_nbr, bool *enable);

Um, I believe you don't need CONFIG_OF here. (If it's about 'struct
device_node', then as I see it in of.h, the header always declares it,
even for the !OF case.)

> +#endif
> +
> +/**
[...]
> +++ b/drivers/power/power_seq/regulator.c
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright (c) 2012 NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + */
> +
> +#include "power_seq_priv.h"
> +
> +#ifdef CONFIG_REGULATOR

Would be really great if you could get rid of the #ifdefs in the .c files.

To do so, in the makefile you could write something like this:

power_seq-$(CONFIG_REGULATOR) += regulator.o

And in the header file (as explained above), you'd have

#ifdef CONFIG_REGULATOR
#define ...REGULATOR_OPS &power_seq_regulator_ops
#else
#define ...REGULATOR_OPS NULL
#endif

Or something along these lines...

Thanks,
Anton.

WARNING: multiple messages have this Message-ID (diff)
From: cbouatmailru@gmail.com (Anton Vorontsov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv9 1/3] Runtime Interpreted Power Sequences
Date: Sat, 17 Nov 2012 03:38:50 -0800	[thread overview]
Message-ID: <20121117113849.GA5228@lizard> (raw)
In-Reply-To: <1353149747-31871-2-git-send-email-acourbot@nvidia.com>

On Sat, Nov 17, 2012 at 07:55:45PM +0900, Alexandre Courbot wrote:
> Some device drivers (e.g. panel or backlights) need to follow precise
> sequences for powering on and off, involving GPIOs, regulators, PWMs
> and other power-related resources, with a defined powering order and
> delays to respect between steps. These sequences are device-specific,
> and do not belong to a particular driver - therefore they have been
> performed by board-specific hook functions so 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. It also
> introduces first support for regulator, GPIO and PWM resources.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
> Tested-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---

This looks almost perfect!

Just a few final notes, again mostly about the build system bits.

[...]
> diff --git a/drivers/power/power_seq/Kconfig b/drivers/power/power_seq/Kconfig
> new file mode 100644
> index 0000000..0ece819
> --- /dev/null
> +++ b/drivers/power/power_seq/Kconfig
> @@ -0,0 +1,2 @@
> +config POWER_SEQ
> +	tristate

This really needs a proper Kconfig description and a help text, shortly
describing the purpose of the subsystem.

> diff --git a/drivers/power/power_seq/Makefile b/drivers/power/power_seq/Makefile
> new file mode 100644
> index 0000000..964b91e
> --- /dev/null
> +++ b/drivers/power/power_seq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQ)		+= power_seq.o
> +power_seq-y			:= core.o delay.o regulator.o gpio.o pwm.o
> diff --git a/drivers/power/power_seq/core.c b/drivers/power/power_seq/core.c
> new file mode 100644
> index 0000000..d51b9b8
> --- /dev/null
> +++ b/drivers/power/power_seq/core.c
> @@ -0,0 +1,362 @@
> +/*
> + * core.c - power sequence interpreter for platform devices and device tree

We usually don't write file names in the comments.

> + *
> + * Author: Alexandre Courbot <acourbot@nvidia.com>
> + *
[...]
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(power_seq_run);
> +
> +/* defined in power_seq_*.c files */

Why not place the decls into the _priv.h file?.. I understand that this
might be a temporary stuff until we have something better for ops
registration, but still, I believe it belongs to the header file.

> +extern const struct power_seq_res_ops power_seq_delay_ops;
> +extern const struct power_seq_res_ops power_seq_gpio_ops;
> +extern const struct power_seq_res_ops power_seq_regulator_ops;
> +extern const struct power_seq_res_ops power_seq_pwm_ops;
> +
> +static const struct power_seq_res_ops *power_seq_ops[POWER_SEQ_NUM_TYPES] = {
> +	[POWER_SEQ_DELAY] = &power_seq_delay_ops,
> +	[POWER_SEQ_REGULATOR] = &power_seq_regulator_ops,
> +	[POWER_SEQ_PWM] = &power_seq_gpio_ops,
> +	[POWER_SEQ_GPIO] = &power_seq_pwm_ops,
> +};
> +
> +MODULE_AUTHOR("Alexandre Courbot <acourbot@nvidia.com>");
> +MODULE_DESCRIPTION("Runtime Interpreted Power Sequences");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/power/power_seq/delay.c b/drivers/power/power_seq/delay.c
> new file mode 100644
> index 0000000..de6810b
> --- /dev/null
> +++ b/drivers/power/power_seq/delay.c
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (c) 2012 NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + */
> +
> +#include "power_seq_priv.h"
> +#include <linux/delay.h>

Things should not depend on _priv.h's includes. I.e. I see this file uses
of_ routines, so it should include <linux/of.h>. <linux/delay.h> for
udelay_range(), etc.

Also, usually we place "private" headers at the very end, not at the
beginning.

> +
> +#ifdef CONFIG_OF
> +static int of_power_seq_parse_delay(struct device_node *node,
> +				    struct power_seq *seq,
> +				    unsigned int step_nbr,
> +				    struct power_seq_resource *res)
> +{
> +	struct power_seq_step *step = &seq->steps[step_nbr];
> +	int err;
> +
> +	err = of_property_read_u32(node, "delay",
> +				   &step->delay.delay);
> +	if (err < 0)
> +		power_seq_err(seq, step_nbr, "error reading delay property\n");
> +
> +	return err;
> +}
> +#else
> +#define of_power_seq_parse_delay NULL
> +#endif

[...]
> +#define power_seq_err(seq, step_nbr, format, ...)			\
> +	dev_err(seq->set->dev, "%s[%d]: " format, seq->id, step_nbr,	\
> +	##__VA_ARGS__);
> +
> +#ifdef CONFIG_OF
> +int of_power_seq_parse_enable_properties(struct device_node *node,
> +					 struct power_seq *seq,
> +					 unsigned int step_nbr, bool *enable);

Um, I believe you don't need CONFIG_OF here. (If it's about 'struct
device_node', then as I see it in of.h, the header always declares it,
even for the !OF case.)

> +#endif
> +
> +/**
[...]
> +++ b/drivers/power/power_seq/regulator.c
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright (c) 2012 NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + */
> +
> +#include "power_seq_priv.h"
> +
> +#ifdef CONFIG_REGULATOR

Would be really great if you could get rid of the #ifdefs in the .c files.

To do so, in the makefile you could write something like this:

power_seq-$(CONFIG_REGULATOR) += regulator.o

And in the header file (as explained above), you'd have

#ifdef CONFIG_REGULATOR
#define ...REGULATOR_OPS &power_seq_regulator_ops
#else
#define ...REGULATOR_OPS NULL
#endif

Or something along these lines...

Thanks,
Anton.

  reply	other threads:[~2012-11-17 11:38 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 [this message]
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
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=20121117113849.GA5228@lizard \
    --to=cbouatmailru@gmail.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.