[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Florian Vaussard]

Hello Benoit,

This patchset adds some new DT supports to the Overo products.
The first patch converts the PMIC LEDB output to use the pwm-leds,
newly merged in your branch for_3.9/dts. The second patch
adds the audio support.

Best regards,

Florian

Florian Vaussard (2):
  ARM: dts: omap3-overo: Add support for pwm-leds
  ARM: dts: omap3-overo: Add audio support

 arch/arm/boot/dts/omap3-overo.dtsi |   23 +++++++++++++++++++----
 1 files changed, 19 insertions(+), 4 deletions(-)

-- 
1.7.5.4

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Florian Vaussard]

Hello Benoit,

This patchset adds some new DT supports to the Overo products.
The first patch converts the PMIC LEDB output to use the pwm-leds,
newly merged in your branch for_3.9/dts. The second patch
adds the audio support.

Best regards,

Florian

Florian Vaussard (2):
  ARM: dts: omap3-overo: Add support for pwm-leds
  ARM: dts: omap3-overo: Add audio support

 arch/arm/boot/dts/omap3-overo.dtsi |   23 +++++++++++++++++++----
 1 files changed, 19 insertions(+), 4 deletions(-)

-- 
1.7.5.4

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

Convert the on-board LED connected to the TWL4030 (LEDB) to use
pwm-leds.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap3-overo.dtsi |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..800be29 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -14,12 +14,13 @@
 /include/ "omap3.dtsi"
 
 / {
-	leds {
-		compatible = "gpio-leds";
+	pwmleds {
+		compatible = "pwm-leds";
+
 		overo {
 			label = "overo:blue:COM";
-			gpios = <&twl_gpio 19 0>;
-			linux,default-trigger = "mmc0";
+			pwms = <&twl_pwmled 1 7812500>;
+			max-brightness = <127>;
 		};
 	};
 };
-- 
1.7.5.4

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

Convert the on-board LED connected to the TWL4030 (LEDB) to use
pwm-leds.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap3-overo.dtsi |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..800be29 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -14,12 +14,13 @@
 /include/ "omap3.dtsi"
 
 / {
-	leds {
-		compatible = "gpio-leds";
+	pwmleds {
+		compatible = "pwm-leds";
+
 		overo {
 			label = "overo:blue:COM";
-			gpios = <&twl_gpio 19 0>;
-			linux,default-trigger = "mmc0";
+			pwms = <&twl_pwmled 1 7812500>;
+			max-brightness = <127>;
 		};
 	};
 };
-- 
1.7.5.4

[PATCH 2/2] ARM: dts: omap3-overo: Add audio support

[Florian Vaussard]

Add the needed sections to enable audio support on Overo.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap3-overo.dtsi |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 800be29..81341fa 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -23,6 +23,14 @@
 			max-brightness = <127>;
 		};
 	};
+
+	sound {
+		compatible = "ti,omap-twl4030";
+		ti,model = "overo";
+
+		ti,mcbsp = <&mcbsp2>;
+		ti,codec = <&twl_audio>;
+	};
 };
 
 &i2c1 {
@@ -32,6 +40,12 @@
 		reg = <0x48>;
 		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
 		interrupt-parent = <&intc>;
+
+		twl_audio: audio {
+			compatible = "ti,twl4030-audio";
+			codec {
+			};
+		};
 	};
 };
 
-- 
1.7.5.4

[PATCH 2/2] ARM: dts: omap3-overo: Add audio support

[Florian Vaussard]

Add the needed sections to enable audio support on Overo.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap3-overo.dtsi |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 800be29..81341fa 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -23,6 +23,14 @@
 			max-brightness = <127>;
 		};
 	};
+
+	sound {
+		compatible = "ti,omap-twl4030";
+		ti,model = "overo";
+
+		ti,mcbsp = <&mcbsp2>;
+		ti,codec = <&twl_audio>;
+	};
 };
 
 &i2c1 {
@@ -32,6 +40,12 @@
 		reg = <0x48>;
 		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
 		interrupt-parent = <&intc>;
+
+		twl_audio: audio {
+			compatible = "ti,twl4030-audio";
+			codec {
+			};
+		};
 	};
 };
 
-- 
1.7.5.4

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Benoit Cousson]

+ Peter who did the original PWM

Hi Florian,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:
> Hello Benoit,
> 
> This patchset adds some new DT supports to the Overo products.
> The first patch converts the PMIC LEDB output to use the pwm-leds,
> newly merged in your branch for_3.9/dts. The second patch
> adds the audio support.

Excellent, that looks very good to me, but I'd like to get the feedback
from Peter before merging it.

Thanks,
Benoit

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Benoit Cousson]

+ Peter who did the original PWM

Hi Florian,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:
> Hello Benoit,
> 
> This patchset adds some new DT supports to the Overo products.
> The first patch converts the PMIC LEDB output to use the pwm-leds,
> newly merged in your branch for_3.9/dts. The second patch
> adds the audio support.

Excellent, that looks very good to me, but I'd like to get the feedback
from Peter before merging it.

Thanks,
Benoit

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

