diff mbox

[v3,3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs

Message ID 1353405382-9226-4-git-send-email-peter.ujfalusi@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Peter Ujfalusi Nov. 20, 2012, 9:56 a.m. UTC
The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)

On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 drivers/pwm/Kconfig       |  10 ++
 drivers/pwm/Makefile      |   1 +
 drivers/pwm/pwm-twl-led.c | 303 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 314 insertions(+)
 create mode 100644 drivers/pwm/pwm-twl-led.c

Comments

Peter Ujfalusi Nov. 20, 2012, 11:54 a.m. UTC | #1
On 11/20/2012 10:56 AM, Peter Ujfalusi wrote:
> The driver supports the following LED outputs as generic PWM driver:
> TWL4030 LEDA and LEDB (PWMA and PWMB)
> TWL6030 Charging indicator LED (PWM LED)
> 
> On TWL6030 when the PWM requested LED is configured to be controlled by SW.
> In this case the user can enable/disable and set the duty period freely.
> When the PWM has been freed, the LED driver is put back to HW control.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  drivers/pwm/Kconfig       |  10 ++
>  drivers/pwm/Makefile      |   1 +
>  drivers/pwm/pwm-twl-led.c | 303 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 314 insertions(+)
>  create mode 100644 drivers/pwm/pwm-twl-led.c

...

