PWM Driver for OMAP (and backlight)
Happy Holidays everyone.
I have a DM3730 that am trying to setup timer 10 to drive a PWM that
controls the LCD backlight.
Using the linux-next git branch, I am trying to use the
pwm-omap-dmtimer function and I have configured the Device Tree as
follows:
bl: backlight {
compatible = "pwm-backlight";
pinctrl-names = "default";
pinctrl-0 = <&backlight_pins &backlight_pwm_pins>;
pwms = <&pwm10 0 500>;
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
default-brightness-level = <7>;
enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>; /* gpio_154 */
default-on;
};
pwm10: dmtimer-pwm@10 {
status = "okay";
compatible = "ti,omap-dmtimer-pwm";
ti,timers = <&timer10>;
#pwm-cells = <3>;
};
The Pinmuxing is configured as follows:
backlight_pwm_pins: pinmux_backlight_pwm_pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x20B8, PIN_OUTPUT | MUX_MODE2) /* gpmc_ncs5.gpio_56 */
>;
};
backlight_pins: pinmux_backlight_pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x2188, PIN_OUTPUT | MUX_MODE4) /* mcbsp4_dx.gpio_154 */
>;
};
I can certainly combine the backlight pinmuxing, but I can't figure
out the following errors
I get the following error:
[0.387145] omap-dmtimer-pwm dmtimer-pwm@10: Missing dmtimer platform data
[0.387176] omap-dmtimer-pwm: probe of dmtimer-pwm@10 failed with error -22
[0.389495] pwm-backlight backlight: unable to request PWM
[0.389617] pwm-backlight: probe of backlight failed with error -22
I assume that the backlight fails because the pwm fails, and I was
hoping some of you guys with more experience with this new pwm driver
might have some insight. I have the pwm driver built into the kernel.
I wasn't sure if I could directly reference timer10 from the backlight
since the examples showed it referencing a pwm.
adam
--
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] ARM: dts: n900: Include adp1653 device
This patch adds adp1653 device into n900 DT structure. DT support in
adp1653 driver is there since v4.2-rc1 version.
Signed-off-by: Pali Rohár
---
arch/arm/boot/dts/omap3-n900.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 5f5e0f3..ba93642 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -522,6 +522,21 @@
amstaos,cover-comp-gain = <16>;
};
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ led-max-microamp = <5>;
+ };
+ indicator {
+ led-max-microamp = <17500>;
+ };
+ };
+
lp5523: lp5523@32 {
compatible = "national,lp5523";
reg = <0x32>;
--
1.7.9.5
--
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] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver
Driver for omap3 with documentation is there since v4.4-rc1.
Signed-off-by: Pali Rohár
---
arch/arm/boot/dts/omap34xx.dtsi |5 +
arch/arm/boot/dts/omap36xx.dtsi |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 4f6b2d5..c3f488f 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -54,6 +54,11 @@
#size-cells = <0>;
};
};
+
+ bandgap {
+ reg = <0x48002524 0x4>;
+ compatible = "ti,omap34xx-bandgap";
+ };
};
};
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 86253de..00f98c1 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -86,6 +86,11 @@
#size-cells = <0>;
};
};
+
+ bandgap {
+ reg = <0x48002524 0x4>;
+ compatible = "ti,omap36xx-bandgap";
+ };
};
};
--
1.7.9.5
--
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] ARM: omapfb: Add early framebuffer memory allocator
On 26.12.2013 01:12, Ivaylo Dimitrov wrote: From: Ivaylo Dimitrov On memory limited devices, CMA fails easily when asked to allocate big chunks of memory like framebuffer memory needed for video playback. Add boot parameter "omapfb_memsize" which allocates memory to be used as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator when trying to allocate memory for the framebuffers Signed-off-by: Ivaylo Dimitrov --- arch/arm/mach-omap2/common.c |1 + arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/fb.c | 46 +- 3 files changed, 48 insertions(+), 1 deletions(-) ping -- 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 v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
Hi Tomi, On 13.01.2014 12:20, Tomi Valkeinen wrote: On 2014-01-11 11:39, Ivaylo Dimitrov wrote: The patch does not apply cleanly on top of rc7, however I applied it by hand. So far it seems it fixes the issue brought by c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if mutex_lock/mutex_unlock are complementary in every code path (at least not explicitly, I guess maemo is doing it for us anyway :) ). Ok, thanks. So, shall I send a patch incorporating your code changes, or you will do it? I can handle it. Tomi I still don't see those fixes in mainline, shall I send a patch? Ivo -- 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] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > * Arnd Bergmann [150515 14:26]: > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > If setting up the generic binding is expected to take a while, > > you can naturally pass it in pdata while waiting for the generic > > binding to get merged. > > Yes, good idea. So the n900 machine can use auxdata to pass this for > the time being, while the binding and generic implementation is > being worked out. > > Arnd Ok, so what is needed to finish this patch series? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