Hi,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:
> Convert the on-board LED connected to the TWL4030 (LEDB) to use
> pwm-leds.
> 
> Signed-off-by: Florian Vaussard <florian.vaussard-p8DiymsW2f8@public.gmane.org>
> ---
>  arch/arm/boot/dts/omap3-overo.dtsi |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
> index 89808ce..800be29 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -14,12 +14,13 @@
>  /include/ "omap3.dtsi"
>  
>  / {
> -	leds {
> -		compatible = "gpio-leds";
> +	pwmleds {
> +		compatible = "pwm-leds";
> +
>  		overo {
>  			label = "overo:blue:COM";
> -			gpios = <&twl_gpio 19 0>;
> -			linux,default-trigger = "mmc0";

You can keep the default trigger for the pwm-leds as well.
The best way to test this is on top of linux-next which already have the
leds-pwm DT bindings.

> +			pwms = <&twl_pwmled 1 7812500>;
> +			max-brightness = <127>;
>  		};
>  	};
>  };
> 


-- 
Péter

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

Hi,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:
> Convert the on-board LED connected to the TWL4030 (LEDB) to use
> pwm-leds.
> 
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  arch/arm/boot/dts/omap3-overo.dtsi |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
> index 89808ce..800be29 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -14,12 +14,13 @@
>  /include/ "omap3.dtsi"
>  
>  / {
> -	leds {
> -		compatible = "gpio-leds";
> +	pwmleds {
> +		compatible = "pwm-leds";
> +
>  		overo {
>  			label = "overo:blue:COM";
> -			gpios = <&twl_gpio 19 0>;
> -			linux,default-trigger = "mmc0";

You can keep the default trigger for the pwm-leds as well.
The best way to test this is on top of linux-next which already have the
leds-pwm DT bindings.

> +			pwms = <&twl_pwmled 1 7812500>;
> +			max-brightness = <127>;
>  		};
>  	};
>  };
> 


-- 
P?ter

Re: [PATCH 2/2] ARM: dts: omap3-overo: Add audio support

[Peter Ujfalusi]

Hi,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:
> Add the needed sections to enable audio support on Overo.

Looks fine for me.

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

> 
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  arch/arm/boot/dts/omap3-overo.dtsi |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
> index 800be29..81341fa 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -23,6 +23,14 @@
>  			max-brightness = <127>;
>  		};
>  	};
> +
> +	sound {
> +		compatible = "ti,omap-twl4030";
> +		ti,model = "overo";
> +
> +		ti,mcbsp = <&mcbsp2>;
> +		ti,codec = <&twl_audio>;
> +	};
>  };
>  
>  &i2c1 {
> @@ -32,6 +40,12 @@
>  		reg = <0x48>;
>  		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>  		interrupt-parent = <&intc>;
> +
> +		twl_audio: audio {
> +			compatible = "ti,twl4030-audio";
> +			codec {
> +			};
> +		};
>  	};
>  };
>  
> 


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

[PATCH 2/2] ARM: dts: omap3-overo: Add audio support

[Peter Ujfalusi]

Hi,

On 01/23/2013 06:56 PM, Florian Vaussard wrote:
> Add the needed sections to enable audio support on Overo.

Looks fine for me.

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

> 
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  arch/arm/boot/dts/omap3-overo.dtsi |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
> index 800be29..81341fa 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -23,6 +23,14 @@
>  			max-brightness = <127>;
>  		};
>  	};
> +
> +	sound {
> +		compatible = "ti,omap-twl4030";
> +		ti,model = "overo";
> +
> +		ti,mcbsp = <&mcbsp2>;
> +		ti,codec = <&twl_audio>;
> +	};
>  };
>  
>  &i2c1 {
> @@ -32,6 +40,12 @@
>  		reg = <0x48>;
>  		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>  		interrupt-parent = <&intc>;
> +
> +		twl_audio: audio {
> +			compatible = "ti,twl4030-audio";
> +			codec {
> +			};
> +		};
>  	};
>  };
>  
> 


-- 
P?ter

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

Hi Peter,