> +static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device *pwm,
> +			      int duty_ns, int period_ns)
> +{
> +	int duty_cycle = DIV_ROUND_UP(duty_ns * TWL4030_LED_MAX, period_ns);
> +	u8 pwm_config[2] = {1, 0};
> +	int base, ret;
> +
> +	/*
> +	 * To configure the duty period:
> +	 * On-cycle is set to 1 (the minimum allowed value)
> +	 * The off time of 0 is not configurable, so the mapping is:
> +	 * 0 -> off cycle = 2,
> +	 * 1 -> off cycle = 2,
> +	 * 2 -> off cycle = 3,
> +	 * 125 - > off cycle 127,
> +	 * 126 - > off cycle 1

Oh, I missed to save the updated comment before I commited the change.
Can I just send and update patch instead of the whole series again?

> +	 * When on cycle == off cycle the PWM will be always on
> +	 */
Thierry Reding Nov. 20, 2012, 11:58 a.m. UTC | #2
On Tue, Nov 20, 2012 at 12:54:11PM +0100, Peter Ujfalusi wrote:
> On 11/20/2012 10:56 AM, Peter Ujfalusi wrote:
> > The driver supports the following LED outputs as generic PWM driver:
> > TWL4030 LEDA and LEDB (PWMA and PWMB)
> > TWL6030 Charging indicator LED (PWM LED)
> > 
> > On TWL6030 when the PWM requested LED is configured to be controlled by SW.
> > In this case the user can enable/disable and set the duty period freely.
> > When the PWM has been freed, the LED driver is put back to HW control.
> > 
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> > ---
> >  drivers/pwm/Kconfig       |  10 ++
> >  drivers/pwm/Makefile      |   1 +
> >  drivers/pwm/pwm-twl-led.c | 303 ++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 314 insertions(+)
> >  create mode 100644 drivers/pwm/pwm-twl-led.c
> 
> ...
> 
> > +static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > +			      int duty_ns, int period_ns)
> > +{
> > +	int duty_cycle = DIV_ROUND_UP(duty_ns * TWL4030_LED_MAX, period_ns);
> > +	u8 pwm_config[2] = {1, 0};
> > +	int base, ret;
> > +
> > +	/*
> > +	 * To configure the duty period:
> > +	 * On-cycle is set to 1 (the minimum allowed value)
> > +	 * The off time of 0 is not configurable, so the mapping is:
> > +	 * 0 -> off cycle = 2,
> > +	 * 1 -> off cycle = 2,
> > +	 * 2 -> off cycle = 3,
> > +	 * 125 - > off cycle 127,
> > +	 * 126 - > off cycle 1
> 
> Oh, I missed to save the updated comment before I commited the change.
> Can I just send and update patch instead of the whole series again?

Sure.

Sorry for taking so long to review this. I'm rather busy with other
things but I'll try to find some time to review properly tonight or
tomorrow.

Thierry
Peter Ujfalusi Nov. 23, 2012, 9:51 a.m. UTC | #3
Hi Thierry,

On 11/20/2012 12:58 PM, Thierry Reding wrote:
>> Oh, I missed to save the updated comment before I commited the change.
>> Can I just send and update patch instead of the whole series again?
> 
> Sure.
> 
> Sorry for taking so long to review this. I'm rather busy with other
> things but I'll try to find some time to review properly tonight or
> tomorrow.

I have sent the update patch for the series:
https://lkml.org/lkml/2012/11/20/268

I know you are busy, but would you be able to take a look at the series?

Thank you,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thierry Reding Nov. 23, 2012, 3:04 p.m. UTC | #4
On Tue, Nov 20, 2012 at 10:56:22AM +0100, Peter Ujfalusi wrote:
> The driver supports the following LED outputs as generic PWM driver:
> TWL4030 LEDA and LEDB (PWMA and PWMB)
> TWL6030 Charging indicator LED (PWM LED)
> 
> On TWL6030 when the PWM requested LED is configured to be controlled by SW.
> In this case the user can enable/disable and set the duty period freely.
> When the PWM has been freed, the LED driver is put back to HW control.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  drivers/pwm/Kconfig       |  10 ++
>  drivers/pwm/Makefile      |   1 +
>  drivers/pwm/pwm-twl-led.c | 303 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 314 insertions(+)
>  create mode 100644 drivers/pwm/pwm-twl-led.c

Doesn't this belong in the drivers/leds subsystem? Besides that, the
same comments as for the previous patch apply. One additional note
below.

> +static struct platform_driver twl_pwmled_driver = {
> +	.driver = {
> +		.name = "twl-pwmled",
> +		.of_match_table = of_match_ptr(twl_pwmled_of_match),
> +	},
> +	.probe = twl_pwmled_probe,
> +	.remove = __devexit_p(twl_pwmled_remove),

You didn't annotate twl_pwmled_remove() with __devexit, so __devexit_p
isn't needed here either.

Thierry
Peter Ujfalusi Nov. 26, 2012, 8:30 a.m. UTC | #5
On 11/23/2012 04:04 PM, Thierry Reding wrote:
> On Tue, Nov 20, 2012 at 10:56:22AM +0100, Peter Ujfalusi wrote:
>> The driver supports the following LED outputs as generic PWM driver:
>> TWL4030 LEDA and LEDB (PWMA and PWMB)
>> TWL6030 Charging indicator LED (PWM LED)
>>
>> On TWL6030 when the PWM requested LED is configured to be controlled by SW.
>> In this case the user can enable/disable and set the duty period freely.
>> When the PWM has been freed, the LED driver is put back to HW control.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>>  drivers/pwm/Kconfig       |  10 ++
>>  drivers/pwm/Makefile      |   1 +
>>  drivers/pwm/pwm-twl-led.c | 303 ++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 314 insertions(+)
>>  create mode 100644 drivers/pwm/pwm-twl-led.c
> 
> Doesn't this belong in the drivers/leds subsystem? Besides that, the
> same comments as for the previous patch apply. One additional note
> below.

The PINs itself are called as LED but they are PWMs at the end. If we
represent them as PWMs they can be used for different purposes which is going
to be needed for example in BeagleBoard, where the LEDA (PWMA) is used as a
GPO to enable/disable the USB host power.
Also the removed 'twl6030-pwm' driver was only controlled the LED part of twl6030.
With this series I enable the use of the PWMs and the PWMs behind of the LED
functions to give us flexibility on how we are using them.

> 
>> +static struct platform_driver twl_pwmled_driver = {
>> +	.driver = {
>> +		.name = "twl-pwmled",
>> +		.of_match_table = of_match_ptr(twl_pwmled_of_match),
>> +	},
>> +	.probe = twl_pwmled_probe,
>> +	.remove = __devexit_p(twl_pwmled_remove),
> 
> You didn't annotate twl_pwmled_remove() with __devexit, so __devexit_p
> isn't needed here either.

Oh yes, I have also received patches from a series which removes the
_devexit_p() from the kernel.
But should the __devexit need to be added to the remove function?
Thierry Reding Nov. 26, 2012, 9:17 a.m. UTC | #6
On Mon, Nov 26, 2012 at 09:30:03AM +0100, Peter Ujfalusi wrote:
> On 11/23/2012 04:04 PM, Thierry Reding wrote:
> > On Tue, Nov 20, 2012 at 10:56:22AM +0100, Peter Ujfalusi wrote:
> >> The driver supports the following LED outputs as generic PWM driver:
> >> TWL4030 LEDA and LEDB (PWMA and PWMB)
> >> TWL6030 Charging indicator LED (PWM LED)
> >>
> >> On TWL6030 when the PWM requested LED is configured to be controlled by SW.
> >> In this case the user can enable/disable and set the duty period freely.
> >> When the PWM has been freed, the LED driver is put back to HW control.
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> >> ---
> >>  drivers/pwm/Kconfig       |  10 ++
> >>  drivers/pwm/Makefile      |   1 +
> >>  drivers/pwm/pwm-twl-led.c | 303 ++++++++++++++++++++++++++++++++++++++++++++++
> >>  3 files changed, 314 insertions(+)
> >>  create mode 100644 drivers/pwm/pwm-twl-led.c
> > 
> > Doesn't this belong in the drivers/leds subsystem? Besides that, the
> > same comments as for the previous patch apply. One additional note
> > below.
> 
> The PINs itself are called as LED but they are PWMs at the end. If we
> represent them as PWMs they can be used for different purposes which is going
> to be needed for example in BeagleBoard, where the LEDA (PWMA) is used as a
> GPO to enable/disable the USB host power.

Heh, that's an interesting use-case for a PWM. =)

> Also the removed 'twl6030-pwm' driver was only controlled the LED part of twl6030.
> With this series I enable the use of the PWMs and the PWMs behind of the LED
> functions to give us flexibility on how we are using them.

Alright, we can keep it in the PWM subsystem then.

> >> +static struct platform_driver twl_pwmled_driver = {
> >> +	.driver = {
> >> +		.name = "twl-pwmled",
> >> +		.of_match_table = of_match_ptr(twl_pwmled_of_match),
> >> +	},
> >> +	.probe = twl_pwmled_probe,
> >> +	.remove = __devexit_p(twl_pwmled_remove),
> > 
> > You didn't annotate twl_pwmled_remove() with __devexit, so __devexit_p
> > isn't needed here either.
> 
> Oh yes, I have also received patches from a series which removes the
> _devexit_p() from the kernel.
> But should the __devexit need to be added to the remove function?

__devexit_p without a corresponding __devexit doesn't make sense. But as
all of __devinit, __devexit and __devexit_p will be removed sooner or
later, new code just shouldn't bother adding it. In this case, just drop
__devexit_p.

Thierry
Peter Ujfalusi Nov. 26, 2012, 9:33 a.m. UTC | #7
On 11/26/2012 10:17 AM, Thierry Reding wrote:
>>> Doesn't this belong in the drivers/leds subsystem? Besides that, the
>>> same comments as for the previous patch apply. One additional note
>>> below.
>>
>> The PINs itself are called as LED but they are PWMs at the end. If we
>> represent them as PWMs they can be used for different purposes which is going
>> to be needed for example in BeagleBoard, where the LEDA (PWMA) is used as a
>> GPO to enable/disable the USB host power.
> 
> Heh, that's an interesting use-case for a PWM. =)

You should have seen the expression on my face when I saw this on the
schematics ;)

>> Also the removed 'twl6030-pwm' driver was only controlled the LED part of twl6030.
>> With this series I enable the use of the PWMs and the PWMs behind of the LED
>> functions to give us flexibility on how we are using them.
> 
> Alright, we can keep it in the PWM subsystem then.

Thank you.

>>>> +static struct platform_driver twl_pwmled_driver = {
>>>> +	.driver = {
>>>> +		.name = "twl-pwmled",
>>>> +		.of_match_table = of_match_ptr(twl_pwmled_of_match),
>>>> +	},
>>>> +	.probe = twl_pwmled_probe,
>>>> +	.remove = __devexit_p(twl_pwmled_remove),
>>>
>>> You didn't annotate twl_pwmled_remove() with __devexit, so __devexit_p
>>> isn't needed here either.
>>
>> Oh yes, I have also received patches from a series which removes the
>> _devexit_p() from the kernel.
>> But should the __devexit need to be added to the remove function?
> 
> __devexit_p without a corresponding __devexit doesn't make sense. But as
> all of __devinit, __devexit and __devexit_p will be removed sooner or
> later, new code just shouldn't bother adding it. In this case, just drop
> __devexit_p.

I'll get rid of them.

Thank you,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c577db9..49c2082 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -152,6 +152,16 @@  config PWM_TWL
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-twl.
 
+config PWM_TWL_LED
+	tristate "TWL4030/6030 PWM support for LED drivers"
+	select HAVE_PWM
+	depends on TWL4030_CORE
+	help
+	  Generic PWM framework driver for TWL4030/6030 LED.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called pwm-twl-led.
+
 config PWM_VT8500
 	tristate "vt8500 pwm support"
 	depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 3324c06..5f26134 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,4 +12,5 @@  obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TWL)		+= pwm-twl.o
+obj-$(CONFIG_PWM_TWL_LED)	+= pwm-twl-led.o
 obj-$(CONFIG_PWM_VT8500)	+= pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
new file mode 100644
index 0000000..9468720
--- /dev/null
+++ b/drivers/pwm/pwm-twl-led.c
@@ -0,0 +1,303 @@ 
+/*
+ * Driver for TWL4030/6030 Pulse Width Modulator used as LED driver
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
+ *
+ * This driver is a complete rewrite of the former pwm-twl6030.c authorded by:
+ * Hemanth V <hemanthv@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/i2c/twl.h>
+#include <linux/slab.h>
+
+/*
+ * This driver handles the PWM driven LED terminals of TWL4030 and TWL6030.
+ * To generate the signal on TWL4030:
+ *  - LEDA uses PWMA
+ *  - LEDB uses PWMB
+ * TWL6030 has one LED pin with dedicated LEDPWM
+ */
+
+#define TWL4030_LED_MAX		0x7f
+#define TWL6030_LED_MAX		0xff
+
+/* Registers, bits and macro for TWL4030 */
+#define TWL4030_LEDEN_REG	0x00
+#define TWL4030_PWMA_REG	0x01
+
+#define TWL4030_LEDXON		(1 << 0)
+#define TWL4030_LEDXPWM		(1 << 4)
+#define TWL4030_LED_PINS	(TWL4030_LEDXON | TWL4030_LEDXPWM)
+#define TWL4030_LED_TOGGLE(led, x)	((x) << (led))
+
+/* Register, bits and macro for TWL6030 */
+#define TWL6030_LED_PWM_CTRL1	0xf4
+#define TWL6030_LED_PWM_CTRL2	0xf5
+
+#define TWL6040_LED_MODE_HW	0x00
+#define TWL6040_LED_MODE_ON	0x01
+#define TWL6040_LED_MODE_OFF	0x02
+#define TWL6040_LED_MODE_MASK	0x03
+
+struct twl_pwmled_chip {
+	struct pwm_chip chip;
+};
+
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device *pwm,
+			      int duty_ns, int period_ns)
+{
+	int duty_cycle = DIV_ROUND_UP(duty_ns * TWL4030_LED_MAX, period_ns);
+	u8 pwm_config[2] = {1, 0};
+	int base, ret;
+
+	/*
+	 * To configure the duty period:
+	 * On-cycle is set to 1 (the minimum allowed value)
+	 * The off time of 0 is not configurable, so the mapping is:
+	 * 0 -> off cycle = 2,
+	 * 1 -> off cycle = 2,
+	 * 2 -> off cycle = 3,
+	 * 125 - > off cycle 127,
+	 * 126 - > off cycle 1
+	 * When on cycle == off cycle the PWM will be always on
+	 */
+	duty_cycle += 1;
+	if (duty_cycle == 1)
+		duty_cycle = 2;
+	else if (duty_cycle > TWL4030_LED_MAX)
+		duty_cycle = 1;
+
+	base = pwm->hwpwm * 2 + TWL4030_PWMA_REG;
+
+	pwm_config[1] = duty_cycle;
+
+	ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to configure PWM\n", pwm->label);
+
+	return ret;
+}
+
+static int twl4030_pwmled_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	int ret;
+	u8 val;
+
+	ret = twl_i2c_read_u8(TWL4030_MODULE_LED, &val, TWL4030_LEDEN_REG);
+	if (ret < 0) {
+		dev_err(chip->dev, "%s: Failed to read LEDEN\n", pwm->label);
+		return ret;
+	}
+
+	val |= TWL4030_LED_TOGGLE(pwm->hwpwm, TWL4030_LED_PINS);
+
+	ret = twl_i2c_write_u8(TWL4030_MODULE_LED, val, TWL4030_LEDEN_REG);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to enable PWM\n", pwm->label);
+
+	return ret;
+}
+
+static void twl4030_pwmled_disable(struct pwm_chip *chip,
+				   struct pwm_device *pwm)
+{
+	int ret;
+	u8 val;
+
+	ret = twl_i2c_read_u8(TWL4030_MODULE_LED, &val, TWL4030_LEDEN_REG);
+	if (ret < 0) {
+		dev_err(chip->dev, "%s: Failed to read LEDEN\n", pwm->label);
+		return;
+	}
+
+	val &= ~TWL4030_LED_TOGGLE(pwm->hwpwm, TWL4030_LED_PINS);
+
+	ret = twl_i2c_write_u8(TWL4030_MODULE_LED, val, TWL4030_LEDEN_REG);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to disable PWM\n", pwm->label);
+}
+
+static int twl6030_pwmled_config(struct pwm_chip *chip, struct pwm_device *pwm,
+			      int duty_ns, int period_ns)
+{
+	int duty_cycle = (duty_ns * TWL6030_LED_MAX) / period_ns;
+	u8 on_time;
+	int ret;
+
+	on_time = duty_cycle & 0xff;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, on_time,
+			       TWL6030_LED_PWM_CTRL1);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to configure PWM\n", pwm->label);
+
+	return ret;
+}
+
+static int twl6030_pwmled_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	int ret;
+	u8 val;
+
+	ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0) {
+		dev_err(chip->dev, "%s: Failed to read PWM_CTRL2\n",
+			pwm->label);
+		return ret;
+	}
+
+	val &= ~TWL6040_LED_MODE_MASK;
+	val |= TWL6040_LED_MODE_ON;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to enable PWM\n", pwm->label);
+
+	return ret;
+}
+
+static void twl6030_pwmled_disable(struct pwm_chip *chip,
+				   struct pwm_device *pwm)
+{
+	int ret;
+	u8 val;
+
+	ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0) {
+		dev_err(chip->dev, "%s: Failed to read PWM_CTRL2\n",
+			pwm->label);
+		return;
+	}
+
+	val &= ~TWL6040_LED_MODE_MASK;
+	val |= TWL6040_LED_MODE_OFF;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to disable PWM\n", pwm->label);
+}
+
+static int twl6030_pwmled_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	int ret;
+	u8 val;
+
+	ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0) {
+		dev_err(chip->dev, "%s: Failed to read PWM_CTRL2\n",
+			pwm->label);
+		return ret;
+	}
+
+	val &= ~TWL6040_LED_MODE_MASK;
+	val |= TWL6040_LED_MODE_OFF;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to request PWM\n", pwm->label);
+
+	return ret;
+}
+
+static void twl6030_pwmled_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	int ret;
+	u8 val;
+
+	ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0) {
+		dev_err(chip->dev, "%s: Failed to read PWM_CTRL2\n",
+			pwm->label);
+		return;
+	}
+
+	val &= ~TWL6040_LED_MODE_MASK;
+	val |= TWL6040_LED_MODE_HW;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, TWL6030_LED_PWM_CTRL2);
+	if (ret < 0)
+		dev_err(chip->dev, "%s: Failed to free PWM\n", pwm->label);
+}
+
+static struct pwm_ops twl_pwmled_ops;
+
+static int twl_pwmled_probe(struct platform_device *pdev)
+{
+	struct twl_pwmled_chip *twl;
+	int ret;
+
+	twl = devm_kzalloc(&pdev->dev, sizeof(*twl), GFP_KERNEL);
+	if (!twl)
+		return -ENOMEM;
+
+	if (twl_class_is_4030()) {
+		twl_pwmled_ops.enable = twl4030_pwmled_enable;
+		twl_pwmled_ops.disable = twl4030_pwmled_disable;
+		twl_pwmled_ops.config = twl4030_pwmled_config;
+		twl->chip.npwm = 2;
+	} else {
+		twl_pwmled_ops.enable = twl6030_pwmled_enable;
+		twl_pwmled_ops.disable = twl6030_pwmled_disable;
+		twl_pwmled_ops.config = twl6030_pwmled_config;
+		twl_pwmled_ops.request = twl6030_pwmled_request;
+		twl_pwmled_ops.free = twl6030_pwmled_free;
+		twl->chip.npwm = 1;
+	}
+
+	twl->chip.dev = &pdev->dev;
+	twl->chip.ops = &twl_pwmled_ops;
+	twl->chip.base = -1;
+
+	ret = pwmchip_add(&twl->chip);
+	if (ret < 0)
+		return ret;
+
+	platform_set_drvdata(pdev, twl);
+
+	return 0;
+}
+
+static int twl_pwmled_remove(struct platform_device *pdev)
+{
+	struct twl_pwmled_chip *twl = platform_get_drvdata(pdev);
+
+	return pwmchip_remove(&twl->chip);
+}
+
+static struct of_device_id twl_pwmled_of_match[] = {
+	{ .compatible = "ti,twl4030-pwmled" },
+	{ .compatible = "ti,twl6030-pwmled" },
+};
+
+MODULE_DEVICE_TABLE(of, twl_pwmled_of_match);
+
+static struct platform_driver twl_pwmled_driver = {
+	.driver = {
+		.name = "twl-pwmled",
+		.of_match_table = of_match_ptr(twl_pwmled_of_match),
+	},
+	.probe = twl_pwmled_probe,
+	.remove = __devexit_p(twl_pwmled_remove),
+};
+module_platform_driver(twl_pwmled_driver);
+
+MODULE_AUTHOR("Peter Ujfalusi <peter.ujfalusi@ti.com>");
+MODULE_DESCRIPTION("PWM driver for TWL4030 and TWL6030 LED outputs");
+MODULE_ALIAS("platform:twl-pwm");
+MODULE_LICENSE("GPL");