ARM: dts: omap3-overo: Add pwm-leds and audio support

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

Signed-off-by Florian Vaussard <[email protected]>

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

arch/arm/boot/dts/omap3-overo.dtsi +0 -0

index 89808ce..800be29 100644
@@ -14,12 +14,13 @@
 /include/ "omap3.dtsi"
 

arch/arm/boot/dts/omap3-overo.dtsi +2 -0

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

Quoted 8 lines

arch/arm/boot/dts/omap3-overo.dtsi +0 -0

index 89808ce..800be29 100644
@@ -14,12 +14,13 @@
  /include/ "omap3.dtsi"
 

arch/arm/boot/dts/omap3-overo.dtsi line 22

Quoted 10 lines

arch/arm/boot/dts/omap3-overo.dtsi +3 -4

  / {
-	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.

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 6 lines

Quoted 3 lines

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)

:-)

Quoted 6 lines

Quoted 1 line

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?

Quoted 8 lines

Quoted 7 lines

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 5 lines · Florian Vaussard

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.

Quoted 4 lines

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.

Quoted 5 lines

Quoted 4 lines

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.

Quoted 5 lines

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?

Add the needed sections to enable audio support on Overo.

Signed-off-by Florian Vaussard <[email protected]>

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

arch/arm/boot/dts/omap3-overo.dtsi +14 -0

index 800be29..81341fa 100644
@@ -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 {
+			};
+		};
 	};
 };
 

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.

+ Peter who did the original PWM

Hi Florian,

Quoted 2 lines · Florian Vaussard

Hello Benoit,

Quoted 4 lines

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.

Hello Benoit,

Quoted 12 lines · Benoit Cousson

+ Peter who did the original PWM

Hi Florian,

Quoted 6 lines · 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.

Quoted 3 lines

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?

Salut Florian,

Quoted 15 lines · Florian Vaussard

Hello Benoit,

Quoted 12 lines · Benoit Cousson

+ Peter who did the original PWM

Hi Florian,

Quoted 6 lines · 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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Hi,

Quoted 7 lines · Benoit Cousson

Quoted 3 lines

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?

Quoted 2 lines

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

Hi,

Quoted 11 lines · Peter Ujfalusi

Hi,

Quoted 8 lines · Benoit Cousson

Quoted 4 lines

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?

Quoted 9 lines

Quoted 2 lines

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.