>>
>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
>> index 89808ce..800be29 100644
>> --- a/arch/arm/boot/dts/omap3-overo.dtsi
>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
>> @@ -14,12 +14,13 @@
>>   /include/ "omap3.dtsi"
>>
>>   / {
>> -	leds {
>> -		compatible = "gpio-leds";
>> +	pwmleds {
>> +		compatible = "pwm-leds";
>> +
>>   		overo {
>>   			label = "overo:blue:COM";
>> -			gpios = <&twl_gpio 19 0>;
>> -			linux,default-trigger = "mmc0";
>
> You can keep the default trigger for the pwm-leds as well.
> The best way to test this is on top of linux-next which already have the
> leds-pwm DT bindings.
>

I did it at first, but the led API executes in atomic context, where the 
pwm-twl-led driver uses i2c communication. Setting a trigger will result 
in a kernel panic.

I am working on a patch for pwm-twl-led to defer using a workqueue right 
now.

Cheers,

Florian

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

Hi Peter,

>>
>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
>> index 89808ce..800be29 100644
>> --- a/arch/arm/boot/dts/omap3-overo.dtsi
>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
>> @@ -14,12 +14,13 @@
>>   /include/ "omap3.dtsi"
>>
>>   / {
>> -	leds {
>> -		compatible = "gpio-leds";
>> +	pwmleds {
>> +		compatible = "pwm-leds";
>> +
>>   		overo {
>>   			label = "overo:blue:COM";
>> -			gpios = <&twl_gpio 19 0>;
>> -			linux,default-trigger = "mmc0";
>
> You can keep the default trigger for the pwm-leds as well.
> The best way to test this is on top of linux-next which already have the
> leds-pwm DT bindings.
>

I did it at first, but the led API executes in atomic context, where the 
pwm-twl-led driver uses i2c communication. Setting a trigger will result 
in a kernel panic.

I am working on a patch for pwm-twl-led to defer using a workqueue right 
now.

Cheers,

Florian

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/24/2013 04:42 PM, Florian Vaussard wrote:
> I did it at first, but the led API executes in atomic context, where the
> pwm-twl-led driver uses i2c communication. Setting a trigger will result in a
> kernel panic.

Now that you mentioned it, this might be true.

> I am working on a patch for pwm-twl-led to defer using a workqueue right now.

Great!
The only thing I worry about is the latency we are going to get with the
workqueue.

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

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/24/2013 04:42 PM, Florian Vaussard wrote:
> I did it at first, but the led API executes in atomic context, where the
> pwm-twl-led driver uses i2c communication. Setting a trigger will result in a
> kernel panic.

Now that you mentioned it, this might be true.

> I am working on a patch for pwm-twl-led to defer using a workqueue right now.

Great!
The only thing I worry about is the latency we are going to get with the
workqueue.

-- 
P?ter

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

>> I did it at first, but the led API executes in atomic context, where the
>> pwm-twl-led driver uses i2c communication. Setting a trigger will result in a
>> kernel panic.
>
> Now that you mentioned it, this might be true.
>

[<c0013204>] (unwind_backtrace+0x0/0xec) from [<c00348ac>] 
(warn_slowpath_common+0x4c/0x64)
[<c00348ac>] (warn_slowpath_common+0x4c/0x64) from [<c00348e0>] 
(warn_slowpath_null+0x1c/0x24)
[<c00348e0>] (warn_slowpath_null+0x1c/0x24) from [<c054d384>] 
(__mutex_lock_slowpath+0x6c/0x26c)
[<c054d384>] (__mutex_lock_slowpath+0x6c/0x26c) from [<c054d590>] 
(mutex_lock+0xc/0x20)
[<c054d590>] (mutex_lock+0xc/0x20) from [<c02d740c>] 
(regmap_bulk_write+0x48/0x138)
[<c02d740c>] (regmap_bulk_write+0x48/0x138) from [<c02de2c0>] 
(twl_i2c_write+0xa4/0xf0)
[<c02de2c0>] (twl_i2c_write+0xa4/0xf0) from [<c0299e34>] 
(twl4030_pwmled_config+0x70/0x9c)
[<c0299e34>] (twl4030_pwmled_config+0x70/0x9c) from [<c029875c>] 
(pwm_config+0x5c/0x6c)
[<c029875c>] (pwm_config+0x5c/0x6c) from [<c039dc04>] 
(led_pwm_set+0x28/0x64)
[<c039dc04>] (led_pwm_set+0x28/0x64) from [<c039e27c>] 
(led_heartbeat_function+0x10c/0x134)
[<c039e27c>] (led_heartbeat_function+0x10c/0x134) from [<c004359c>] 
(call_timer_fn+0x90/0x178)
[<c004359c>] (call_timer_fn+0x90/0x178) from [<c0043994>] 
(run_timer_softirq+0x250/0x2c8)
[<c0043994>] (run_timer_softirq+0x250/0x2c8) from [<c003cf78>] 
(__do_softirq+0xf8/0x248)
[<c003cf78>] (__do_softirq+0xf8/0x248) from [<c003d154>] 
(irq_exit+0x44/0x98)
[<c003d154>] (irq_exit+0x44/0x98) from [<c000e338>] (handle_IRQ+0x68/0x8c)
[<c000e338>] (handle_IRQ+0x68/0x8c) from [<c000870c>] 
(omap3_intc_handle_irq+0x58/0x70)
[<c000870c>] (omap3_intc_handle_irq+0x58/0x70) from [<c054f8c0>] 
(__irq_svc+0x40/0x70)
Exception stack(0xc077df60 to 0xc077dfa8)

:-)

>> I am working on a patch for pwm-twl-led to defer using a workqueue right now.
>
> Great!
> The only thing I worry about is the latency we are going to get with the
> workqueue.
>

If the latency becomes critical, we can create our own workqueue.

Do we merge anyway this patchset, or do we wait until the trigger has 
been fixed?

Florian

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

>> I did it at first, but the led API executes in atomic context, where the
>> pwm-twl-led driver uses i2c communication. Setting a trigger will result in a
>> kernel panic.
>
> Now that you mentioned it, this might be true.
>

[<c0013204>] (unwind_backtrace+0x0/0xec) from [<c00348ac>] 
(warn_slowpath_common+0x4c/0x64)
[<c00348ac>] (warn_slowpath_common+0x4c/0x64) from [<c00348e0>] 
(warn_slowpath_null+0x1c/0x24)
[<c00348e0>] (warn_slowpath_null+0x1c/0x24) from [<c054d384>] 
(__mutex_lock_slowpath+0x6c/0x26c)
[<c054d384>] (__mutex_lock_slowpath+0x6c/0x26c) from [<c054d590>] 
(mutex_lock+0xc/0x20)
[<c054d590>] (mutex_lock+0xc/0x20) from [<c02d740c>] 
(regmap_bulk_write+0x48/0x138)
[<c02d740c>] (regmap_bulk_write+0x48/0x138) from [<c02de2c0>] 
(twl_i2c_write+0xa4/0xf0)
[<c02de2c0>] (twl_i2c_write+0xa4/0xf0) from [<c0299e34>] 
(twl4030_pwmled_config+0x70/0x9c)
[<c0299e34>] (twl4030_pwmled_config+0x70/0x9c) from [<c029875c>] 
(pwm_config+0x5c/0x6c)
[<c029875c>] (pwm_config+0x5c/0x6c) from [<c039dc04>] 
(led_pwm_set+0x28/0x64)
[<c039dc04>] (led_pwm_set+0x28/0x64) from [<c039e27c>] 
(led_heartbeat_function+0x10c/0x134)
[<c039e27c>] (led_heartbeat_function+0x10c/0x134) from [<c004359c>] 
(call_timer_fn+0x90/0x178)
[<c004359c>] (call_timer_fn+0x90/0x178) from [<c0043994>] 
(run_timer_softirq+0x250/0x2c8)
[<c0043994>] (run_timer_softirq+0x250/0x2c8) from [<c003cf78>] 
(__do_softirq+0xf8/0x248)
[<c003cf78>] (__do_softirq+0xf8/0x248) from [<c003d154>] 
(irq_exit+0x44/0x98)
[<c003d154>] (irq_exit+0x44/0x98) from [<c000e338>] (handle_IRQ+0x68/0x8c)
[<c000e338>] (handle_IRQ+0x68/0x8c) from [<c000870c>] 
(omap3_intc_handle_irq+0x58/0x70)
[<c000870c>] (omap3_intc_handle_irq+0x58/0x70) from [<c054f8c0>] 
(__irq_svc+0x40/0x70)
Exception stack(0xc077df60 to 0xc077dfa8)

:-)

>> I am working on a patch for pwm-twl-led to defer using a workqueue right now.
>
> Great!
> The only thing I worry about is the latency we are going to get with the
> workqueue.
>

If the latency becomes critical, we can create our own workqueue.

Do we merge anyway this patchset, or do we wait until the trigger has 
been fixed?

Florian

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/24/2013 05:50 PM, Florian Vaussard wrote:
>>> I did it at first, but the led API executes in atomic context, where the
>>> pwm-twl-led driver uses i2c communication. Setting a trigger will result in a
>>> kernel panic.
>>
>> Now that you mentioned it, this might be true.
>>
> 
> [<c0013204>] (unwind_backtrace+0x0/0xec) from [<c00348ac>]
> (warn_slowpath_common+0x4c/0x64)
> [<c00348ac>] (warn_slowpath_common+0x4c/0x64) from [<c00348e0>]
> (warn_slowpath_null+0x1c/0x24)
> [<c00348e0>] (warn_slowpath_null+0x1c/0x24) from [<c054d384>]
> (__mutex_lock_slowpath+0x6c/0x26c)
> [<c054d384>] (__mutex_lock_slowpath+0x6c/0x26c) from [<c054d590>]
> (mutex_lock+0xc/0x20)
> [<c054d590>] (mutex_lock+0xc/0x20) from [<c02d740c>]
> (regmap_bulk_write+0x48/0x138)
> [<c02d740c>] (regmap_bulk_write+0x48/0x138) from [<c02de2c0>]
> (twl_i2c_write+0xa4/0xf0)
> [<c02de2c0>] (twl_i2c_write+0xa4/0xf0) from [<c0299e34>]
> (twl4030_pwmled_config+0x70/0x9c)
> [<c0299e34>] (twl4030_pwmled_config+0x70/0x9c) from [<c029875c>]
> (pwm_config+0x5c/0x6c)
> [<c029875c>] (pwm_config+0x5c/0x6c) from [<c039dc04>] (led_pwm_set+0x28/0x64)
> [<c039dc04>] (led_pwm_set+0x28/0x64) from [<c039e27c>]
> (led_heartbeat_function+0x10c/0x134)
> [<c039e27c>] (led_heartbeat_function+0x10c/0x134) from [<c004359c>]
> (call_timer_fn+0x90/0x178)
> [<c004359c>] (call_timer_fn+0x90/0x178) from [<c0043994>]
> (run_timer_softirq+0x250/0x2c8)
> [<c0043994>] (run_timer_softirq+0x250/0x2c8) from [<c003cf78>]
> (__do_softirq+0xf8/0x248)
> [<c003cf78>] (__do_softirq+0xf8/0x248) from [<c003d154>] (irq_exit+0x44/0x98)
> [<c003d154>] (irq_exit+0x44/0x98) from [<c000e338>] (handle_IRQ+0x68/0x8c)
> [<c000e338>] (handle_IRQ+0x68/0x8c) from [<c000870c>]
> (omap3_intc_handle_irq+0x58/0x70)
> [<c000870c>] (omap3_intc_handle_irq+0x58/0x70) from [<c054f8c0>]
> (__irq_svc+0x40/0x70)
> Exception stack(0xc077df60 to 0xc077dfa8)
> 
> :-)
> 
>>> I am working on a patch for pwm-twl-led to defer using a workqueue right now.
>>
>> Great!
>> The only thing I worry about is the latency we are going to get with the
>> workqueue.
>>
> 
> If the latency becomes critical, we can create our own workqueue.

Hrm, when we handled the led via gpio-leds it was also going through the same
path at the end, via i2c to twl4030.
I think the fix for this is going to be needed in the pwm core level. Just
need to look at the gpio code to have similar handling of might_sleep interfaces.

> Do we merge anyway this patchset, or do we wait until the trigger has been fixed?

I think it can go and later when we have the fix for the slow path you can add
the default trigger.

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/24/2013 05:50 PM, Florian Vaussard wrote:
>>> I did it at first, but the led API executes in atomic context, where the
>>> pwm-twl-led driver uses i2c communication. Setting a trigger will result in a
>>> kernel panic.
>>
>> Now that you mentioned it, this might be true.
>>
> 
> [<c0013204>] (unwind_backtrace+0x0/0xec) from [<c00348ac>]
> (warn_slowpath_common+0x4c/0x64)
> [<c00348ac>] (warn_slowpath_common+0x4c/0x64) from [<c00348e0>]
> (warn_slowpath_null+0x1c/0x24)
> [<c00348e0>] (warn_slowpath_null+0x1c/0x24) from [<c054d384>]
> (__mutex_lock_slowpath+0x6c/0x26c)
> [<c054d384>] (__mutex_lock_slowpath+0x6c/0x26c) from [<c054d590>]
> (mutex_lock+0xc/0x20)
> [<c054d590>] (mutex_lock+0xc/0x20) from [<c02d740c>]
> (regmap_bulk_write+0x48/0x138)
> [<c02d740c>] (regmap_bulk_write+0x48/0x138) from [<c02de2c0>]
> (twl_i2c_write+0xa4/0xf0)
> [<c02de2c0>] (twl_i2c_write+0xa4/0xf0) from [<c0299e34>]
> (twl4030_pwmled_config+0x70/0x9c)
> [<c0299e34>] (twl4030_pwmled_config+0x70/0x9c) from [<c029875c>]
> (pwm_config+0x5c/0x6c)
> [<c029875c>] (pwm_config+0x5c/0x6c) from [<c039dc04>] (led_pwm_set+0x28/0x64)
> [<c039dc04>] (led_pwm_set+0x28/0x64) from [<c039e27c>]
> (led_heartbeat_function+0x10c/0x134)
> [<c039e27c>] (led_heartbeat_function+0x10c/0x134) from [<c004359c>]
> (call_timer_fn+0x90/0x178)
> [<c004359c>] (call_timer_fn+0x90/0x178) from [<c0043994>]
> (run_timer_softirq+0x250/0x2c8)
> [<c0043994>] (run_timer_softirq+0x250/0x2c8) from [<c003cf78>]
> (__do_softirq+0xf8/0x248)
> [<c003cf78>] (__do_softirq+0xf8/0x248) from [<c003d154>] (irq_exit+0x44/0x98)
> [<c003d154>] (irq_exit+0x44/0x98) from [<c000e338>] (handle_IRQ+0x68/0x8c)
> [<c000e338>] (handle_IRQ+0x68/0x8c) from [<c000870c>]
> (omap3_intc_handle_irq+0x58/0x70)
> [<c000870c>] (omap3_intc_handle_irq+0x58/0x70) from [<c054f8c0>]
> (__irq_svc+0x40/0x70)
> Exception stack(0xc077df60 to 0xc077dfa8)
> 
> :-)
> 
>>> I am working on a patch for pwm-twl-led to defer using a workqueue right now.
>>
>> Great!
>> The only thing I worry about is the latency we are going to get with the
>> workqueue.
>>
> 
> If the latency becomes critical, we can create our own workqueue.

Hrm, when we handled the led via gpio-leds it was also going through the same
path at the end, via i2c to twl4030.
I think the fix for this is going to be needed in the pwm core level. Just
need to look at the gpio code to have similar handling of might_sleep interfaces.

> Do we merge anyway this patchset, or do we wait until the trigger has been fixed?

I think it can go and later when we have the fix for the slow path you can add
the default trigger.

Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

Hi

>>
>>>> I am working on a patch for pwm-twl-led to defer using a workqueue right now.
>>>
>>> Great!
>>> The only thing I worry about is the latency we are going to get with the
>>> workqueue.
>>>
>>
>> If the latency becomes critical, we can create our own workqueue.
>
> Hrm, when we handled the led via gpio-leds it was also going through the same
> path at the end, via i2c to twl4030.
> I think the fix for this is going to be needed in the pwm core level. Just
> need to look at the gpio code to have similar handling of might_sleep interfaces.
>

You are right. But then the pwm core must provide a way to know if the 
pwm access function are callable
from atomic context or not (the gpio framework provides gpio_cansleep()).
This implies a good amount of changes to the pwm framework, and 
currently we are the only driver using
non-atomic access.

I will take a closer look to the complexity of this solution tomorrow.

Florian

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

Hi

>>
>>>> I am working on a patch for pwm-twl-led to defer using a workqueue right now.
>>>
>>> Great!
>>> The only thing I worry about is the latency we are going to get with the
>>> workqueue.
>>>
>>
>> If the latency becomes critical, we can create our own workqueue.
>
> Hrm, when we handled the led via gpio-leds it was also going through the same
> path at the end, via i2c to twl4030.
> I think the fix for this is going to be needed in the pwm core level. Just
> need to look at the gpio code to have similar handling of might_sleep interfaces.
>

You are right. But then the pwm core must provide a way to know if the 
pwm access function are callable
from atomic context or not (the gpio framework provides gpio_cansleep()).
This implies a good amount of changes to the pwm framework, and 
currently we are the only driver using
non-atomic access.

I will take a closer look to the complexity of this solution tomorrow.

Florian

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/24/2013 10:14 PM, Florian Vaussard wrote:
> You are right. But then the pwm core must provide a way to know if the pwm
> access function are callable
> from atomic context or not (the gpio framework provides gpio_cansleep()).
> This implies a good amount of changes to the pwm framework, and currently we
> are the only driver using non-atomic access.

We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
SoC PWM drivers might come (for example for palmas). So it worth take a look
at some generic implementation.

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

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/24/2013 10:14 PM, Florian Vaussard wrote:
> You are right. But then the pwm core must provide a way to know if the pwm
> access function are callable
> from atomic context or not (the gpio framework provides gpio_cansleep()).
> This implies a good amount of changes to the pwm framework, and currently we
> are the only driver using non-atomic access.

We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
SoC PWM drivers might come (for example for palmas). So it worth take a look
at some generic implementation.

-- 
P?ter

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/25/2013 09:29 AM, Peter Ujfalusi wrote:
> On 01/24/2013 10:14 PM, Florian Vaussard wrote:
>> You are right. But then the pwm core must provide a way to know if the pwm
>> access function are callable
>> from atomic context or not (the gpio framework provides gpio_cansleep()).
>> This implies a good amount of changes to the pwm framework, and currently we
>> are the only driver using non-atomic access.
> 
> We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
> SoC PWM drivers might come (for example for palmas). So it worth take a look
> at some generic implementation.

OK. So I have the series. I need to add few more things but pwm-leds on
BeagleBoard works fine when I put the default_trigger for the pmustat LED to
be mmc0. It is blinking happily ;)
I'll CC you with the patches when I send them.

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

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/25/2013 09:29 AM, Peter Ujfalusi wrote:
> On 01/24/2013 10:14 PM, Florian Vaussard wrote:
>> You are right. But then the pwm core must provide a way to know if the pwm
>> access function are callable
>> from atomic context or not (the gpio framework provides gpio_cansleep()).
>> This implies a good amount of changes to the pwm framework, and currently we
>> are the only driver using non-atomic access.
> 
> We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
> SoC PWM drivers might come (for example for palmas). So it worth take a look
> at some generic implementation.

OK. So I have the series. I need to add few more things but pwm-leds on
BeagleBoard works fine when I put the default_trigger for the pmustat LED to
be mmc0. It is blinking happily ;)
I'll CC you with the patches when I send them.

-- 
P?ter

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

>>
>> We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
>> SoC PWM drivers might come (for example for palmas). So it worth take a look
>> at some generic implementation.
>
> OK. So I have the series. I need to add few more things but pwm-leds on
> BeagleBoard works fine when I put the default_trigger for the pmustat LED to
> be mmc0. It is blinking happily ;)
> I'll CC you with the patches when I send them.
>

I sent a patchset 2 hours ago with you in CC, you haven't received them?

Cheers,

Florian

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Florian Vaussard]

