Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
* Bryan Wu coolo...@gmail.com [131022 10:47]: On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren t...@atomide.com wrote: * Bryan Wu coolo...@gmail.com [131022 10:23]: On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@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 t...@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 coolo...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On 23/10/2013 10:19, Tony Lindgren wrote: * Bryan Wu coolo...@gmail.com [131022 10:47]: On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren t...@atomide.com wrote: * Bryan Wu coolo...@gmail.com [131022 10:23]: On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@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 t...@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 coolo...@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 -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] leds: lp55xx: handle enable pin in driver
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 s...@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(-)
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
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On Tue, Oct 22, 2013 at 3:01 PM, Sebastian Reichel s...@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 s...@debian.org Looks good to me. Acked-by: Linus Walleij linus.wall...@linaro.org BTW: should we disable the GPIO when remove()ing the module? This is a topic of another patch but... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On Tue, Oct 22, 2013 at 6:57 PM, Linus Walleij linus.wall...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
* Sebastian Reichel s...@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 t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@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 t...@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 coolo...@gmail.com Thanks, -Bryan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
* Bryan Wu coolo...@gmail.com [131022 10:23]: On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@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 t...@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 coolo...@gmail.com It's probably best that you take it via with the LED patches. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren t...@atomide.com wrote: * Bryan Wu coolo...@gmail.com [131022 10:23]: On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@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 t...@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 coolo...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
