| Message ID | 1382446896-28436-2-git-send-email-sre@debian.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Oct 22, 2013 at 3:01 PM, Sebastian Reichel <sre@debian.org> wrote: > This patch moves the handling of the chip's enable pin from the board > code into the driver. It also updates all board-code files using the > driver to incorporate this change. > > This is needed for device tree support of the enable pin. > > Signed-off-by: Sebastian Reichel <sre@debian.org> Looks good to me. Acked-by: Linus Walleij <linus.walleij@linaro.org> BTW: should we disable the GPIO when remove()ing the module? This is a topic of another patch but... Yours, Linus Walleij
On Tue, Oct 22, 2013 at 6:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > BTW: should we disable the GPIO when remove()ing the module? > This is a topic of another patch but... Bah forget this stupid comment, I misread it, obviously you're doing this. Yours, Linus Walleij
* Sebastian Reichel <sre@debian.org> [131022 06:02]: > This patch moves the handling of the chip's enable pin from the board > code into the driver. It also updates all board-code files using the > driver to incorporate this change. > > This is needed for device tree support of the enable pin. This seems safe to merge along with the other LED patches, the changes to arch/arm/mach-omap2 should not conflict with anything. So for the arch/arm/mach-omap2 changes: Acked-by: Tony Lindgren <tony@atomide.com>
On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren <tony@atomide.com> wrote: > * Sebastian Reichel <sre@debian.org> [131022 06:02]: >> This patch moves the handling of the chip's enable pin from the board >> code into the driver. It also updates all board-code files using the >> driver to incorporate this change. >> >> This is needed for device tree support of the enable pin. > > This seems safe to merge along with the other LED patches, the > changes to arch/arm/mach-omap2 should not conflict with anything. > > So for the arch/arm/mach-omap2 changes: > > Acked-by: Tony Lindgren <tony@atomide.com> I'm OK for LED parts, will this patch go through omap tree? If so, please add my ack. Acked-by: Bryan Wu <cooloney@gmail.com> Thanks, -Bryan
* Bryan Wu <cooloney@gmail.com> [131022 10:23]: > On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren <tony@atomide.com> wrote: > > * Sebastian Reichel <sre@debian.org> [131022 06:02]: > >> This patch moves the handling of the chip's enable pin from the board > >> code into the driver. It also updates all board-code files using the > >> driver to incorporate this change. > >> > >> This is needed for device tree support of the enable pin. > > > > This seems safe to merge along with the other LED patches, the > > changes to arch/arm/mach-omap2 should not conflict with anything. > > > > So for the arch/arm/mach-omap2 changes: > > > > Acked-by: Tony Lindgren <tony@atomide.com> > > I'm OK for LED parts, will this patch go through omap tree? If so, > please add my ack. > > Acked-by: Bryan Wu <cooloney@gmail.com> It's probably best that you take it via with the LED patches. Regards, Tony
On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren <tony@atomide.com> wrote: > * Bryan Wu <cooloney@gmail.com> [131022 10:23]: >> On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren <tony@atomide.com> wrote: >> > * Sebastian Reichel <sre@debian.org> [131022 06:02]: >> >> This patch moves the handling of the chip's enable pin from the board >> >> code into the driver. It also updates all board-code files using the >> >> driver to incorporate this change. >> >> >> >> This is needed for device tree support of the enable pin. >> > >> > This seems safe to merge along with the other LED patches, the >> > changes to arch/arm/mach-omap2 should not conflict with anything. >> > >> > So for the arch/arm/mach-omap2 changes: >> > >> > Acked-by: Tony Lindgren <tony@atomide.com> >> >> I'm OK for LED parts, will this patch go through omap tree? If so, >> please add my ack. >> >> Acked-by: Bryan Wu <cooloney@gmail.com> > > It's probably best that you take it via with the LED patches. > OK, I will do it. what about PATCH 2 of this patch set? Will you take care of it? Thanks, -Bryan
* Bryan Wu <cooloney@gmail.com> [131022 10:47]: > On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren <tony@atomide.com> wrote: > > * Bryan Wu <cooloney@gmail.com> [131022 10:23]: > >> On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren <tony@atomide.com> wrote: > >> > * Sebastian Reichel <sre@debian.org> [131022 06:02]: > >> >> This patch moves the handling of the chip's enable pin from the board > >> >> code into the driver. It also updates all board-code files using the > >> >> driver to incorporate this change. > >> >> > >> >> This is needed for device tree support of the enable pin. > >> > > >> > This seems safe to merge along with the other LED patches, the > >> > changes to arch/arm/mach-omap2 should not conflict with anything. > >> > > >> > So for the arch/arm/mach-omap2 changes: > >> > > >> > Acked-by: Tony Lindgren <tony@atomide.com> > >> > >> I'm OK for LED parts, will this patch go through omap tree? If so, > >> please add my ack. > >> > >> Acked-by: Bryan Wu <cooloney@gmail.com> > > > > It's probably best that you take it via with the LED patches. > > > > OK, I will do it. what about PATCH 2 of this patch set? Will you take > care of it? Benoit should take that one, otherwise there's a good chance of pointless merge conflicts with the .dts files. Regards, Tony
On 23/10/2013 10:19, Tony Lindgren wrote: > * Bryan Wu <cooloney@gmail.com> [131022 10:47]: >> On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren <tony@atomide.com> wrote: >>> * Bryan Wu <cooloney@gmail.com> [131022 10:23]: >>>> On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren <tony@atomide.com> wrote: >>>>> * Sebastian Reichel <sre@debian.org> [131022 06:02]: >>>>>> This patch moves the handling of the chip's enable pin from the board >>>>>> code into the driver. It also updates all board-code files using the >>>>>> driver to incorporate this change. >>>>>> >>>>>> This is needed for device tree support of the enable pin. >>>>> >>>>> This seems safe to merge along with the other LED patches, the >>>>> changes to arch/arm/mach-omap2 should not conflict with anything. >>>>> >>>>> So for the arch/arm/mach-omap2 changes: >>>>> >>>>> Acked-by: Tony Lindgren <tony@atomide.com> >>>> >>>> I'm OK for LED parts, will this patch go through omap tree? If so, >>>> please add my ack. >>>> >>>> Acked-by: Bryan Wu <cooloney@gmail.com> >>> >>> It's probably best that you take it via with the LED patches. >>> >> >> OK, I will do it. what about PATCH 2 of this patch set? Will you take >> care of it? > > Benoit should take that one, otherwise there's a good chance of > pointless merge conflicts with the .dts files. I've just merged it. Regards, Benoit
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt index a61727f..5fb7b21 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt @@ -10,6 +10,7 @@ Each child has own specific current settings - max-cur: Maximun current at each led channel. Optional properties: +- enable-gpio: GPIO attached to the chip's enable pin - label: Used for naming LEDs - pwr-sel: LP8501 specific property. Power selection for output channels. 0: D1~9 are connected to VDD diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index f6fe388..68dc998 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -211,29 +211,11 @@ static struct lp55xx_led_config rx51_lp5523_led_config[] = { } }; -static int rx51_lp5523_setup(void) -{ - return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT, - "lp5523_enable"); -} - -static void rx51_lp5523_release(void) -{ - gpio_free(RX51_LP5523_CHIP_EN_GPIO); -} - -static void rx51_lp5523_enable(bool state) -{ - gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, !!state); -} - static struct lp55xx_platform_data rx51_lp5523_platform_data = { .led_config = rx51_lp5523_led_config, .num_channels = ARRAY_SIZE(rx51_lp5523_led_config), .clock_mode = LP55XX_CLOCK_AUTO, - .setup_resources = rx51_lp5523_setup, - .release_resources = rx51_lp5523_release, - .enable = rx51_lp5523_enable, + .enable_gpio = RX51_LP5523_CHIP_EN_GPIO, }; #endif diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c index ad0806e..703dec2 100644 --- a/arch/arm/mach-ux500/board-mop500.c +++ b/arch/arm/mach-ux500/board-mop500.c @@ -297,6 +297,7 @@ static struct lp55xx_platform_data __initdata lp5521_pri_data = { .led_config = &lp5521_pri_led[0], .num_channels = 3, .clock_mode = LP55XX_CLOCK_EXT, + .enable_gpio = -1, }; static struct lp55xx_led_config lp5521_sec_led[] = { @@ -322,6 +323,7 @@ static struct lp55xx_platform_data __initdata lp5521_sec_data = { .led_config = &lp5521_sec_led[0], .num_channels = 3, .clock_mode = LP55XX_CLOCK_EXT, + .enable_gpio = -1, }; /* I2C0 devices only available on the first HREF/MOP500 */ diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c index 351825b..5160f8e 100644 --- a/drivers/leds/leds-lp55xx-common.c +++ b/drivers/leds/leds-lp55xx-common.c @@ -20,6 +20,8 @@ #include <linux/module.h> #include <linux/platform_data/leds-lp55xx.h> #include <linux/slab.h> +#include <linux/gpio.h> +#include <linux/of_gpio.h> #include "leds-lp55xx-common.h" @@ -406,18 +408,18 @@ int lp55xx_init_device(struct lp55xx_chip *chip) if (!pdata || !cfg) return -EINVAL; - if (pdata->setup_resources) { - ret = pdata->setup_resources(); + if (gpio_is_valid(pdata->enable_gpio)) { + ret = devm_gpio_request_one(dev, pdata->enable_gpio, + GPIOF_DIR_OUT, "lp5523_enable"); if (ret < 0) { - dev_err(dev, "setup resoure err: %d\n", ret); + dev_err(dev, "could not acquire enable gpio (err=%d)\n", + ret); goto err; } - } - if (pdata->enable) { - pdata->enable(0); + gpio_set_value(pdata->enable_gpio, 0); usleep_range(1000, 2000); /* Keep enable down at least 1ms */ - pdata->enable(1); + gpio_set_value(pdata->enable_gpio, 1); usleep_range(1000, 2000); /* 500us abs min. */ } @@ -458,11 +460,8 @@ void lp55xx_deinit_device(struct lp55xx_chip *chip) if (chip->clk) clk_disable_unprepare(chip->clk); - if (pdata->enable) - pdata->enable(0); - - if (pdata->release_resources) - pdata->release_resources(); + if (gpio_is_valid(pdata->enable_gpio)) + gpio_set_value(pdata->enable_gpio, 0); } EXPORT_SYMBOL_GPL(lp55xx_deinit_device); @@ -593,6 +592,8 @@ int lp55xx_of_populate_pdata(struct device *dev, struct device_node *np) of_property_read_string(np, "label", &pdata->label); of_property_read_u8(np, "clock-mode", &pdata->clock_mode); + pdata->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0); + /* LP8501 specific */ of_property_read_u8(np, "pwr-sel", (u8 *)&pdata->pwr_sel); diff --git a/include/linux/platform_data/leds-lp55xx.h b/include/linux/platform_data/leds-lp55xx.h index 51a2ff5..820a5c7 100644 --- a/include/linux/platform_data/leds-lp55xx.h +++ b/include/linux/platform_data/leds-lp55xx.h @@ -66,10 +66,8 @@ struct lp55xx_platform_data { /* Clock configuration */ u8 clock_mode; - /* Platform specific functions */ - int (*setup_resources)(void); - void (*release_resources)(void); - void (*enable)(bool state); + /* optional enable GPIO */ + int enable_gpio; /* Predefined pattern data */ struct lp55xx_predef_pattern *patterns;
This patch moves the handling of the chip's enable pin from the board code into the driver. It also updates all board-code files using the driver to incorporate this change. This is needed for device tree support of the enable pin. Signed-off-by: Sebastian Reichel <sre@debian.org> --- .../devicetree/bindings/leds/leds-lp55xx.txt | 1 + arch/arm/mach-omap2/board-rx51-peripherals.c | 20 +---------------- arch/arm/mach-ux500/board-mop500.c | 2 ++ drivers/leds/leds-lp55xx-common.c | 25 +++++++++++----------- include/linux/platform_data/leds-lp55xx.h | 6 ++---- 5 files changed, 19 insertions(+), 35 deletions(-)