>>
>> We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
>> SoC PWM drivers might come (for example for palmas). So it worth take a look
>> at some generic implementation.
>
> OK. So I have the series. I need to add few more things but pwm-leds on
> BeagleBoard works fine when I put the default_trigger for the pmustat LED to
> be mmc0. It is blinking happily ;)
> I'll CC you with the patches when I send them.
>

I sent a patchset 2 hours ago with you in CC, you haven't received them?

Cheers,

Florian

Re: [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/25/2013 01:21 PM, Florian Vaussard wrote:
>>>
>>> We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
>>> SoC PWM drivers might come (for example for palmas). So it worth take a look
>>> at some generic implementation.
>>
>> OK. So I have the series. I need to add few more things but pwm-leds on
>> BeagleBoard works fine when I put the default_trigger for the pmustat LED to
>> be mmc0. It is blinking happily ;)
>> I'll CC you with the patches when I send them.
>>
> 
> I sent a patchset 2 hours ago with you in CC, you haven't received them?

I have not noticed them. Going through them right now.

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

[PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds

[Peter Ujfalusi]

On 01/25/2013 01:21 PM, Florian Vaussard wrote:
>>>
>>> We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
>>> SoC PWM drivers might come (for example for palmas). So it worth take a look
>>> at some generic implementation.
>>
>> OK. So I have the series. I need to add few more things but pwm-leds on
>> BeagleBoard works fine when I put the default_trigger for the pmustat LED to
>> be mmc0. It is blinking happily ;)
>> I'll CC you with the patches when I send them.
>>
> 
> I sent a patchset 2 hours ago with you in CC, you haven't received them?

I have not noticed them. Going through them right now.

-- 
P?ter

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Florian Vaussard]

Hello Benoit,

On 01/24/2013 01:21 PM, Benoit Cousson wrote:
> + Peter who did the original PWM
>
> Hi Florian,
>
> On 01/23/2013 06:56 PM, Florian Vaussard wrote:
>> Hello Benoit,
>>
>> This patchset adds some new DT supports to the Overo products. The
>> first patch converts the PMIC LEDB output to use the pwm-leds,
>> newly merged in your branch for_3.9/dts. The second patch adds the
>> audio support.
>
> Excellent, that looks very good to me, but I'd like to get the
> feedback from Peter before merging it.
>

So a patch is being merged to handle triggers in the case of pwm leds [1].
When done, we will be able to add back the default trigger. Do you want
to wait on it to merge this series?

Regards,

Florian

[1] https://patchwork.kernel.org/patch/2056191/

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Florian Vaussard]

Hello Benoit,

On 01/24/2013 01:21 PM, Benoit Cousson wrote:
> + Peter who did the original PWM
>
> Hi Florian,
>
> On 01/23/2013 06:56 PM, Florian Vaussard wrote:
>> Hello Benoit,
>>
>> This patchset adds some new DT supports to the Overo products. The
>> first patch converts the PMIC LEDB output to use the pwm-leds,
>> newly merged in your branch for_3.9/dts. The second patch adds the
>> audio support.
>
> Excellent, that looks very good to me, but I'd like to get the
> feedback from Peter before merging it.
>

So a patch is being merged to handle triggers in the case of pwm leds [1].
When done, we will be able to add back the default trigger. Do you want
to wait on it to merge this series?

Regards,

Florian

[1] https://patchwork.kernel.org/patch/2056191/

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Benoit Cousson]

Salut Florian,

On 02/04/2013 10:14 AM, Florian Vaussard wrote:
> Hello Benoit,
> 
> On 01/24/2013 01:21 PM, Benoit Cousson wrote:
>> + Peter who did the original PWM
>>
>> Hi Florian,
>>
>> On 01/23/2013 06:56 PM, Florian Vaussard wrote:
>>> Hello Benoit,
>>>
>>> This patchset adds some new DT supports to the Overo products. The
>>> first patch converts the PMIC LEDB output to use the pwm-leds,
>>> newly merged in your branch for_3.9/dts. The second patch adds the
>>> audio support.
>>
>> Excellent, that looks very good to me, but I'd like to get the
>> feedback from Peter before merging it.
>>
> 
> So a patch is being merged to handle triggers in the case of pwm leds [1].
> When done, we will be able to add back the default trigger. Do you want
> to wait on it to merge this series?

What kind of dependency do we have between these two series? I mean what
will happen if the DTS is merged before the pwm subsystem?

If that does not generate any regression / crash, then it is OK, if not,
we should take care of the order.

Thanks,
Benoit

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Benoit Cousson]

Salut Florian,

On 02/04/2013 10:14 AM, Florian Vaussard wrote:
> Hello Benoit,
> 
> On 01/24/2013 01:21 PM, Benoit Cousson wrote:
>> + Peter who did the original PWM
>>
>> Hi Florian,
>>
>> On 01/23/2013 06:56 PM, Florian Vaussard wrote:
>>> Hello Benoit,
>>>
>>> This patchset adds some new DT supports to the Overo products. The
>>> first patch converts the PMIC LEDB output to use the pwm-leds,
>>> newly merged in your branch for_3.9/dts. The second patch adds the
>>> audio support.
>>
>> Excellent, that looks very good to me, but I'd like to get the
>> feedback from Peter before merging it.
>>
> 
> So a patch is being merged to handle triggers in the case of pwm leds [1].
> When done, we will be able to add back the default trigger. Do you want
> to wait on it to merge this series?

What kind of dependency do we have between these two series? I mean what
will happen if the DTS is merged before the pwm subsystem?

If that does not generate any regression / crash, then it is OK, if not,
we should take care of the order.

Thanks,
Benoit

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Philippe Rétornaz]

Hi all !

Le 06/02/2013 14:30, Benoit Cousson a écrit :
> Salut Florian,
>
> On 02/04/2013 10:14 AM, Florian Vaussard wrote:
>> Hello Benoit,
>>
>> On 01/24/2013 01:21 PM, Benoit Cousson wrote:
>>> + Peter who did the original PWM
>>>
>>> Hi Florian,
>>>
>>> On 01/23/2013 06:56 PM, Florian Vaussard wrote:
>>>> Hello Benoit,
>>>>
>>>> This patchset adds some new DT supports to the Overo products.
>>>> The first patch converts the PMIC LEDB output to use the
>>>> pwm-leds, newly merged in your branch for_3.9/dts. The second
>>>> patch adds the audio support.
>>>
>>> Excellent, that looks very good to me, but I'd like to get the
>>> feedback from Peter before merging it.
>>>
>>
>> So a patch is being merged to handle triggers in the case of pwm
>> leds [1]. When done, we will be able to add back the default
>> trigger. Do you want to wait on it to merge this series?
>
> What kind of dependency do we have between these two series? I mean
> what will happen if the DTS is merged before the pwm subsystem?
>
> If that does not generate any regression / crash, then it is OK, if
> not, we should take care of the order.

Florian is on holiday the next two weeks.

AFAIK if the PWM/leds subsystem patches are not merged before this one
then the kernel will panic if a trigger is used to change the led status.

Regards,

Philippe

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Philippe Rétornaz]

Hi all !

Le 06/02/2013 14:30, Benoit Cousson a ?crit :
> Salut Florian,
>
> On 02/04/2013 10:14 AM, Florian Vaussard wrote:
>> Hello Benoit,
>>
>> On 01/24/2013 01:21 PM, Benoit Cousson wrote:
>>> + Peter who did the original PWM
>>>
>>> Hi Florian,
>>>
>>> On 01/23/2013 06:56 PM, Florian Vaussard wrote:
>>>> Hello Benoit,
>>>>
>>>> This patchset adds some new DT supports to the Overo products.
>>>> The first patch converts the PMIC LEDB output to use the
>>>> pwm-leds, newly merged in your branch for_3.9/dts. The second
>>>> patch adds the audio support.
>>>
>>> Excellent, that looks very good to me, but I'd like to get the
>>> feedback from Peter before merging it.
>>>
>>
>> So a patch is being merged to handle triggers in the case of pwm
>> leds [1]. When done, we will be able to add back the default
>> trigger. Do you want to wait on it to merge this series?
>
> What kind of dependency do we have between these two series? I mean
> what will happen if the DTS is merged before the pwm subsystem?
>
> If that does not generate any regression / crash, then it is OK, if
> not, we should take care of the order.

Florian is on holiday the next two weeks.

AFAIK if the PWM/leds subsystem patches are not merged before this one
then the kernel will panic if a trigger is used to change the led status.

Regards,

Philippe

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Peter Ujfalusi]

Hi,

On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>> So a patch is being merged to handle triggers in the case of pwm leds [1].
>> When done, we will be able to add back the default trigger. Do you want
>> to wait on it to merge this series?
> 
> What kind of dependency do we have between these two series? I mean what
> will happen if the DTS is merged before the pwm subsystem?
> 
> If that does not generate any regression / crash, then it is OK, if not,
> we should take care of the order.

In this series the 'linux,default-trigger' property is not added to the
pwm-leds node, so it is safe to take this series.
I'm sure Florian will send the update to add this flag back for 3.10 or for
3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9).

I'm also waiting for 3.9-rc1 so I can finish up some of the pending things
regarding to PWMs.

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

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Peter Ujfalusi]

Hi,

On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>> So a patch is being merged to handle triggers in the case of pwm leds [1].
>> When done, we will be able to add back the default trigger. Do you want
>> to wait on it to merge this series?
> 
> What kind of dependency do we have between these two series? I mean what
> will happen if the DTS is merged before the pwm subsystem?
> 
> If that does not generate any regression / crash, then it is OK, if not,
> we should take care of the order.

In this series the 'linux,default-trigger' property is not added to the
pwm-leds node, so it is safe to take this series.
I'm sure Florian will send the update to add this flag back for 3.10 or for
3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9).

I'm also waiting for 3.9-rc1 so I can finish up some of the pending things
regarding to PWMs.

-- 
P?ter

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Florian Vaussard]

Hi,

On 02/07/2013 08:58 AM, Peter Ujfalusi wrote:
> Hi,
>
> On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>>> So a patch is being merged to handle triggers in the case of pwm leds [1].
>>> When done, we will be able to add back the default trigger. Do you want
>>> to wait on it to merge this series?
>>
>> What kind of dependency do we have between these two series? I mean what
>> will happen if the DTS is merged before the pwm subsystem?
>>
>> If that does not generate any regression / crash, then it is OK, if not,
>> we should take care of the order.
>
> In this series the 'linux,default-trigger' property is not added to the
> pwm-leds node, so it is safe to take this series.
> I'm sure Florian will send the update to add this flag back for 3.10 or for
> 3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9).
>

Yes, it is safe to take this series. I will provide a patch to add back
the trigger when it is safe to.

Regards,

Florian

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Florian Vaussard]

Hi,

On 02/07/2013 08:58 AM, Peter Ujfalusi wrote:
> Hi,
>
> On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>>> So a patch is being merged to handle triggers in the case of pwm leds [1].
>>> When done, we will be able to add back the default trigger. Do you want
>>> to wait on it to merge this series?
>>
>> What kind of dependency do we have between these two series? I mean what
>> will happen if the DTS is merged before the pwm subsystem?
>>
>> If that does not generate any regression / crash, then it is OK, if not,
>> we should take care of the order.
>
> In this series the 'linux,default-trigger' property is not added to the
> pwm-leds node, so it is safe to take this series.
> I'm sure Florian will send the update to add this flag back for 3.10 or for
> 3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9).
>

Yes, it is safe to take this series. I will provide a patch to add back
the trigger when it is safe to.

Regards,

Florian

Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Benoit Cousson]

Hi Florian,

On 02/26/2013 05:07 PM, Florian Vaussard wrote:
> Hi,
> 
> On 02/07/2013 08:58 AM, Peter Ujfalusi wrote:
>> Hi,
>>
>> On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>>>> So a patch is being merged to handle triggers in the case of pwm
>>>> leds [1].
>>>> When done, we will be able to add back the default trigger. Do you want
>>>> to wait on it to merge this series?
>>>
>>> What kind of dependency do we have between these two series? I mean what
>>> will happen if the DTS is merged before the pwm subsystem?
>>>
>>> If that does not generate any regression / crash, then it is OK, if not,
>>> we should take care of the order.
>>
>> In this series the 'linux,default-trigger' property is not added to the
>> pwm-leds node, so it is safe to take this series.
>> I'm sure Florian will send the update to add this flag back for 3.10
>> or for
>> 3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9).
>>
> 
> Yes, it is safe to take this series. I will provide a patch to add back
> the trigger when it is safe to.

OK, great, I'll take the series then.

Thanks,
Benoit

[PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support

[Benoit Cousson]

Hi Florian,

On 02/26/2013 05:07 PM, Florian Vaussard wrote:
> Hi,
> 
> On 02/07/2013 08:58 AM, Peter Ujfalusi wrote:
>> Hi,
>>
>> On 02/06/2013 02:30 PM, Benoit Cousson wrote:
>>>> So a patch is being merged to handle triggers in the case of pwm
>>>> leds [1].
>>>> When done, we will be able to add back the default trigger. Do you want
>>>> to wait on it to merge this series?
>>>
>>> What kind of dependency do we have between these two series? I mean what
>>> will happen if the DTS is merged before the pwm subsystem?
>>>
>>> If that does not generate any regression / crash, then it is OK, if not,
>>> we should take care of the order.
>>
>> In this series the 'linux,default-trigger' property is not added to the
>> pwm-leds node, so it is safe to take this series.
>> I'm sure Florian will send the update to add this flag back for 3.10
>> or for
>> 3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9).
>>
> 
> Yes, it is safe to take this series. I will provide a patch to add back
> the trigger when it is safe to.

OK, great, I'll take the series then.

Thanks,
Benoit