Re: [PATCH v2 0/1] OMAP4: DSS: Add panel for Blaze Tablet boards
Hi, On 2013-02-08 17:43, Ruslan Bilovol wrote: > Hi, > > This patch adds support for TC358765 DSI-to-LVDS transmitter > from Toshiba, that is used in OMAP4 Blaze Tablet development > platform. It was originally developed a long time ago and > was used internally survived few kernel migrations. > Different people worked in this driver during last two > years changing its sources to what each new version of > kernel expects. > > Current version is ported from internal kernel v3.4 to 3.8.0-rc6 > Tested basic functioning under busybox. Thanks for updating the driver to a recent kernel. I didn't review the patch line by line, but with a brief look it looks fine. However, I'm not quite sure what to do with this patch. The problem is that the driver is a combined driver for the TC358765 chip and the panel on Blaze Tablet, and we are very much trying to fix that design issue so that the drivers for the chip and panel could be separate, as they should. So I fear that if I now accept the patch, it'll increase my burden of managing the display drivers during this design rework. Furthermore, to my knowledge the Blaze Tablet is quite a rare board, and it's not even supported in the mainline kernel, so this driver wouldn't be usable by itself. So if I'm right about the blaze tablet status, I'm inclined to say that I think this should be still kept out of tree. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v2] ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
Current CPU PM code code make use of common cpu_suspend() path for all the CPU power states which is not optimal. In fact cpu_suspend() path is needed only when we put CPU power domain to off state where the CPU context is lost. Update the code accordingly so that the expensive cpu_suspend() path can be avoided for the shallow CPU power states like CPU PD INA/CSWR. The patch has been tested on OMAP4430 and OMAP5430(with few out of tree patches) devices for suspend and CPUidle. Cc: Kevin Hilman Reported-by: Richard Woodruff Signed-off-by: Santosh Shilimkar --- Update changelog to include testing details as suggested by Kevin Hilman. arch/arm/mach-omap2/omap-mpuss-lowpower.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c index aac46bf..abdd0f6 100644 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c @@ -276,7 +276,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) /* * Call low level function with targeted low power state. */ - cpu_suspend(save_state, omap4_finish_suspend); + if (save_state) + cpu_suspend(save_state, omap4_finish_suspend); + else + omap4_finish_suspend(save_state); /* * Restore the CPUx power state to ON otherwise CPUx -- 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 v2 10/13] mailbox: create dbx500 mailbox driver
On Tue, Feb 12, 2013 at 08:01:05PM +, Loic PALLARDY wrote:
> Hi Mark,
>
> Thanks for your comments.
>
> On 02/12/2013 11:39 AM, Mark Rutland wrote:
> > Hello,
> >
> > I have a few comments on the devicetree binding and the way it's parsed.
> >
> >> +static const struct of_device_id dbx500_mailbox_match[] = {
> >> + { .compatible = "stericsson,db8500-mailbox",
> >> + .data = (void *)db8500_mboxes,
> >> + },
> >> + { .compatible = "stericsson,db9540-mailbox",
> >> + .data = (void *)dbx540_mboxes,
> >> + },
> >> + { /* sentinel */}
> >> +};
> >> +
> >
> > The binding for the compatible strings above and property parsing below
> > should
> > be documented.
> >
> Yes you're right. I will add a description in
> Documentation/devicetree/bindings/mailbox/...
Great!
[...]
> >> + mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> >> "prcm_reg");
> >
> > Does this work for dt? I wasn't aware we got anything more than anonymous
> > memory and interrupts.
> >
> Yes this is working with and without dt.
> dt declaration will be the following
> mailbox {
> compatible = "stericsson,db8500-mailbox";
> reg = <0x80157000 0x1000>, <0x801B8000 0x2000>;
> reg-names = "prcm-reg", "prcmu-tcdm";
> interrupts = <0 47 0x4>;
> interrupt-names = "irq";
> legacy-offset = <0xdd4>;
> };
Ah, I wasn't aware of reg-names. Thanks for the example.
Thanks,
Mark.
--
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 0/5] omap[4/5] I2c/Spi dts patches
Hi Tony, These patches were send as seperate ones before[1], but did not recieve any comments. Resending them all as a single patch series, as some affect the same files. [1]: https://patchwork.kernel.org/patch/2054891/ https://patchwork.kernel.org/patch/2054871/ https://patchwork.kernel.org/patch/2070991/ https://patchwork.kernel.org/patch/2089751/ http://www.spinics.net/lists/linux-omap/msg86137.html If you are Ok with the patch and there are no comments, Can it be picked? The following changes since commit 6edacf05c8362f4c368991b55d85e8122cfc9a24: Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2013-02-04 16:58:41 +1100) are available in the git repository at: g...@gitorious.org:linux-connectivity/linux-connectivity.git spi_i2c_dev Felipe Balbi (1): arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file Sourav Poddar (4): arm: dts: omap4-sdp: Add I2c pinctrl data arm: dts: omap5-evm: Add I2c pinctrl data arm: dts: omap4-panda: Add I2c pinctrl data arm: dts: omap5-evm: Add mcspi data arch/arm/boot/dts/omap4-panda.dts | 40 ++ arch/arm/boot/dts/omap4-sdp.dts | 40 ++ arch/arm/boot/dts/omap5-evm.dts | 108 + arch/arm/boot/dts/omap5.dtsi | 40 ++ 4 files changed, 228 insertions(+), 0 deletions(-) -- 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 5/5] arm: dts: omap5-evm: Add mcspi data
Add mcspi node and pinmux data for omap5 mcspi controller.
Tested on omap5430 evm with 3.8-rc6 custom kernel.
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5-evm.dts | 46 +++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index a4784be..64edd51 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -115,6 +115,33 @@
0x186 0x100 /* i2c5_sda INPUTENABLE | MODE0 */
>;
};
+
+ mcspi2_pins: pinmux_mcspi2_pins {
+ pinctrl-single,pins = <
+ 0xbc 0x100 /* MCSPI2_CLK INPUTENABLE | MODE0 */
+ 0xbe 0x100 /* MCSPI2_SIMO INPUTENABLE | MODE0 */
+ 0xc0 0x118 /* MCSPI2_SOMI PULLUP | INPUTENABLE |
MODE0*/
+ 0xc2 0x0/* MCSPI2_CS MODE0*/
+ >;
+ };
+
+ mcspi3_pins: pinmux_mcspi3_pins {
+ pinctrl-single,pins = <
+ 0x78 0x101 /* MCSPI2_SOMI INPUTENABLE | MODE1 */
+ 0x7a 0x101 /* MCSPI2_CS INPUTENABLE | MODE1 */
+ 0x7c 0x101 /* MCSPI2_SIMO INPUTENABLE | MODE1 */
+ 0x7e 0x101 /* MCSPI2_CLK INPUTENABLE | MODE1 */
+ >;
+ };
+
+ mcspi4_pins: pinmux_mcspi4_pins {
+ pinctrl-single,pins = <
+ 0x164 0x101 /* MCSPI2_CLK INPUTENABLE | MODE1 */
+ 0x168 0x101 /* MCSPI2_SIMO INPUTENABLE | MODE1 */
+ 0x16a 0x101 /* MCSPI2_SOMI INPUTENABLE | MODE1 */
+ 0x16c 0x101 /* MCSPI2_CS INPUTENABLE | MODE1 */
+ >;
+ };
};
&mmc1 {
@@ -213,3 +240,22 @@
cs1-used;
device-handle = <&samsung_K3PE0E000B>;
};
+
+&mcspi1 {
+
+};
+
+&mcspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi2_pins>;
+};
+
+&mcspi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi3_pins>;
+};
+
+&mcspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi4_pins>;
+};
--
1.7.1
--
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 2/5] arm: dts: omap5-evm: Add I2c pinctrl data
Booting 3.8-rc6 on omap 5430evm results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz
[1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap5 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap5430 evm with 3.8-rc6 kernel.
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5-evm.dts | 62 +++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 8722c15..a4784be 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -80,6 +80,41 @@
0x15a 0x100 /* abemcbsp2_clkx.abemcbsp2_clkx INPUT
| MODE0 */
>;
};
+
+i2c1_pins: pinmux_i2c1_pins {
+pinctrl-single,pins = <
+0x1b2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+0x1b4 0x118/* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+>;
+};
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x178 0x100/* i2c2_scl INPUTENABLE | MODE0 */
+ 0x17a 0x100/* i2c2_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0x13a 0x100/* i2c3_scl INPUTENABLE | MODE0 */
+ 0x13c 0x100 /* i2c3_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xb8 0x100/* i2c4_scl INPUTENABLE | MODE0 */
+ 0xba 0x100 /* i2c4_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins = <
+ 0x184 0x100/* i2c5_scl INPUTENABLE | MODE0 */
+ 0x186 0x100 /* i2c5_sda INPUTENABLE | MODE0 */
+ >;
+ };
};
&mmc1 {
@@ -106,7 +141,17 @@
status = "disabled";
};
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
+ clock-frequency = <40>;
+};
+
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <40>;
/* Pressure Sensor */
@@ -116,7 +161,17 @@
};
};
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
+ clock-frequency = <40>;
+};
+
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <40>;
/* Temperature Sensor */
@@ -126,6 +181,13 @@
};
};
+&i2c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5_pins>;
+
+ clock-frequency = <40>;
+};
+
&keypad {
keypad,num-rows = <8>;
keypad,num-columns = <8>;
--
1.7.1
--
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 3/5] arm: dts: omap4-panda: Add I2c pinctrl data
Booting 3.8-rc6 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
[0.473937] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[0.474670] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz
[0.474822] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[0.476379] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz
[0.477294] omap_i2c 4835.i2c: did not get pins for i2c error: -19
[0.477996] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz
[0.483398] Switching to clocksource 32k_counter
This happens because omap4 panda dts file is not adapted to use i2c through
pinctrl framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4460 panda with 3.8-rc6 kernel.
Signed-off-by: Sourav Poddar
Reported-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-panda.dts | 40 +
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..f951e6b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -110,9 +110,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe4 0x118/* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
clock-frequency = <40>;
twl: twl@48 {
@@ -139,10 +170,16 @@
/include/ "twl6030.dtsi"
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <40>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
clock-frequency = <10>;
/*
@@ -156,6 +193,9 @@
};
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <40>;
};
--
1.7.1
--
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 4/5] arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file
From: Felipe Balbi
Add all 4 mcspi instances to omap5.dtsi file.
Signed-off-by: Felipe Balbi
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5.dtsi | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..9e182a9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -241,6 +241,46 @@
ti,hwmods = "i2c5";
};
+ mcspi1: spi@48098000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x48098000 0x200>;
+ interrupts = <0 65 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi1";
+ ti,spi-num-cs = <4>;
+ };
+
+ mcspi2: spi@4809a000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x4809a000 0x200>;
+ interrupts = <0 66 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi2";
+ ti,spi-num-cs = <2>;
+ };
+
+ mcspi3: spi@480b8000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x480b8000 0x200>;
+ interrupts = <0 91 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi3";
+ ti,spi-num-cs = <2>;
+ };
+
+ mcspi4: spi@480ba000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x480ba000 0x200>;
+ interrupts = <0 48 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi4";
+ ti,spi-num-cs = <1>;
+ };
+
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
--
1.7.1
--
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/5] arm: dts: omap4-sdp: Add I2c pinctrl data
Booting 3.8-rc6 on omap 4430sdp results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz
[1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap4 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4430 sdp with 3.8-rc6 kernel.
Signed-off-by: Sourav Poddar
Reported-by: Santosh Shilimkar
---
arch/arm/boot/dts/omap4-sdp.dts | 40 +++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..40a04c9 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -212,9 +212,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe4 0x118 /* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
MODE0 */
+0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
clock-frequency = <40>;
twl: twl@48 {
@@ -253,10 +284,16 @@
/include/ "twl6030.dtsi"
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <40>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
clock-frequency = <40>;
/*
@@ -279,6 +316,9 @@
};
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <40>;
/*
--
1.7.1
--
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: [RFC v2 07/18] ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
Hi Kevin, On Tue, Feb 12, 2013 at 05:03:23, Kevin Hilman wrote: > Vaibhav Bedia writes: > > > TPTC0 needs to be idled and put to standby under SW control. > > Please elaborate about why (e.g. HW support not available, HW support > broken/buggy, etc.) since these blocks are not well documented in the > docs that I have (spruh73f.) > This change was picked up for v3.9. I'll submit a follow-up patch adding in a comment in the hwmod file for this. Regards, Vaibhav -- 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
[RFC 0/1] ARM: omap2: gpmc: Move binding documentation
Following current trend of placing memory controllers drivers under
drivers/memory, this patch anticipates this by moving the binding
documentation to Documentation/devicetree/bindings/memory-controller.
Some other SoCs will have similar memory controllers placed under
drivers/memory and it seems a bit strange to put GPMC under drivers/bus.
Ezequiel Garcia (1):
ARM: omap2: gpmc: Move binding documentation to memory-controller
.../ti-gpmc.txt => memory-controllers/ti/gpmc.txt} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt =>
memory-controllers/ti/gpmc.txt} (100%)
--
1.7.8.6
--
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
[RFC 1/1] ARM: omap2: gpmc: Move binding documentation to memory-controller
GPMC stands for General Purpose Memory Controller, and it's primarily
used to handle memories such as NOR, NAND, SRAM.
Note that this controller is also used to handle network controllers
such as smsc911x.
This patch moves the documentation binding to memory-controllers,
where it belongs.
Signed-off-by: Ezequiel Garcia
---
.../ti-gpmc.txt => memory-controllers/ti/gpmc.txt} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt =>
memory-controllers/ti/gpmc.txt} (100%)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/bus/ti-gpmc.txt
rename to Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
--
1.7.8.6
--
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 3/4] mtd: devices: elm: Low power transition support
On Sat, Feb 09, 2013 at 15:52:44, Russell King - ARM Linux wrote:
> On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
> > +static int elm_suspend(struct device *dev)
> > +{
> > + struct elm_info *info = dev_get_drvdata(dev);
> > + wait_queue_head_t wq;
> > + DECLARE_WAITQUEUE(wait, current);
> > +
> > + init_waitqueue_head(&wq);
> > + while (1) {
> > + /* Make sure that ELM not running */
> > + if (info->idle) {
> > + add_wait_queue(&wq, &wait);
> > + schedule();
> > + remove_wait_queue(&wq, &wait);
> > + } else {
> > + break;
> > + }
> > + }
>
> The above code looks really wrong - it will just spin endlessly with the
> waitqueues doing nothing useful. What are you trying to do here?
The intention of waitqeue is to make the suspend process really wait till
the ELM module finishes current activity. Although this type of protection
already achieved in mtd layer using nand_suspend(), this one is particularly
required for ELM module to really make sure that *any pending* corrections to
finish really before gone to suspend.
If suspend activity initiated and NAND driver requested service of ELM
module for error correction, then suspend activity has to wait till
(info->idle == false), so that ELM module finishes activity.
I can think of adding different states to ELM module and take action.
I will add following states.
RUNNING
SUSPEND
Thanks
Avinash
>
--
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 3/4] mtd: devices: elm: Low power transition support
On Wed, Feb 13, 2013 at 11:42:01AM +, Philip, Avinash wrote:
> On Sat, Feb 09, 2013 at 15:52:44, Russell King - ARM Linux wrote:
> > On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
> > > +static int elm_suspend(struct device *dev)
> > > +{
> > > + struct elm_info *info = dev_get_drvdata(dev);
> > > + wait_queue_head_t wq;
> > > + DECLARE_WAITQUEUE(wait, current);
> > > +
> > > + init_waitqueue_head(&wq);
> > > + while (1) {
> > > + /* Make sure that ELM not running */
> > > + if (info->idle) {
> > > + add_wait_queue(&wq, &wait);
> > > + schedule();
> > > + remove_wait_queue(&wq, &wait);
> > > + } else {
> > > + break;
> > > + }
> > > + }
> >
> > The above code looks really wrong - it will just spin endlessly with the
> > waitqueues doing nothing useful. What are you trying to do here?
>
> The intention of waitqeue is to make the suspend process really wait till
> the ELM module finishes current activity. Although this type of protection
> already achieved in mtd layer using nand_suspend(), this one is particularly
> required for ELM module to really make sure that *any pending* corrections to
> finish really before gone to suspend.
I don't think you understand what's going on with the above, and why the
above is completely ineffective.
1. Your wait queue head is declared on stack, and there's no references
to it outside of this function. So _nothing_ can activate the wait
queue.
2. You're not changing the current thread's status away from TASK_RUNNING,
so schedule() will either return immediately or it will schedule another
task if it's time for this one to be preempted.
In other words, the above can be rewritten as:
while (info->idle)
schedule();
and it will still have the same effect.
Now, if you want to be kinder to the system, then you should use a
wait queue properly. Put the waitqueue head in struct elm_info. Use
wait_event() here. And call wake_up() where you set info->idle to
false.
--
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] ASoC: omap-dmic: Clean up with devm_request_and_ioremap
On 02/13/2013 08:22 AM, Sebastien Guiriec wrote:
> Clean up dmic code with devm_request_and_ioremap function.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Sebastien Guiriec
> ---
> sound/soc/omap/omap-dmic.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
> index ba49ccd..77e9e7e 100644
> --- a/sound/soc/omap/omap-dmic.c
> +++ b/sound/soc/omap/omap-dmic.c
> @@ -493,16 +493,9 @@ static int asoc_dmic_probe(struct platform_device *pdev)
> goto err_put_clk;
> }
>
> - if (!devm_request_mem_region(&pdev->dev, res->start,
> - resource_size(res), pdev->name)) {
> - dev_err(dmic->dev, "memory region already claimed\n");
> - ret = -ENODEV;
> - goto err_put_clk;
> - }
> -
> - dmic->io_base = devm_ioremap(&pdev->dev, res->start,
> - resource_size(res));
> + dmic->io_base = devm_request_and_ioremap(&pdev->dev, res);
> if (!dmic->io_base) {
> + dev_err(&pdev->dev, "cannot remap\n");
> ret = -ENOMEM;
> goto err_put_clk;
> }
>
--
Péter
--
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] ASoC: omap-mcpdm: Clean up with devm_* function
On 02/13/2013 08:21 AM, Sebastien Guiriec wrote:
> Clean up McPDM driver with devm_ function.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Sebastien Guiriec
> ---
> sound/soc/omap/omap-mcpdm.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
> index 5ca11bd..079f277 100644
> --- a/sound/soc/omap/omap-mcpdm.c
> +++ b/sound/soc/omap/omap-mcpdm.c
> @@ -369,7 +369,7 @@ static int omap_mcpdm_probe(struct snd_soc_dai *dai)
> pm_runtime_get_sync(mcpdm->dev);
> omap_mcpdm_write(mcpdm, MCPDM_REG_CTRL, 0x00);
>
> - ret = request_irq(mcpdm->irq, omap_mcpdm_irq_handler,
> + ret = devm_request_irq(mcpdm->dev, mcpdm->irq, omap_mcpdm_irq_handler,
> 0, "McPDM", (void *)mcpdm);
>
> pm_runtime_put_sync(mcpdm->dev);
> @@ -389,7 +389,6 @@ static int omap_mcpdm_remove(struct snd_soc_dai *dai)
> {
> struct omap_mcpdm *mcpdm = snd_soc_dai_get_drvdata(dai);
>
> - free_irq(mcpdm->irq, (void *)mcpdm);
> pm_runtime_disable(mcpdm->dev);
>
> return 0;
> @@ -465,14 +464,11 @@ static int asoc_mcpdm_probe(struct platform_device
> *pdev)
> if (res == NULL)
> return -ENOMEM;
>
> - if (!devm_request_mem_region(&pdev->dev, res->start,
> - resource_size(res), "McPDM"))
> - return -EBUSY;
> -
> - mcpdm->io_base = devm_ioremap(&pdev->dev, res->start,
> - resource_size(res));
> - if (!mcpdm->io_base)
> + mcpdm->io_base = devm_request_and_ioremap(&pdev->dev, res);
> + if (!mcpdm->io_base) {
> + dev_err(&pdev->dev, "cannot remap\n");
> return -ENOMEM;
> + }
>
> mcpdm->irq = platform_get_irq(pdev, 0);
> if (mcpdm->irq < 0)
>
--
Péter
--
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] ASoC: omap-mcpdm: Clean up with devm_* function
On Wed, Feb 13, 2013 at 08:21:54AM +0100, Sebastien Guiriec wrote: > Clean up McPDM driver with devm_ function. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] ASoC: omap-dmic: Clean up with devm_request_and_ioremap
On Wed, Feb 13, 2013 at 08:22:07AM +0100, Sebastien Guiriec wrote: > Clean up dmic code with devm_request_and_ioremap function. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v2 00/13] drivers: mailbox: framework creation
On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna wrote: > I have hosted the series at [3]. > [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox Suman, I suggest you ask Stepgen Rothwell to include this branch into the linux-next tree, so we can get some rotation of this stuff in preparation for the v3.10 merge window. (It's not going in now anyway.) If it proves to survive some smoke testing there, I suggest we proceed to pull this into the ARM SoC tree early in the v3.10 kernel cycle, since all the dependencies will be in ARM SoC anyway. 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 v2 00/13] drivers: mailbox: framework creation
On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote: > On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna wrote: > > > I have hosted the series at [3]. > > [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox > > Suman, I suggest you ask Stepgen Rothwell to include this > branch into the linux-next tree, so we can get some > rotation of this stuff in preparation for the v3.10 merge > window. (It's not going in now anyway.) Best wait until after v3.9-rc1 - remember that linux-next is supposed to be a staging tree for the _next_ merge window only. -- 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: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Kevin,
On Tue, Feb 12, 2013 at 06:57:50, Kevin Hilman wrote:
[...]
> > +
> > +void (*am33xx_do_wfi_sram)(void);
>
> static?
Will fix.
[...]
> > +
> > + /*
> > +* By default the following IPs do not have MSTANDBY asserted
> > +* which is necessary for PER domain transition. If the drivers
> > +* are not compiled into the kernel HWMOD code will not change the
> > +* state of the IPs if the IP was not never enabled. To ensure
> > +* that there no issues with or without the drivers being compiled
> > +* in the kernel, we forcefully put these IPs to idle.
> > +*/
> > + omap_hwmod_enable(usb_oh);
> > + omap_hwmod_enable(tptc0_oh);
> > + omap_hwmod_enable(tptc1_oh);
> > + omap_hwmod_enable(tptc2_oh);
> > + omap_hwmod_enable(cpsw_oh);
> > +
> > + omap_hwmod_idle(usb_oh);
> > + omap_hwmod_idle(tptc0_oh);
> > + omap_hwmod_idle(tptc1_oh);
> > + omap_hwmod_idle(tptc2_oh);
> > + omap_hwmod_idle(cpsw_oh);
>
> I think I asked this in my review of v1, but why does this need to
> happen on every suspend attempt?
>
> This should happen once on init, which will handle the case where there
> are no drivers, and if there are drivers, then the drivers need to
> handle this properly.
>
> I don't like this happening here on every suspend attempt, because it
> will surely hide bugs where drivers are not properly managing their own PM.
>
By default these IPs don't have MSTANDBY asserted. When a low power transition
happens, the peripheral power domain loses context and hence the forced
MSTANDBY configuration in the IP is lost. To work around this problem we need
to assert MSTANDBY in every suspend-resume iteration.
I agree that this might hide PM bugs in the driver but to solve this problem we
need some mechanism for the PM code to know whether or not a driver is bound
to the corresponding platform devices. Any suggestions on this?
> > + /* Try to put GFX to sleep */
> > + pwrdm_set_next_fpwrst(gfx_pwrdm, PWRDM_FUNC_PWRST_OFF);
> > +
> > + ret = cpu_suspend(0, am33xx_do_sram_idle);
> > + status = pwrdm_read_fpwrst(gfx_pwrdm);
> > + if (status != PWRDM_FUNC_PWRST_OFF)
> > + pr_err("GFX domain did not transition\n");
> > + else
> > + pr_info("GFX domain entered low power state\n");
>
> Do you really want this printed every time?
>
Hmm... it could perhaps be clubbed with the overall status that's
printed. I kept it here since the GFX power domain is completely
under MPU control and hence this information would be useful in
finding out if there's a problem with the GFX suspend-resume.
> > + /*
> > +* GFX_L4LS clock domain needs to be woken up to
> > +* ensure thet L4LS clock domain does not get stuck in transition
> > +* If that happens L3 module does not get disabled, thereby leading
> > +* to PER power domain transition failing
> > +*
> > +* The clock framework should take care of ensuring
> > +* that the clock domain is in the right state when
> > +* GFX driver is active.
>
> Are you suggesting that the clock framework is not doing this already?
>
No. This clkdm_*() calls are here to work-around an issue that I observed
when implementing suspend-resume. The force wakeup and sleep of the gfx_l4ls
clock domain across every suspend-resume is something I don't think can
be pushed to the clock framework.
> > +*/
> > + clkdm_wakeup(gfx_l4ls_clkdm);
> > + clkdm_sleep(gfx_l4ls_clkdm);
> > +
> > + if (ret) {
> > + pr_err("Kernel suspend failure\n");
> > + } else {
> > + status = omap_ctrl_readl(AM33XX_CONTROL_IPC_MSG_REG1);
>
> We're trying to git rid of direct control module register access, and
> consolidate them into control.c (for an eventual move to a driver.) I
> see you've mostly done that in other parts of the series, but here's one
> that needs to move.
Yes, I somehow missed this one. Will take care of it in the next version.
>
> > + status &= IPC_RESP_MASK;
> > + status >>= __ffs(IPC_RESP_MASK);
> > +
> > + switch (status) {
> > + case 0:
> > + pr_info("Successfully put all powerdomains to target
> > state\n");
> > + /*
> > +* XXX: Leads to loss of logic state in PER power domain
> > +* Use SOC specific ops for this?
> > +*/
>
> huh?
>
Ah... this is more of a TODO. There's no previous state entered information
in the PRCM registers. So to ensure that the drivers get the right information
when they check with the PM layer about the loss of context and hence the need
to restore the registers, I need to update the logic and membank state counters
for the PER power domain manually. I was thinking of leveraging the SoC specific
power domain ops for doing this.
[...]
> > +
> > + /* Give some time to M3 to respond. 500msec is a random value here */
>
> random? really?
Sort of. I don't have any numbers from the h/w guys
Re: [PATCH v2 09/11] mfd: twl-core: Collect global variables behind one private structure (global)
Hi Jon, On 02/12/2013 05:15 PM, Jon Hunter wrote: > > On 02/12/2013 01:26 AM, Peter Ujfalusi wrote: >> On 02/11/2013 09:22 PM, Jon Hunter wrote: >>> Good point. I just noticed that none of my omap2+ board were booting and >>> on omap3/4 I was the panic in the twl code. I can't say that I checked >>> the panic on omap2, so may be that was another problem? >> >> Do you have insights on the code path leading to a crash on OMAP3/4? I have >> been running this code on several boards (BeagleBoard, Zoom2, PandaBoard, >> Blaze) and have not seen a crash. > > Here is the panic log ... Thanks. > > [2.286132] Unable to handle kernel NULL pointer dereference at virtual > address > [2.294738] pgd = c0004000 > [2.297576] [] *pgd= > [2.301361] Internal error: Oops: 5 [#1] SMP ARM > [2.306243] Modules linked in: > [2.309448] CPU: 0Not tainted (3.8.0-rc6-next-20130207-00016-g735c237 > #35) > [2.317169] PC is at twl_i2c_read+0x3c/0xec > [2.321563] LR is at twl_i2c_read+0x1c/0xec > [2.325988] pc : []lr : []psr: 8153 > [2.325988] sp : c702fed0 ip : fp : > [2.338043] r10: c702e000 r9 : c06e84e8 r8 : c06e51c8 > [2.343536] r7 : 0001 r6 : 0006 r5 : c702fef6 r4 : 0004 > [2.350402] r3 : c129508c r2 : 0006 r1 : c702fef6 r0 : 000e > [2.357269] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment > kernel > [2.365051] Control: 10c5387d Table: 80004019 DAC: 0017 > [2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240) > [2.377410] Stack: (0xc702fed0 to 0xc703) > [2.382019] fec0: c0d42180 c0d429d0 > c70a7640 c07354c4 > [2.390624] fee0: 0001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac > c07354c4 > [2.399230] ff00: 0007 c06f2d64 0017 c06fb308 c06f07a4 > c0cb8580 c06edee0 > [2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 009e c00611b4 > 0001 > [2.416442] ff40: c061994c c06b7548 0007 0007 c07354c4 > 0007 c0719798 > [2.425048] ff60: c0d42180 c06e51c8 c07197a0 009e c06e590c > 0007 0007 > [2.433654] ff80: c06e51c8 c04d26ec > > [2.442260] ffa0: c04d26f4 c00137b0 > > [2.450866] ffc0: > > [2.459472] ffe0: 0013 > 80fb6c10 71bbcd20 > [2.468078] [] (twl_i2c_read+0x3c/0xec) from [] > (omap3_twl_set_sr_bit+0x3c/0xb4) > [2.477722] [] (omap3_twl_set_sr_bit+0x3c/0xb4) from > [] (omap3_twl_init+0x2c/0x70) > [2.487518] [] (omap3_twl_init+0x2c/0x70) from [] > (omap_pmic_late_init+0x18/0x24) > [2.497222] [] (omap_pmic_late_init+0x18/0x24) from [] > (omap2_common_pm_late_init+0x18/0xd0) > [2.507934] [] (omap2_common_pm_late_init+0x18/0xd0) from > [] (omap3_init_late+0xc/0x18) > [2.518188] [] (omap3_init_late+0xc/0x18) from [] > (init_machine_late+0x1c/0x28) > [2.527740] [] (init_machine_late+0x1c/0x28) from [] > (do_one_initcall+0x100/0x16c) > [2.537536] [] (do_one_initcall+0x100/0x16c) from [] > (kernel_init_freeable+0xfc/0x1c8) > [2.547698] [] (kernel_init_freeable+0xfc/0x1c8) from > [] (kernel_init+0x8/0xe4) > [2.557250] [] (kernel_init+0x8/0xe4) from [] > (ret_from_fork+0x14/0x24) This is exactly the sort of thing which should not ever existed in the first place... The code in omap_twl.c, especially the omap3_twl_set_sr_bit() function is executed in .init_late of the board. If the twl stack is not up by then we are going to have issues. Right now I don't see how to solve this (the call chain is related to smartreflex) but IMHO we should not have these 'random' twl_write calls spread across the kernel without integrating them to the twl stack in a proper manner. What I mean is that we should only have twl_* calls from drivers, which has been created by the twl-core MFD core. -- Péter -- 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 00/11] OMAPDSS: Misc cleanups
These patches perform cleanups which will help the omapdss driver to migrate to DT more easily: - omapdss panel drivers call platform specific backlight functions defined in board files. These callbacks are removed. Setting of max backlight level in the board file is also removed. - other misc changes which thin down the omap_dss_device struct by removing some unnecessary fields. - usage of devm_kzalloc in panel drivers. Reference branch: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.9/misc_cleanups Archit Taneja (7): OMAPDSS: ZOOM/NEC-nl8048hl11: remove platform backlight support OMAPDSS: Generic DPI Panel: use devm_kzalloc for allocating driver data OMAPDSS: lb035q02: use devm_kzalloc for allocating driver data OMAPDSS: picodlp: use devm_kzalloc for allocating driver data OMAPDSS: remove unnecessary DSI external TE pin platform info from omap_dss_device OMAPDSS: panel acx565akm: remove omap_dss_device maximum backlight level usage OMAPDSS: Remove max_backlight_level form omap_dss_device Tomi Valkeinen (4): OMAPDSS: acx565akm: remove platform backlight calls OMAPDSS: ls037v7dw01: remove platform backlight calls OMAPDSS: n8x0: remove platform backlight calls OMAPDSS: remove set_backlight/get_backlight function ptrs arch/arm/mach-omap2/board-zoom-display.c |2 - drivers/video/omap2/displays/panel-acx565akm.c | 11 +-- drivers/video/omap2/displays/panel-generic-dpi.c |6 +- .../omap2/displays/panel-lgphilips-lb035q02.c | 16 ++--- drivers/video/omap2/displays/panel-n8x0.c | 74 .../omap2/displays/panel-nec-nl8048hl11-01b.c | 74 drivers/video/omap2/displays/panel-picodlp.c | 16 ++--- .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 62 include/video/omap-panel-n8x0.h|2 - include/video/omapdss.h|7 -- 10 files changed, 14 insertions(+), 256 deletions(-) -- 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 01/11] OMAPDSS: acx565akm: remove platform backlight calls
From: Tomi Valkeinen acx565akm has support to call set_backlight/get_backlight in platform code. They are not used by any board, and thus can be removed from the driver. Signed-off-by: Tomi Valkeinen Signed-off-by: Archit Taneja --- drivers/video/omap2/displays/panel-acx565akm.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c index 72699f8..a980a11 100644 --- a/drivers/video/omap2/displays/panel-acx565akm.c +++ b/drivers/video/omap2/displays/panel-acx565akm.c @@ -336,8 +336,6 @@ static int acx565akm_bl_update_status(struct backlight_device *dev) r = 0; if (md->has_bc) acx565akm_set_brightness(md, level); - else if (md->dssdev->set_backlight) - r = md->dssdev->set_backlight(md->dssdev, level); else r = -ENODEV; @@ -352,7 +350,7 @@ static int acx565akm_bl_get_intensity(struct backlight_device *dev) dev_dbg(&dev->dev, "%s\n", __func__); - if (!md->has_bc && md->dssdev->set_backlight == NULL) + if (!md->has_bc) return -ENODEV; if (dev->props.fb_blank == FB_BLANK_UNBLANK && @@ -564,8 +562,6 @@ static int acx_panel_probe(struct omap_dss_device *dssdev) if (md->has_bc) brightness = acx565akm_get_actual_brightness(md); - else if (dssdev->get_backlight) - brightness = dssdev->get_backlight(dssdev); else brightness = 0; -- 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 02/11] OMAPDSS: ls037v7dw01: remove platform backlight calls
From: Tomi Valkeinen
Sharp ls037v7dw01 driver contains support to call platform backlight
functions. These are not used by any board, and can be removed.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Archit Taneja
---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 62
1 file changed, 62 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index cada8c6..eb6bd81 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -28,7 +27,6 @@
#include
struct sharp_data {
- struct backlight_device *bl;
};
static struct omap_video_timings sharp_ls_timings = {
@@ -52,45 +50,10 @@ static struct omap_video_timings sharp_ls_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
-static int sharp_ls_bl_update_status(struct backlight_device *bl)
-{
- struct omap_dss_device *dssdev = dev_get_drvdata(&bl->dev);
- int level;
-
- if (!dssdev->set_backlight)
- return -EINVAL;
-
- if (bl->props.fb_blank == FB_BLANK_UNBLANK &&
- bl->props.power == FB_BLANK_UNBLANK)
- level = bl->props.brightness;
- else
- level = 0;
-
- return dssdev->set_backlight(dssdev, level);
-}
-
-static int sharp_ls_bl_get_brightness(struct backlight_device *bl)
-{
- if (bl->props.fb_blank == FB_BLANK_UNBLANK &&
- bl->props.power == FB_BLANK_UNBLANK)
- return bl->props.brightness;
-
- return 0;
-}
-
-static const struct backlight_ops sharp_ls_bl_ops = {
- .get_brightness = sharp_ls_bl_get_brightness,
- .update_status = sharp_ls_bl_update_status,
-};
-
-
static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
{
- struct backlight_properties props;
- struct backlight_device *bl;
struct sharp_data *sd;
- int r;
dssdev->panel.timings = sharp_ls_timings;
@@ -100,37 +63,12 @@ static int sharp_ls_panel_probe(struct omap_dss_device
*dssdev)
dev_set_drvdata(&dssdev->dev, sd);
- memset(&props, 0, sizeof(struct backlight_properties));
- props.max_brightness = dssdev->max_backlight_level;
- props.type = BACKLIGHT_RAW;
-
- bl = backlight_device_register("sharp-ls", &dssdev->dev, dssdev,
- &sharp_ls_bl_ops, &props);
- if (IS_ERR(bl)) {
- r = PTR_ERR(bl);
- kfree(sd);
- return r;
- }
- sd->bl = bl;
-
- bl->props.fb_blank = FB_BLANK_UNBLANK;
- bl->props.power = FB_BLANK_UNBLANK;
- bl->props.brightness = dssdev->max_backlight_level;
- r = sharp_ls_bl_update_status(bl);
- if (r < 0)
- dev_err(&dssdev->dev, "failed to set lcd brightness\n");
-
return 0;
}
static void __exit sharp_ls_panel_remove(struct omap_dss_device *dssdev)
{
struct sharp_data *sd = dev_get_drvdata(&dssdev->dev);
- struct backlight_device *bl = sd->bl;
-
- bl->props.power = FB_BLANK_POWERDOWN;
- sharp_ls_bl_update_status(bl);
- backlight_device_unregister(bl);
kfree(sd);
}
--
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 03/11] OMAPDSS: ZOOM/NEC-nl8048hl11: remove platform backlight support
omap_dss_device provides a callback function to set backlight. Panel backlight
on Zoom board is implemented by the function zoom_set_bl_intensity() in the
board file. This needs to be removed. The PWM backlight should be implemented
with the pwm_bl driver.
For now, function zoom_set_bl_intensity() is left as is, but omap_dss_device's
set_backlight func pointer and max_brightness_level are removed. NEC-nl8048hl11
panel driver contains support to call platform backlight functions. These are
not used any more in zoom and are now removed.
Signed-off-by: Archit Taneja
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-zoom-display.c |2 -
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 74
2 files changed, 76 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
index 1c7c834..4717ed5 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -109,8 +109,6 @@ static struct omap_dss_device zoom_lcd_device = {
.phy.dpi.data_lines = 24,
.platform_enable= zoom_panel_enable_lcd,
.platform_disable = zoom_panel_disable_lcd,
- .max_backlight_level= 100,
- .set_backlight = zoom_set_bl_intensity,
};
static struct omap_dss_device *zoom_dss_devices[] = {
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index c4e9c2b..c197927 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
@@ -33,7 +32,6 @@
#define LCD_PIXEL_CLOCK23800
struct nec_8048_data {
- struct backlight_device *bl;
};
static const struct {
@@ -84,43 +82,9 @@ static struct omap_video_timings nec_8048_panel_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
};
-static int nec_8048_bl_update_status(struct backlight_device *bl)
-{
- struct omap_dss_device *dssdev = dev_get_drvdata(&bl->dev);
- int level;
-
- if (!dssdev->set_backlight)
- return -EINVAL;
-
- if (bl->props.fb_blank == FB_BLANK_UNBLANK &&
- bl->props.power == FB_BLANK_UNBLANK)
- level = bl->props.brightness;
- else
- level = 0;
-
- return dssdev->set_backlight(dssdev, level);
-}
-
-static int nec_8048_bl_get_brightness(struct backlight_device *bl)
-{
- if (bl->props.fb_blank == FB_BLANK_UNBLANK &&
- bl->props.power == FB_BLANK_UNBLANK)
- return bl->props.brightness;
-
- return 0;
-}
-
-static const struct backlight_ops nec_8048_bl_ops = {
- .get_brightness = nec_8048_bl_get_brightness,
- .update_status = nec_8048_bl_update_status,
-};
-
static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
{
- struct backlight_device *bl;
struct nec_8048_data *necd;
- struct backlight_properties props;
- int r;
dssdev->panel.timings = nec_8048_panel_timings;
@@ -130,38 +94,12 @@ static int nec_8048_panel_probe(struct omap_dss_device
*dssdev)
dev_set_drvdata(&dssdev->dev, necd);
- memset(&props, 0, sizeof(struct backlight_properties));
- props.max_brightness = 255;
-
- bl = backlight_device_register("nec-8048", &dssdev->dev, dssdev,
- &nec_8048_bl_ops, &props);
- if (IS_ERR(bl)) {
- r = PTR_ERR(bl);
- kfree(necd);
- return r;
- }
- necd->bl = bl;
-
- bl->props.fb_blank = FB_BLANK_UNBLANK;
- bl->props.power = FB_BLANK_UNBLANK;
- bl->props.max_brightness = dssdev->max_backlight_level;
- bl->props.brightness = dssdev->max_backlight_level;
-
- r = nec_8048_bl_update_status(bl);
- if (r < 0)
- dev_err(&dssdev->dev, "failed to set lcd brightness\n");
-
return 0;
}
static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
{
struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
- struct backlight_device *bl = necd->bl;
-
- bl->props.power = FB_BLANK_POWERDOWN;
- nec_8048_bl_update_status(bl);
- backlight_device_unregister(bl);
kfree(necd);
}
@@ -169,8 +107,6 @@ static void nec_8048_panel_remove(struct omap_dss_device
*dssdev)
static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
{
int r;
- struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
- struct backlight_device *bl = necd->bl;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
return 0;
@@ -188,10 +124,6 @@ static int nec_8048_panel_power_on(struct omap_dss_device
*dssdev)
goto err1;
}
- r = nec_8048_bl_update_status(bl);
- i
[PATCH 04/11] OMAPDSS: n8x0: remove platform backlight calls
From: Tomi Valkeinen
The n8x0 panel contains support to call platform backlight functions.
These are not used by any board, and can be removed.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-n8x0.c | 74 -
include/video/omap-panel-n8x0.h |2 -
2 files changed, 76 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c
b/drivers/video/omap2/displays/panel-n8x0.c
index dd12947..b750480 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -5,7 +5,6 @@
#include
#include
#include
-#include
#include
#include
@@ -69,7 +68,6 @@ static struct panel_drv_data {
struct omap_dss_device *dssdev;
struct spi_device *spidev;
- struct backlight_device *bldev;
int blizzard_ver;
} s_drv_data;
@@ -424,55 +422,10 @@ static const struct rfbi_timings n8x0_panel_timings = {
.cs_pulse_width = 0,
};
-static int n8x0_bl_update_status(struct backlight_device *dev)
-{
- struct omap_dss_device *dssdev = dev_get_drvdata(&dev->dev);
- struct panel_n8x0_data *bdata = get_board_data(dssdev);
- struct panel_drv_data *ddata = get_drv_data(dssdev);
- int r;
- int level;
-
- mutex_lock(&ddata->lock);
-
- if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
- dev->props.power == FB_BLANK_UNBLANK)
- level = dev->props.brightness;
- else
- level = 0;
-
- dev_dbg(&dssdev->dev, "update brightness to %d\n", level);
-
- if (!bdata->set_backlight)
- r = -EINVAL;
- else
- r = bdata->set_backlight(dssdev, level);
-
- mutex_unlock(&ddata->lock);
-
- return r;
-}
-
-static int n8x0_bl_get_intensity(struct backlight_device *dev)
-{
- if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
- dev->props.power == FB_BLANK_UNBLANK)
- return dev->props.brightness;
-
- return 0;
-}
-
-static const struct backlight_ops n8x0_bl_ops = {
- .get_brightness = n8x0_bl_get_intensity,
- .update_status = n8x0_bl_update_status,
-};
-
static int n8x0_panel_probe(struct omap_dss_device *dssdev)
{
struct panel_n8x0_data *bdata = get_board_data(dssdev);
struct panel_drv_data *ddata;
- struct backlight_device *bldev;
- struct backlight_properties props;
- int r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -491,40 +444,13 @@ static int n8x0_panel_probe(struct omap_dss_device
*dssdev)
dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
- memset(&props, 0, sizeof(props));
- props.max_brightness = 127;
- props.type = BACKLIGHT_PLATFORM;
- bldev = backlight_device_register(dev_name(&dssdev->dev), &dssdev->dev,
- dssdev, &n8x0_bl_ops, &props);
- if (IS_ERR(bldev)) {
- r = PTR_ERR(bldev);
- dev_err(&dssdev->dev, "register backlight failed\n");
- return r;
- }
-
- ddata->bldev = bldev;
-
- bldev->props.fb_blank = FB_BLANK_UNBLANK;
- bldev->props.power = FB_BLANK_UNBLANK;
- bldev->props.brightness = 127;
-
- n8x0_bl_update_status(bldev);
-
return 0;
}
static void n8x0_panel_remove(struct omap_dss_device *dssdev)
{
- struct panel_drv_data *ddata = get_drv_data(dssdev);
- struct backlight_device *bldev;
-
dev_dbg(&dssdev->dev, "remove\n");
- bldev = ddata->bldev;
- bldev->props.power = FB_BLANK_POWERDOWN;
- n8x0_bl_update_status(bldev);
- backlight_device_unregister(bldev);
-
dev_set_drvdata(&dssdev->dev, NULL);
}
diff --git a/include/video/omap-panel-n8x0.h b/include/video/omap-panel-n8x0.h
index 50a1302..9cc69c8 100644
--- a/include/video/omap-panel-n8x0.h
+++ b/include/video/omap-panel-n8x0.h
@@ -8,8 +8,6 @@ struct panel_n8x0_data {
void (*platform_disable)(struct omap_dss_device *dssdev);
int panel_reset;
int ctrl_pwrdown;
-
- int (*set_backlight)(struct omap_dss_device *dssdev, int level);
};
#endif
--
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 05/11] OMAPDSS: remove set_backlight/get_backlight function ptrs
From: Tomi Valkeinen
Now that no board nor panel is using set_backlight and get_backlight
functions, we can remove them from omapdss.h.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Archit Taneja
---
include/video/omapdss.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index caefa09..d5dcd50 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -659,8 +659,6 @@ struct omap_dss_device {
/* platform specific */
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
- int (*set_backlight)(struct omap_dss_device *dssdev, int level);
- int (*get_backlight)(struct omap_dss_device *dssdev);
};
struct omap_dss_hdmi_data
--
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 06/11] OMAPDSS: Generic DPI Panel: use devm_kzalloc for allocating driver data
Use devm_kzalloc instead of kzalloc to allocate driver data for the generic dpi
panel driver. This simplifies the driver's probe and remove functions.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-generic-dpi.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 54ca8ae..6cb2fe0 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -632,7 +632,7 @@ static int generic_dpi_panel_probe(struct omap_dss_device
*dssdev)
dssdev->panel.timings = panel_config->timings;
- drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
+ drv_data = devm_kzalloc(&dssdev->dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
return -ENOMEM;
@@ -648,12 +648,8 @@ static int generic_dpi_panel_probe(struct omap_dss_device
*dssdev)
static void __exit generic_dpi_panel_remove(struct omap_dss_device *dssdev)
{
- struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
-
dev_dbg(&dssdev->dev, "remove\n");
- kfree(drv_data);
-
dev_set_drvdata(&dssdev->dev, NULL);
}
--
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 07/11] OMAPDSS: lb035q02: use devm_kzalloc for allocating driver data
Use devm_kzalloc instead of kzalloc to allocate driver data for the lg phillips
panel driver. This simplifies the driver's probe and remove functions.
Cc: Steve Sakoman
Signed-off-by: Archit Taneja
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index 6e5abe8..8effea8 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -89,27 +89,21 @@ static void lb035q02_panel_power_off(struct omap_dss_device
*dssdev)
static int lb035q02_panel_probe(struct omap_dss_device *dssdev)
{
struct lb035q02_data *ld;
- int r;
dssdev->panel.timings = lb035q02_timings;
- ld = kzalloc(sizeof(*ld), GFP_KERNEL);
- if (!ld) {
- r = -ENOMEM;
- goto err;
- }
+ ld = devm_kzalloc(&dssdev->dev, sizeof(*ld), GFP_KERNEL);
+ if (!ld)
+ return -ENOMEM;
+
mutex_init(&ld->lock);
dev_set_drvdata(&dssdev->dev, ld);
+
return 0;
-err:
- return r;
}
static void lb035q02_panel_remove(struct omap_dss_device *dssdev)
{
- struct lb035q02_data *ld = dev_get_drvdata(&dssdev->dev);
-
- kfree(ld);
}
static int lb035q02_panel_enable(struct omap_dss_device *dssdev)
--
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 08/11] OMAPDSS: picodlp: use devm_kzalloc for allocating driver data
Use devm_kzalloc instead of kzalloc to allocate driver data for the picodlp
panel driver. This simplifies the driver's probe and remove functions.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-picodlp.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
index 1b94018..3864299 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -423,11 +423,11 @@ static int picodlp_panel_probe(struct omap_dss_device
*dssdev)
struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
struct i2c_adapter *adapter;
struct i2c_client *picodlp_i2c_client;
- int r = 0, picodlp_adapter_id;
+ int picodlp_adapter_id;
dssdev->panel.timings = pico_ls_timings;
- picod = kzalloc(sizeof(struct picodlp_data), GFP_KERNEL);
+ picod = devm_kzalloc(&dssdev->dev, sizeof(*picod), GFP_KERNEL);
if (!picod)
return -ENOMEM;
@@ -438,25 +438,21 @@ static int picodlp_panel_probe(struct omap_dss_device
*dssdev)
adapter = i2c_get_adapter(picodlp_adapter_id);
if (!adapter) {
dev_err(&dssdev->dev, "can't get i2c adapter\n");
- r = -ENODEV;
- goto err;
+ return -ENODEV;
}
picodlp_i2c_client = i2c_new_device(adapter, &picodlp_i2c_board_info);
if (!picodlp_i2c_client) {
dev_err(&dssdev->dev, "can't add i2c device::"
" picodlp_i2c_client is NULL\n");
- r = -ENODEV;
- goto err;
+ return -ENODEV;
}
picod->picodlp_i2c_client = picodlp_i2c_client;
dev_set_drvdata(&dssdev->dev, picod);
- return r;
-err:
- kfree(picod);
- return r;
+
+ return 0;
}
static void picodlp_panel_remove(struct omap_dss_device *dssdev)
--
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 09/11] OMAPDSS: remove unnecessary DSI external TE pin platform info from omap_dss_device
The omap_dss_device provides platform related parameters ext_te and ext_te_gpio
for DSI command mode panels. These parameters are now owned by a panel driver's
platform_data instead.
Remove these fields as they aren't used anymore.
Signed-off-by: Archit Taneja
---
include/video/omapdss.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index d5dcd50..ec68769 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -579,9 +579,6 @@ struct omap_dss_device {
struct {
int module;
-
- bool ext_te;
- u8 ext_te_gpio;
} dsi;
struct {
--
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 10/11] OMAPDSS: panel acx565akm: remove omap_dss_device maximum backlight level usage
The omap_dss_device structs's max_backlight_level is used to pass maximum backlight level for the platform. However, no board file using this panel populates this field. Therefore, we remove it's usage from the panel driver. Signed-off-by: Archit Taneja --- drivers/video/omap2/displays/panel-acx565akm.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c index a980a11..a8fb26b 100644 --- a/drivers/video/omap2/displays/panel-acx565akm.c +++ b/drivers/video/omap2/displays/panel-acx565akm.c @@ -555,10 +555,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev) md->cabc_mode = get_hw_cabc_mode(md); } - if (md->has_bc) - max_brightness = 255; - else - max_brightness = dssdev->max_backlight_level; + max_brightness = 255; if (md->has_bc) brightness = acx565akm_get_actual_brightness(md); -- 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 11/11] OMAPDSS: Remove max_backlight_level form omap_dss_device
The maximum backlight level supported is a parameter which should come from
the panel's platform data. Usage of max_backlight_level in omap_dss_device has
been removed from all panel drivers. Remove it from the omap_dss_device struct.
Signed-off-by: Archit Taneja
---
include/video/omapdss.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ec68769..f0b65a5 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -631,8 +631,6 @@ struct omap_dss_device {
int reset_gpio;
- int max_backlight_level;
-
const char *name;
/* used to match device to driver */
--
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 v3 2/2] ARM: OMAP2+: Export SoC information to userspace
On Mon, Feb 11, 2013 at 7:56 PM, Tony Lindgren wrote:
> * Ruslan Bilovol [130206 14:54]:
>> --- a/arch/arm/mach-omap2/io.c
>> +++ b/arch/arm/mach-omap2/io.c
>> @@ -602,6 +602,7 @@ void __init omap4430_init_late(void)
>> omap2_common_pm_late_init();
>> omap4_pm_init();
>> omap2_clk_enable_autoidle_all();
>> + omap_soc_device_init();
>> }
>> #endif
>
> Looks like this should be called for all omaps instead
> of just omap4430?
>
> I suggest you create omap_common_init_late() that
> calls all the common init_late functions:
>
> static void __init omap_common_init_late(void)
> {
> omap_mux_late_init();
> omap2_common_pm_late_init();
> omap_soc_device_init();
> }
>
> Needs to be verified that these really are common to
> all omap2+ though :)
Yes, you are right, currently these functions are common to all
init_late callbacks that we have right now in io.c
I will prepare additional patch soon...
>
> 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
--
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 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
init functions in omap board files request panel specific gpios, and provide functions which omapdss panel drivers call to enable or disable them. Instead of the board files requesting these gpios, they should just pass the platform specific data(like the gpio numbers), the panel should retrieve the platform data and request the gpios. Doing this prevents the need of the panel driver calling platform functions in board files. Panel drivers have their own platform data struct, and the board files populate these structs and pass the pointer to the 'data' field of omap_dss_device. This work will make it easier for the panel drivers be more adaptable to the DT model. There is also removal of passing panel reset_gpio numbers through omap_dss_device struct directly, reset gpios are passed through platform data only. Reference tree: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.9/remove_enable_disable_callbacks Archit Taneja (32): OMAPDSS: panels: keep platform data of all panels in a single header arm: omap: board-2430: use generic dpi panel's gpio handling arm: omap: board-devkit8000: use generic dpi panel's gpio handling arm: omap: board-cm-t35: use generic dpi panel's gpio handling arm: omap: board-apollon: use generic dpi panel's gpio handling arm: omap: board-am3517: use generic dpi panel's gpio handling arm: omap: board-ldp: use generic dpi panel's gpio handling OMAPDSS: lb035q02: handle gpios in panel driver arm: omap: board-overo: use lb035q02 dpi panel's gpio handling OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks OMAPDSS: generic dpi panel: remove platform_enable/disable ops from platform_data arm: omap: board-omap3evm: use sharp panel's gpio handling arm: omap: board-sdp3430: use sharp panel's gpio handling OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks OMAPDSS: acx565akm panel: handle gpios in panel driver arm: omap: board-rx-51: use acx565akm panel's gpio handling OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver arm: omap: board-zoom: use NEC panel's gpio handling OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks OMAPDSS: tpo-td043 panel: handle gpios in panel driver arm: omap: board-omap3pandora: use tpo panel's gpio handling OMAPDSS: tpo-td043: remove platform_enable/disable callbacks OMAPDSS: picodlp panel: handle gpio data in panel driver arm: omap: dss-common: use picodlp panel's gpio handling OMAPDSS: picodlp panel: remove platform_enable/disable callbacks OMAPDSS: n8x0 panel: handle gpio data in panel driver OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC devices OMAPDSS: VENC: remove platform_enable/disable calls OMAPDSS: remove platform_enable/disable callbacks from omap_dss_device arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device OMAPDSS: remove reset_gpio field from omap_dss_device Tomi Valkeinen (1): OMAPDSS: generic dpi panel: handle gpios in panel driver arch/arm/mach-omap2/board-2430sdp.c| 45 +- arch/arm/mach-omap2/board-3430sdp.c| 55 +++- arch/arm/mach-omap2/board-am3517evm.c | 77 +-- arch/arm/mach-omap2/board-apollon.c| 11 +- arch/arm/mach-omap2/board-cm-t35.c | 60 +--- arch/arm/mach-omap2/board-devkit8000.c | 30 +--- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c| 63 ++--- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c | 72 +++--- arch/arm/mach-omap2/board-omap3pandora.c |7 +- arch/arm/mach-omap2/board-omap3stalker.c | 14 +- arch/arm/mach-omap2/board-overo.c | 61 ++--- arch/arm/mach-omap2/board-rx51-video.c | 26 +--- arch/arm/mach-omap2/board-zoom-display.c | 38 ++ arch/arm/mach-omap2/dss-common.c | 58 +++- drivers/video/omap2/displays/panel-acx565akm.c | 48 +-- drivers/video/omap2/displays/panel-generic-dpi.c | 33 +++-- .../omap2/displays/panel-lgphilips-lb035q02.c | 44 -- drivers/video/omap2/displays/panel-n8x0.c | 29 ++-- .../omap2/displays/panel-nec-nl8048hl11-01b.c | 53 --- drivers/video/omap2/displays/panel-picodlp.c | 35 +++-- .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 78 --- drivers/video/omap2/displays/panel-taal.c |2 +- drivers/video/omap2/displays/panel-tfp410.c|2 +- .../video/omap2/displays/panel-tpo-td043mtea1.c| 45 +++--- drivers/video/omap2/dss/venc.c |9 -- include/video/omap-panel-data.h|
[PATCH 01/33] OMAPDSS: panels: keep platform data of all panels in a single header
Structs for platform data of omapdss panels are found in headers in the 'include/video/' path. Board files populate these structs with platform specific values, and the panel driver uses these to configure the panel. Currently, each panel has it's own header in the above path. Move all the omapdss panel platform data structs to a single header omap-panel-data.h. This is useful because: - All other omapdss panel drivers will be modified to use platform data. This would lead to a lot of panel headers usable only by omapdss. A lot of these platform data structs are trivial, and don't really need a separate header. - Platform data would be eventually removed, and platform information would be passed via device tree. Therefore, omapdss panel platform data structs are temporary, and will be easier to remove if they are all in the same header. - All board files will have to include the same header to configure a panel's platform data, that makes the board files more consistent. Signed-off-by: Archit Taneja --- arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-am3517evm.c|3 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |3 +- arch/arm/mach-omap2/board-devkit8000.c |3 +- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |3 +- arch/arm/mach-omap2/board-overo.c|3 +- arch/arm/mach-omap2/dss-common.c |4 +- drivers/video/omap2/displays/panel-generic-dpi.c |2 +- drivers/video/omap2/displays/panel-n8x0.c|2 +- drivers/video/omap2/displays/panel-picodlp.c |2 +- drivers/video/omap2/displays/panel-taal.c|2 +- drivers/video/omap2/displays/panel-tfp410.c |2 +- include/video/omap-panel-data.h | 101 ++ include/video/omap-panel-generic-dpi.h | 37 include/video/omap-panel-n8x0.h | 13 --- include/video/omap-panel-nokia-dsi.h | 32 --- include/video/omap-panel-picodlp.h | 23 - include/video/omap-panel-tfp410.h| 35 25 files changed, 120 insertions(+), 166 deletions(-) create mode 100644 include/video/omap-panel-data.h delete mode 100644 include/video/omap-panel-generic-dpi.h delete mode 100644 include/video/omap-panel-n8x0.h delete mode 100644 include/video/omap-panel-nokia-dsi.h delete mode 100644 include/video/omap-panel-picodlp.h delete mode 100644 include/video/omap-panel-tfp410.h diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 4815ea6..13a1a3b 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -37,7 +37,7 @@ #include "gpmc-smc91x.h" #include -#include +#include #include "mux.h" #include "hsmmc.h" diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index bb73afc..fb75a81 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -33,7 +33,7 @@ #include "common.h" #include #include -#include +#include #include "gpmc.h" #include "gpmc-smc91x.h" diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index f81a303..2988049 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -35,8 +35,7 @@ #include "common.h" #include -#include -#include +#include #include "am35xx-emac.h" #include "mux.h" diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index 5d0a61f..d2a83a8 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -38,7 +38,7 @@ #include "gpmc.h" #include -#include +#include #include "mux.h" #include "control.h" diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index b3102c2..f940a79 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -40,8 +40,7 @@ #include #include -#include -#include +#include #include #include "common.h" diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index 12865af..019b212 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -42,8 +42,7 @@ #include "gpmc.h" #include #include -#include -#include +#include #include #include diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c index 3be1311..8
[PATCH 02/33] OMAPDSS: generic dpi panel: handle gpios in panel driver
From: Tomi Valkeinen
The generic dpi panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Add a generic way of passing gpio information to the generic dpi panel driver
via it's platform_data. This information includes the number of gpios used by
the panel, the gpio number and logic level (active high/low) for each gpio. This
gpio data will be used by the driver to request and configure the gpios required
by the panel.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 --
include/video/omap-panel-data.h |7 ++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index d8d0cd5..4a12db6 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -557,7 +558,7 @@ static inline struct panel_generic_dpi_data
static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
{
- int r;
+ int r, i;
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
struct panel_config *panel_config = drv_data->panel_config;
@@ -582,6 +583,11 @@ static int generic_dpi_panel_power_on(struct
omap_dss_device *dssdev)
goto err1;
}
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 0 : 1);
+ }
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -594,10 +600,16 @@ static void generic_dpi_panel_power_off(struct
omap_dss_device *dssdev)
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
struct panel_config *panel_config = drv_data->panel_config;
+ int i;
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ for (i = panel_data->num_gpios - 1; i >= 0; --i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 1 : 0);
+ }
+
if (panel_data->platform_disable)
panel_data->platform_disable(dssdev);
@@ -613,7 +625,7 @@ static int generic_dpi_panel_probe(struct omap_dss_device
*dssdev)
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_config *panel_config = NULL;
struct panel_drv_data *drv_data = NULL;
- int i;
+ int i, r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -630,6 +642,15 @@ static int generic_dpi_panel_probe(struct omap_dss_device
*dssdev)
if (!panel_config)
return -EINVAL;
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->gpios[i],
+ panel_data->gpio_invert[i] ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ "panel gpio");
+ if (r)
+ return r;
+ }
+
dssdev->panel.timings = panel_config->timings;
drv_data = devm_kzalloc(&dssdev->dev, sizeof(*drv_data), GFP_KERNEL);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index e8e30f9..eec93f1 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -34,11 +34,18 @@ struct omap_dss_device;
* @name: panel name
* @platform_enable: platform specific panel enable function
* @platform_disable: platform specific panel disable function
+ * @num_gpios: number of gpios connected to panel
+ * @gpios: gpio numbers on the platform
+ * @gpio_invert: configure gpio as active high or low
*/
struct panel_generic_dpi_data {
const char *name;
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
+
+ int num_gpios;
+ int gpios[10];
+ bool gpio_invert[10];
};
/**
--
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 03/33] arm: omap: board-2430: use generic dpi panel's gpio handling
The 2430sdp board file currently requests gpios required to configure the NEC
DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-2430sdp.c | 43 +--
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 13a1a3b..c888a58 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -107,24 +107,13 @@ static struct platform_device *sdp2430_devices[]
__initdata = {
#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
#define SDP2430_LCD_PANEL_ENABLE_GPIO 154
-static int sdp2430_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 1);
-
- return 0;
-}
-
-static void sdp2430_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 0);
- gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 0);
-}
-
static struct panel_generic_dpi_data sdp2430_panel_data = {
.name = "nec_nl2432dr22-11b",
- .platform_enable= sdp2430_panel_enable_lcd,
- .platform_disable = sdp2430_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ SDP2430_LCD_PANEL_ENABLE_GPIO,
+ SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
+ },
};
static struct omap_dss_device sdp2430_lcd_device = {
@@ -145,26 +134,6 @@ static struct omap_dss_board_info sdp2430_dss_data = {
.default_device = &sdp2430_lcd_device,
};
-static void __init sdp2430_display_init(void)
-{
- int r;
-
- static struct gpio gpios[] __initdata = {
- { SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
- "LCD reset" },
- { SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
- "LCD Backlight" },
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- return;
- }
-
- omap_display_init(&sdp2430_dss_data);
-}
-
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
static struct omap_smc91x_platform_data board_smc91x_data = {
@@ -271,7 +240,7 @@ static void __init omap_2430sdp_init(void)
gpio_request_one(SECONDARY_LCD_GPIO, GPIOF_OUT_INIT_LOW,
"Secondary LCD backlight");
- sdp2430_display_init();
+ omap_display_init(&sdp2430_dss_data);
}
MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
--
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 04/33] arm: omap: board-devkit8000: use generic dpi panel's gpio handling
The devkit8000 board file currently requests gpios required to configure the
innolux DPI panel, and provides platform_enable/disable callbacks to configure
them.
These tasks have been moved to the generic dpi panel driver itself and should
be removed from the board files.
Remove the gpio request and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-devkit8000.c | 27 +++
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 019b212..ccef86d 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -102,19 +102,6 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 1);
- return 0;
-}
-
-static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(dssdev->reset_gpio))
- gpio_set_value_cansleep(dssdev->reset_gpio, 0);
-}
-
static struct regulator_consumer_supply devkit8000_vmmc1_supply[] = {
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
};
@@ -126,8 +113,7 @@ static struct regulator_consumer_supply
devkit8000_vio_supply[] = {
static struct panel_generic_dpi_data lcd_panel = {
.name = "innolux_at070tn83",
- .platform_enable= devkit8000_panel_enable_lcd,
- .platform_disable = devkit8000_panel_disable_lcd,
+ /* gpios filled in code */
};
static struct omap_dss_device devkit8000_lcd_device = {
@@ -209,8 +195,6 @@ static struct gpio_led gpio_leds[];
static int devkit8000_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- int ret;
-
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
omap_hsmmc_late_init(mmc);
@@ -219,13 +203,8 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
/* TWL4030_GPIO_MAX + 0 is "LCD_PWREN" (out, active high) */
- devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
- ret = gpio_request_one(devkit8000_lcd_device.reset_gpio,
- GPIOF_OUT_INIT_LOW, "LCD_PWREN");
- if (ret < 0) {
- devkit8000_lcd_device.reset_gpio = -EINVAL;
- printk(KERN_ERR "Failed to request GPIO for LCD_PWRN\n");
- }
+ lcd_panel.num_gpios = 1;
+ lcd_panel.gpios[0] = gpio + TWL4030_GPIO_MAX + 0;
/* gpio + 7 is "DVI_PD" (out, active low) */
dvi_panel.power_down_gpio = gpio + 7;
--
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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
The cm-t35 board file currently requests gpios required to configure the tdo35s
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was
enabled after a 50 millisecond delay. This code has been removed and is not
taken care of in the generic panel driver. The impact of this needs to be
tested. The panel's gpios are also not exported any more. Hence, they can't be
accessed via sysfs interface.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-cm-t35.c | 46
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index f940a79..563d5ab 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -189,32 +189,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int lcd_enabled;
-static int dvi_enabled;
-
-static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
- gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
-
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- lcd_enabled = 0;
-
- gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
-}
-
static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
{
return 0;
@@ -226,8 +200,11 @@ static void cm_t35_panel_disable_tv(struct omap_dss_device
*dssdev)
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
- .platform_enable= cm_t35_panel_enable_lcd,
- .platform_disable = cm_t35_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ CM_T35_LCD_BL_GPIO,
+ CM_T35_LCD_EN_GPIO
+ },
};
static struct omap_dss_device cm_t35_lcd_device = {
@@ -303,19 +280,6 @@ static void __init cm_t35_init_display(void)
spi_register_board_info(cm_t35_lcd_spi_board_info,
ARRAY_SIZE(cm_t35_lcd_spi_board_info));
- err = gpio_request_array(cm_t35_dss_gpios,
-ARRAY_SIZE(cm_t35_dss_gpios));
- if (err) {
- pr_err("CM-T35: failed to request DSS control GPIOs\n");
- return;
- }
-
- gpio_export(CM_T35_LCD_EN_GPIO, 0);
- gpio_export(CM_T35_LCD_BL_GPIO, 0);
-
- msleep(50);
- gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
-
err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
--
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 06/33] arm: omap: board-apollon: use generic dpi panel's gpio handling
The apollon board file currently configures the LCD_PWR_EN gpio by muxing the
corresponding pin to gpio 11, and configuring it in PULL UP mode.
Remove this muxing from the board file. Add the gpio information to generic dpi
panel's platform data so that it's passed to the panel driver. The panel driver
will take care of requesting and setting the LCD_PWR_EN gpio.
Note: This should be tested to ensure that setting the GPIO is equivalent to
configuring the GPIO in PULL UP mode. Also, this GPIO was just set once during
init, and never cleared, where as now the gpio will toggle everytime the panel
is disabled/enabled. The impact of this needs to be tested.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-apollon.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index d2a83a8..5cc957e 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -55,6 +55,8 @@
#define APOLLON_ETH_CS 1
#define APOLLON_ETHR_GPIO_IRQ 74
+#define APOLLON_LCD_PWR_EN 11
+
static struct mtd_partition apollon_partitions[] = {
{
.name = "X-Loader + U-Boot",
@@ -252,6 +254,10 @@ out:
static struct panel_generic_dpi_data apollon_panel_data = {
.name = "apollon",
+ .num_gpios = 1,
+ .gpios = {
+ APOLLON_LCD_PWR_EN,
+ },
};
static struct omap_dss_device apollon_lcd_device = {
@@ -306,9 +312,6 @@ static void __init omap_apollon_init(void)
/* REVISIT: where's the correct place */
omap_mux_init_signal("sys_nirq", OMAP_PULL_ENA | OMAP_PULL_UP);
- /* LCD PWR_EN */
- omap_mux_init_signal("mcbsp2_dr.gpio_11", OMAP_PULL_ENA | OMAP_PULL_UP);
-
/* Use Internal loop-back in MMC/SDIO Module Input Clock selection */
v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
v |= (1 << 24);
--
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 07/33] arm: omap: board-am3517: use generic dpi panel's gpio handling
The am3517 board file currently requests gpios required to configure the sharp
lq DPI panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to generic dpi panel's platform data so that it's
passed to the panel driver.
Note: It's not clear why the GPIOs were muxed as input signals in PULL down mode
in am3517_evm_display_init(). Also, only the LCD_PANEL_PWR was toggled in the
platform_enable/disable calls, the generic DPI panel driver will now toggle all
the three gpios on panel's disable/enable. We need to test if these changes to
see if they have any impact or not.
Cc: Tony Lindgren
Cc: Vaibhav Hiremath
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-am3517evm.c | 63 -
1 file changed, 6 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 2988049..eb245a6 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -120,63 +120,14 @@ static int __init am3517_evm_i2c_init(void)
return 0;
}
-static int lcd_enabled;
-static int dvi_enabled;
-
-#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
- defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
-static struct gpio am3517_evm_dss_gpios[] __initdata = {
- /* GPIO 182 = LCD Backlight Power */
- { LCD_PANEL_BKLIGHT_PWR, GPIOF_OUT_INIT_HIGH, "lcd_backlight_pwr" },
- /* GPIO 181 = LCD Panel PWM */
- { LCD_PANEL_PWM, GPIOF_OUT_INIT_HIGH, "lcd bl enable" },
- /* GPIO 176 = LCD Panel Power enable pin */
- { LCD_PANEL_PWR, GPIOF_OUT_INIT_HIGH, "dvi enable"},
-};
-
-static void __init am3517_evm_display_init(void)
-{
- int r;
-
- omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR, OMAP_PIN_INPUT_PULLDOWN);
- omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
-
- r = gpio_request_array(am3517_evm_dss_gpios,
- ARRAY_SIZE(am3517_evm_dss_gpios));
- if (r) {
- printk(KERN_ERR "failed to get DSS panel control GPIOs\n");
- return;
- }
-
- printk(KERN_INFO "Display initialized successfully\n");
-}
-#else
-static void __init am3517_evm_display_init(void) {}
-#endif
-
-static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
- gpio_set_value(LCD_PANEL_PWR, 1);
- lcd_enabled = 1;
-
- return 0;
-}
-
-static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(LCD_PANEL_PWR, 0);
- lcd_enabled = 0;
-}
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "sharp_lq",
- .platform_enable= am3517_evm_panel_enable_lcd,
- .platform_disable = am3517_evm_panel_disable_lcd,
+ .num_gpios = 3,
+ .gpios = {
+ LCD_PANEL_PWR,
+ LCD_PANEL_BKLIGHT_PWR,
+ LCD_PANEL_PWM,
+ },
};
static struct omap_dss_device am3517_evm_lcd_device = {
@@ -362,8 +313,6 @@ static void __init am3517_evm_init(void)
omap_mux_init_gpio(57, OMAP_PIN_OUTPUT);
usbhs_init(&usbhs_bdata);
am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
- /* DSS */
- am3517_evm_display_init();
/* RTC - S35390A */
am3517_evm_rtc_init();
--
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 08/33] arm: omap: board-ldp: use generic dpi panel's gpio handling
The ldp board file currently requests gpios required to configure the NEC DPI
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the generic dpi panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Configure the gpio information in generic dpi panel's platform data so that it's
passed to the panel driver.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-ldp.c | 61 ++-
1 file changed, 9 insertions(+), 52 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 68e56f1..c88d01a 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -180,34 +180,13 @@ static inline void __init ldp_init_smsc911x(void)
/* LCD */
-static int ldp_backlight_gpio;
-static int ldp_lcd_enable_gpio;
-
#define LCD_PANEL_RESET_GPIO 55
#define LCD_PANEL_QVGA_GPIO56
-static int ldp_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(ldp_lcd_enable_gpio))
- gpio_direction_output(ldp_lcd_enable_gpio, 1);
- if (gpio_is_valid(ldp_backlight_gpio))
- gpio_direction_output(ldp_backlight_gpio, 1);
-
- return 0;
-}
-
-static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- if (gpio_is_valid(ldp_lcd_enable_gpio))
- gpio_direction_output(ldp_lcd_enable_gpio, 0);
- if (gpio_is_valid(ldp_backlight_gpio))
- gpio_direction_output(ldp_backlight_gpio, 0);
-}
-
static struct panel_generic_dpi_data ldp_panel_data = {
.name = "nec_nl2432dr22-11b",
- .platform_enable= ldp_panel_enable_lcd,
- .platform_disable = ldp_panel_disable_lcd,
+ .num_gpios = 4,
+ /* gpios filled in code */
};
static struct omap_dss_device ldp_lcd_device = {
@@ -230,41 +209,19 @@ static struct omap_dss_board_info ldp_dss_data = {
static void __init ldp_display_init(void)
{
- int r;
-
- static struct gpio gpios[] __initdata = {
- {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
- {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- return;
- }
+ ldp_panel_data.gpios[2] = LCD_PANEL_RESET_GPIO;
+ ldp_panel_data.gpios[3] = LCD_PANEL_QVGA_GPIO;
omap_display_init(&ldp_dss_data);
}
static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned
ngpio)
{
- int r;
-
- struct gpio gpios[] = {
- {gpio + 7 , GPIOF_OUT_INIT_LOW, "LCD ENABLE"},
- {gpio + 15, GPIOF_OUT_INIT_LOW, "LCD BACKLIGHT"},
- };
-
- r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
- if (r) {
- pr_err("Cannot request LCD GPIOs, error %d\n", r);
- ldp_backlight_gpio = -EINVAL;
- ldp_lcd_enable_gpio = -EINVAL;
- return r;
- }
-
- ldp_backlight_gpio = gpio + 15;
- ldp_lcd_enable_gpio = gpio + 7;
+ ldp_panel_data.gpios[0] = gpio + 7;
+ ldp_panel_data.gpio_invert[0] = true;
+
+ ldp_panel_data.gpios[1] = gpio + 15;
+ ldp_panel_data.gpio_invert[1] = true;
return 0;
}
--
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 09/33] OMAPDSS: lb035q02: handle gpios in panel driver
The lgphilips panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the
panel driver itself.
Use the platform data as defined for generic dpi panels to pass gpio information
to the lgphilips driver.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 38 +++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index 8effea8..63cd8857 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -20,8 +20,10 @@
#include
#include
#include
+#include
#include
+#include
struct lb035q02_data {
struct mutex lock;
@@ -48,9 +50,16 @@ static struct omap_video_timings lb035q02_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_generic_dpi_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_generic_dpi_data *) dssdev->data;
+}
+
static int lb035q02_panel_power_on(struct omap_dss_device *dssdev)
{
- int r;
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ int r, i;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
return 0;
@@ -68,6 +77,11 @@ static int lb035q02_panel_power_on(struct omap_dss_device
*dssdev)
goto err1;
}
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 0 : 1);
+ }
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -77,9 +91,17 @@ err0:
static void lb035q02_panel_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ int i;
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ for (i = panel_data->num_gpios - 1; i >= 0; --i) {
+ gpio_set_value_cansleep(panel_data->gpios[i],
+ panel_data->gpio_invert[i] ? 1 : 0);
+ }
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
@@ -88,7 +110,12 @@ static void lb035q02_panel_power_off(struct omap_dss_device
*dssdev)
static int lb035q02_panel_probe(struct omap_dss_device *dssdev)
{
+ struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct lb035q02_data *ld;
+ int r, i;
+
+ if (!panel_data)
+ return -EINVAL;
dssdev->panel.timings = lb035q02_timings;
@@ -96,6 +123,15 @@ static int lb035q02_panel_probe(struct omap_dss_device
*dssdev)
if (!ld)
return -ENOMEM;
+ for (i = 0; i < panel_data->num_gpios; ++i) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->gpios[i],
+ panel_data->gpio_invert[i] ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ "panel gpio");
+ if (r)
+ return r;
+ }
+
mutex_init(&ld->lock);
dev_set_drvdata(&dssdev->dev, ld);
--
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 10/33] arm: omap: board-overo: use lb035q02 dpi panel's gpio handling
The overo board file currently requests gpios required by the lb035q02 panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the lb035q02 dpi panel driver itself and should
be removed from the board files.
The lb035q02 panel driver uses generic dpi panel's platform data struct
internally. Remove the gpio requests and the platform callbacks from the board
file. Add the gpio information to the generic dpi panel platform data struct so
that it's passed to the panel driver.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-overo.c | 58 +
1 file changed, 14 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index bf6b2ce..888e150 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -144,28 +144,9 @@ static inline void __init overo_init_smsc911x(void) {
return; }
#endif
/* DSS */
-static int lcd_enabled;
-static int dvi_enabled;
-
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145
-static struct gpio overo_dss_gpios[] __initdata = {
- { OVERO_GPIO_LCD_EN, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_EN" },
- { OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
-};
-
-static void __init overo_display_init(void)
-{
- if (gpio_request_array(overo_dss_gpios, ARRAY_SIZE(overo_dss_gpios))) {
- printk(KERN_ERR "could not obtain DSS control GPIOs\n");
- return;
- }
-
- gpio_export(OVERO_GPIO_LCD_EN, 0);
- gpio_export(OVERO_GPIO_LCD_BL, 0);
-}
-
static struct tfp410_platform_data dvi_panel = {
.i2c_bus_num= 3,
.power_down_gpio= -1,
@@ -186,30 +167,13 @@ static struct omap_dss_device overo_tv_device = {
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
};
-static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(OVERO_GPIO_LCD_EN, 1);
- gpio_set_value(OVERO_GPIO_LCD_BL, 1);
- lcd_enabled = 1;
- return 0;
-}
-
-static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(OVERO_GPIO_LCD_EN, 0);
- gpio_set_value(OVERO_GPIO_LCD_BL, 0);
- lcd_enabled = 0;
-}
-
static struct panel_generic_dpi_data lcd43_panel = {
.name = "samsung_lte430wq_f0c",
- .platform_enable= overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
+ .num_gpios = 2,
+ .gpios = {
+ OVERO_GPIO_LCD_EN,
+ OVERO_GPIO_LCD_BL
+ },
};
static struct omap_dss_device overo_lcd43_device = {
@@ -222,13 +186,20 @@ static struct omap_dss_device overo_lcd43_device = {
#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
+static struct panel_generic_dpi_data lcd35_panel = {
+ .num_gpios = 2,
+ .gpios = {
+ OVERO_GPIO_LCD_EN,
+ OVERO_GPIO_LCD_BL
+ },
+};
+
static struct omap_dss_device overo_lcd35_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = "lcd35",
.driver_name= "lgphilips_lb035q02_panel",
.phy.dpi.data_lines = 24,
- .platform_enable= overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
+ .data = &lcd35_panel,
};
#endif
@@ -502,7 +473,6 @@ static void __init overo_init(void)
usbhs_init(&usbhs_bdata);
overo_spi_init();
overo_init_smsc911x();
- overo_display_init();
overo_init_led();
overo_init_keys();
omap_twl4030_audio_init("overo");
--
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 11/33] OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks
The lgphilips panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja
---
.../omap2/displays/panel-lgphilips-lb035q02.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index 63cd8857..4ea6548 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -71,20 +71,13 @@ static int lb035q02_panel_power_on(struct omap_dss_device
*dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
for (i = 0; i < panel_data->num_gpios; ++i) {
gpio_set_value_cansleep(panel_data->gpios[i],
panel_data->gpio_invert[i] ? 0 : 1);
}
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -102,9 +95,6 @@ static void lb035q02_panel_power_off(struct omap_dss_device
*dssdev)
panel_data->gpio_invert[i] ? 1 : 0);
}
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
}
--
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 12/33] OMAPDSS: generic dpi panel: remove platform_enable/disable ops from platform_data
The generic dpi panel driver now sets the gpios required to configure the panel.
This was previously done in platform_enable/disable callbacks in board files.
All the board files using generic dpi panel now correctly pass the gpio related
information as platform data, which is needed by the panel driver to configure
the panel. Hence, the platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-generic-dpi.c | 12 +---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 71 +---
include/video/omap-panel-data.h| 20 --
3 files changed, 77 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 4a12db6..64d93b1 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -577,20 +577,13 @@ static int generic_dpi_panel_power_on(struct
omap_dss_device *dssdev)
if (panel_config->power_on_delay)
msleep(panel_config->power_on_delay);
- if (panel_data->platform_enable) {
- r = panel_data->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
for (i = 0; i < panel_data->num_gpios; ++i) {
gpio_set_value_cansleep(panel_data->gpios[i],
panel_data->gpio_invert[i] ? 0 : 1);
}
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -610,9 +603,6 @@ static void generic_dpi_panel_power_off(struct
omap_dss_device *dssdev)
panel_data->gpio_invert[i] ? 1 : 0);
}
- if (panel_data->platform_disable)
- panel_data->platform_disable(dssdev);
-
/* wait couple of vsyncs after disabling the LCD */
if (panel_config->power_off_delay)
msleep(panel_config->power_off_delay);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index eb6bd81..e6d9c9b 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -23,11 +23,10 @@
#include
#include
#include
+#include
#include
-
-struct sharp_data {
-};
+#include
static struct omap_video_timings sharp_ls_timings = {
.x_res = 480,
@@ -50,31 +49,67 @@ static struct omap_video_timings sharp_ls_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_sharp_ls037v7dw01_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_sharp_ls037v7dw01_data *) dssdev->data;
+}
static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd;
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
+ int r;
+
+ if (!pd)
+ return -EINVAL;
dssdev->panel.timings = sharp_ls_timings;
- sd = kzalloc(sizeof(*sd), GFP_KERNEL);
- if (!sd)
- return -ENOMEM;
+ if (gpio_is_valid(pd->mo_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->mo_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd MO");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->lr_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->lr_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd LR");
+ if (r)
+ return r;
+ }
- dev_set_drvdata(&dssdev->dev, sd);
+ if (gpio_is_valid(pd->ud_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->ud_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd UD");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->resb_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->resb_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RESB");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(pd->ini_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->ini_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd INI");
+ if (r)
+ return r;
+ }
return 0;
}
static void __exit sharp_ls_panel_remove(struct omap_dss_device *dssdev)
{
- struct sharp_data *sd = dev_get_drvdata(&dssdev->dev);
-
- kfree(sd);
}
static int sharp_ls_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_sharp_ls037v7dw01_data *pd = get_panel_data(dssdev);
int r = 0;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
@@ -96,6 +131,12 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
go
[PATCH 14/33] arm: omap: board-sdp3430: use sharp panel's gpio handling
The omap3430sdp board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's
passed to the panel driver.
Out of sharp panel's configurable pins, all apart from resb_gpio are managed by
a CPLD on the display and set to a default value. Only the configurable pin is
passed to platform data.
The backlight GPIO doesn't go directly to the sharp panel, it is used to set up
a voltage supply which goes to the LED+ pin of the panel, hence it isn't passed
to panel as platform data, and configured in the board file itself. The
backlight used to previously toggle through the platform_enable/disable
callbacks, but now it is always on. This needs to be revisited.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-3430sdp.c | 42 +++
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index fb75a81..13f1431 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -106,34 +106,22 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
-static struct gpio sdp3430_dss_gpios[] __initdata = {
- {SDP3430_LCD_PANEL_ENABLE_GPIO,GPIOF_OUT_INIT_LOW, "LCD reset"},
- {SDP3430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, "LCD Backlight"},
-};
-
static void __init sdp3430_display_init(void)
{
int r;
- r = gpio_request_array(sdp3430_dss_gpios,
- ARRAY_SIZE(sdp3430_dss_gpios));
+ /*
+* the backlight GPIO doesn't directly go to the panel, it enables
+* an internal circuit on 3430sdp to create the signal V_BKL_28V,
+* this is connected to LED+ pin of the sharp panel. This GPIO
+* is left enabled in the board file, and not passed to the panel
+* as platform_data.
+*/
+ r = gpio_request_one(SDP3430_LCD_PANEL_BACKLIGHT_GPIO,
+ GPIOF_OUT_INIT_HIGH, "LCD Backlight");
if (r)
- printk(KERN_ERR "failed to get LCD control GPIOs\n");
-
-}
-
-static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 1);
- gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 1);
-
- return 0;
-}
+ pr_err("failed to get LCD Backlight GPIO\n");
-static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_direction_output(SDP3430_LCD_PANEL_ENABLE_GPIO, 0);
- gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 0);
}
static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -145,14 +133,20 @@ static void sdp3430_panel_disable_tv(struct
omap_dss_device *dssdev)
{
}
+static struct panel_sharp_ls037v7dw01_data sdp3430_lcd_data = {
+ .resb_gpio = SDP3430_LCD_PANEL_ENABLE_GPIO,
+ .ini_gpio = -1,
+ .mo_gpio = -1,
+ .lr_gpio = -1,
+ .ud_gpio = -1,
+};
static struct omap_dss_device sdp3430_lcd_device = {
.name = "lcd",
.driver_name= "sharp_ls_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 16,
- .platform_enable= sdp3430_panel_enable_lcd,
- .platform_disable = sdp3430_panel_disable_lcd,
+ .data = &sdp3430_lcd_data,
};
static struct tfp410_platform_data dvi_panel = {
--
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 15/33] OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks
The sharp-ls panel driver now manages the gpios required to configure the panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_sharp_ls037v7dw01_data struct, which is needed by the panel
driver to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja
---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index e6d9c9b..74cb0eb 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -125,12 +125,6 @@ static int sharp_ls_power_on(struct omap_dss_device
*dssdev)
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
if (gpio_is_valid(pd->resb_gpio))
gpio_set_value_cansleep(pd->resb_gpio, 1);
@@ -138,8 +132,6 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
gpio_set_value_cansleep(pd->ini_gpio, 1);
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
err0:
return r;
}
@@ -157,9 +149,6 @@ static void sharp_ls_power_off(struct omap_dss_device
*dssdev)
if (gpio_is_valid(pd->resb_gpio))
gpio_set_value_cansleep(pd->resb_gpio, 0);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
/* wait at least 5 vsyncs after disabling the LCD */
msleep(100);
--
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 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
The acx565akm panel driver leaves gpio configurations to the platform_enable
and disable calls in the platform's board file. These should happen in the panel
driver itself.
Create a platform data struct for the panel, this contains the reset gpio number
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure the reset gpio rather than
leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-acx565akm.c | 48
include/video/omap-panel-data.h|8
2 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index a8fb26b..d7f69c0 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -29,8 +29,10 @@
#include
#include
#include
+#include
#include
+#include
#define MIPID_CMD_READ_DISP_ID 0x04
#define MIPID_CMD_READ_RED 0x06
@@ -494,21 +496,38 @@ static struct omap_video_timings acx_panel_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device
*dssdev)
+{
+ return (struct panel_acx565akm_data *) dssdev->data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
int r;
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
struct backlight_device *bldev;
int max_brightness, brightness;
struct backlight_properties props;
dev_dbg(&dssdev->dev, "%s\n", __func__);
+ if (!panel_data)
+ return -EINVAL;
+
/* FIXME AC bias ? */
dssdev->panel.timings = acx_panel_timings;
- if (dssdev->platform_enable)
- dssdev->platform_enable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, panel_data->reset_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd reset");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 1);
+
/*
* After reset we have to wait 5 msec before the first
* command can be sent.
@@ -520,8 +539,9 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
r = panel_detect(md);
if (r) {
dev_err(&dssdev->dev, "%s panel detect error\n", __func__);
- if (!md->enabled && dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (!md->enabled && gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
+
return r;
}
@@ -530,8 +550,8 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
mutex_unlock(&acx_dev.mutex);
if (!md->enabled) {
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 0);
}
/*--- Backlight control */
@@ -584,6 +604,7 @@ static void acx_panel_remove(struct omap_dss_device *dssdev)
static int acx_panel_power_on(struct omap_dss_device *dssdev)
{
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
int r;
dev_dbg(&dssdev->dev, "%s\n", __func__);
@@ -605,11 +626,8 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
/*FIXME tweak me */
msleep(50);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto fail;
- }
+ if (gpio_is_valid(panel_data->reset_gpio))
+ gpio_set_value(panel_data->reset_gpio, 1);
if (md->enabled) {
dev_dbg(&md->spi->dev, "panel already enabled\n");
@@ -638,8 +656,7 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
mutex_unlock(&md->mutex);
return acx565akm_bl_update_status(md->bl_dev);
-fail:
- omapdss_sdi_display_disable(dssdev);
+
fail_unlock:
mutex_unlock(&md->mutex);
return r;
@@ -648,6 +665,7 @@ fail_unlock:
static void acx_panel_power_off(struct omap_dss_device *dssdev)
{
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
dev_dbg(&dssdev->dev, "%s\n", __func__);
@@ -671,8 +689,8 @@ static void acx_panel_power_off(struct
[PATCH 17/33] arm: omap: board-rx-51: use acx565akm panel's gpio handling
The rx-51 board file currently requests gpios required by the acx565akm panel,
and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the acx565akm panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file. Pass
the panel_acx565akm_data instance 'lcd_data' to omap_dss_device instead of
passing the gpio number in omap_dss_device's reset_gpio.
Add the gpio information to panel_acx565akm_data so that it's passed to the
panel driver.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-rx51-video.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 46f4fc9..9e8afa4 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+
#include
#include "board-rx51.h"
@@ -26,25 +28,16 @@
#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
-static int rx51_lcd_enable(struct omap_dss_device *dssdev)
-{
- gpio_set_value(dssdev->reset_gpio, 1);
- return 0;
-}
-
-static void rx51_lcd_disable(struct omap_dss_device *dssdev)
-{
- gpio_set_value(dssdev->reset_gpio, 0);
-}
+static struct panel_acx565akm_data lcd_data = {
+ .reset_gpio = RX51_LCD_RESET_GPIO,
+};
static struct omap_dss_device rx51_lcd_device = {
.name = "lcd",
.driver_name= "panel-acx565akm",
.type = OMAP_DISPLAY_TYPE_SDI,
.phy.sdi.datapairs = 2,
- .reset_gpio = RX51_LCD_RESET_GPIO,
- .platform_enable= rx51_lcd_enable,
- .platform_disable = rx51_lcd_disable,
+ .data = &lcd_data,
};
static struct omap_dss_device rx51_tv_device = {
@@ -75,13 +68,8 @@ static int __init rx51_video_init(void)
return 0;
}
- if (gpio_request_one(RX51_LCD_RESET_GPIO, GPIOF_OUT_INIT_HIGH,
-"LCD ACX565AKM reset")) {
- pr_err("%s failed to get LCD Reset GPIO\n", __func__);
- return 0;
- }
-
omap_display_init(&rx51_dss_board_info);
+
return 0;
}
--
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 18/33] OMAPDSS: nec-nl8048 panel: handle gpios ins panel driver
The nec-nl8048hl11-01 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the gpio numbers
used by the panel driver, this struct will be passed to the panel driver as
platform data. The driver will request and configure these gpios rather than
leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 45 +++-
include/video/omap-panel-data.h| 10 +
2 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index c197927..3b85e2a 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -20,8 +20,10 @@
#include
#include
#include
+#include
#include
+#include
#define LCD_XRES 800
#define LCD_YRES 480
@@ -31,9 +33,6 @@
*/
#define LCD_PIXEL_CLOCK23800
-struct nec_8048_data {
-};
-
static const struct {
unsigned char addr;
unsigned char dat;
@@ -82,30 +81,46 @@ static struct omap_video_timings nec_8048_panel_timings = {
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
};
+static inline struct panel_nec_nl8048_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_nec_nl8048_data *) dssdev->data;
+}
+
static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd;
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
+ int r;
+
+ if (!pd)
+ return -EINVAL;
dssdev->panel.timings = nec_8048_panel_timings;
- necd = kzalloc(sizeof(*necd), GFP_KERNEL);
- if (!necd)
- return -ENOMEM;
+ if (gpio_is_valid(pd->qvga_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->qvga_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd QVGA");
+ if (r)
+ return r;
+ }
- dev_set_drvdata(&dssdev->dev, necd);
+ if (gpio_is_valid(pd->res_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev, pd->res_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd RES");
+ if (r)
+ return r;
+ }
return 0;
}
static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
-
- kfree(necd);
}
static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
{
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
int r;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
@@ -124,6 +139,9 @@ static int nec_8048_panel_power_on(struct omap_dss_device
*dssdev)
goto err1;
}
+ if (gpio_is_valid(pd->res_gpio))
+ gpio_set_value_cansleep(pd->res_gpio, 1);
+
return 0;
err1:
omapdss_dpi_display_disable(dssdev);
@@ -133,9 +151,14 @@ err0:
static void nec_8048_panel_power_off(struct omap_dss_device *dssdev)
{
+ struct panel_nec_nl8048_data *pd = get_panel_data(dssdev);
+
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
+ if (gpio_is_valid(pd->res_gpio))
+ gpio_set_value_cansleep(pd->res_gpio, 0);
+
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 6faf0c7..e7698e2 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -125,4 +125,14 @@ struct panel_acx565akm_data {
int reset_gpio;
};
+/**
+ * nec nl8048 panel driver configuration data
+ * @res_gpio: reset signal
+ * @qvga_gpio: selection for resolution(QVGA/WVGA)
+ */
+struct panel_nec_nl8048_data {
+ int res_gpio;
+ int qvga_gpio;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
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 20/33] OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks
The nec-nl8048 panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_nec_nl8048_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index 3b85e2a..1e0097d 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -133,18 +133,11 @@ static int nec_8048_panel_power_on(struct omap_dss_device
*dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
if (gpio_is_valid(pd->res_gpio))
gpio_set_value_cansleep(pd->res_gpio, 1);
return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
+
err0:
return r;
}
@@ -159,9 +152,6 @@ static void nec_8048_panel_power_off(struct omap_dss_device
*dssdev)
if (gpio_is_valid(pd->res_gpio))
gpio_set_value_cansleep(pd->res_gpio, 0);
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
}
--
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 19/33] arm: omap: board-zoom: use NEC panel's gpio handling
The zoom board file currently requests gpios required by the nec-nl8048hl11-01
dpi panel, and provides dummy platform_enable/disable callbacks.
gpio request and configuration have been moved to the nec-nl8048hl11-01 panel
driver itself and shouldn't be done in the board files.
Remove the gpio requests and the platform callbacks from the board file. Add the
gpio information to panel_nec_nl8048_data so that it's passed to the panel
driver.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-zoom-display.c | 38 ++
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
index 4717ed5..bd79082 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -16,8 +16,9 @@
#include
#include
#include
-#include "board-zoom.h"
+#include
+#include "board-zoom.h"
#include "soc.h"
#include "common.h"
@@ -25,30 +26,11 @@
#define LCD_PANEL_RESET_GPIO_PILOT 55
#define LCD_PANEL_QVGA_GPIO56
-static struct gpio zoom_lcd_gpios[] __initdata = {
- { -EINVAL, GPIOF_OUT_INIT_HIGH, "lcd reset" },
- { LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "lcd qvga" },
+static struct panel_nec_nl8048_data zoom_lcd_data = {
+ /* res_gpio filled in code */
+ .qvga_gpio = LCD_PANEL_QVGA_GPIO,
};
-static void __init zoom_lcd_panel_init(void)
-{
- zoom_lcd_gpios[0].gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
- LCD_PANEL_RESET_GPIO_PROD :
- LCD_PANEL_RESET_GPIO_PILOT;
-
- if (gpio_request_array(zoom_lcd_gpios, ARRAY_SIZE(zoom_lcd_gpios)))
- pr_err("%s: Failed to get LCD GPIOs.\n", __func__);
-}
-
-static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
-}
-
/*
* PWMA/B register offsets (TWL4030_MODULE_PWMA)
*/
@@ -107,8 +89,7 @@ static struct omap_dss_device zoom_lcd_device = {
.driver_name= "NEC_8048_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
- .platform_enable= zoom_panel_enable_lcd,
- .platform_disable = zoom_panel_disable_lcd,
+ .data = &zoom_lcd_data,
};
static struct omap_dss_device *zoom_dss_devices[] = {
@@ -121,6 +102,13 @@ static struct omap_dss_board_info zoom_dss_data = {
.default_device = &zoom_lcd_device,
};
+static void __init zoom_lcd_panel_init(void)
+{
+ zoom_lcd_data.res_gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
+ LCD_PANEL_RESET_GPIO_PROD :
+ LCD_PANEL_RESET_GPIO_PILOT;
+}
+
static struct omap2_mcspi_device_config dss_lcd_mcspi_config = {
.turbo_mode = 1,
};
--
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 21/33] OMAPDSS: tpo-td043 panel: handle gpios in panel driver
The tpo-td043mtea1 panel driver leaves gpio configurations to the
platform_enable and disable calls in the platform's board file. These should
happen in the panel driver itself.
Create a platform data struct for the panel, this contains the reset gpio
number used by the panel driver, this struct will be passed to the panel driver
as platform data. The driver will request and configure the reset gpio rather
than leaving it to platform callbacks in board files.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja
---
.../video/omap2/displays/panel-tpo-td043mtea1.c| 36
include/video/omap-panel-data.h|8 +
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 6b66439..c8244bc 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#define TPO_R02_MODE(x)((x) & 7)
#define TPO_R02_MODE_800x480 7
@@ -275,9 +276,14 @@ static const struct omap_video_timings tpo_td043_timings =
{
.sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
};
+static inline struct panel_tpo_td043_data
+*get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct panel_tpo_td043_data *) dssdev->data;
+}
+
static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
{
- int nreset_gpio = tpo_td043->nreset_gpio;
int r;
if (tpo_td043->powered_on)
@@ -290,8 +296,8 @@ static int tpo_td043_power_on(struct tpo_td043_device
*tpo_td043)
/* wait for panel to stabilize */
msleep(160);
- if (gpio_is_valid(nreset_gpio))
- gpio_set_value(nreset_gpio, 1);
+ if (gpio_is_valid(tpo_td043->nreset_gpio))
+ gpio_set_value(tpo_td043->nreset_gpio, 1);
tpo_td043_write(tpo_td043->spi, 2,
TPO_R02_MODE(tpo_td043->mode) | TPO_R02_NCLK_RISING);
@@ -308,16 +314,14 @@ static int tpo_td043_power_on(struct tpo_td043_device
*tpo_td043)
static void tpo_td043_power_off(struct tpo_td043_device *tpo_td043)
{
- int nreset_gpio = tpo_td043->nreset_gpio;
-
if (!tpo_td043->powered_on)
return;
tpo_td043_write(tpo_td043->spi, 3,
TPO_R03_VAL_STANDBY | TPO_R03_EN_PWM);
- if (gpio_is_valid(nreset_gpio))
- gpio_set_value(nreset_gpio, 0);
+ if (gpio_is_valid(tpo_td043->nreset_gpio))
+ gpio_set_value(tpo_td043->nreset_gpio, 0);
/* wait for at least 2 vsyncs before cutting off power */
msleep(50);
@@ -404,7 +408,7 @@ static void tpo_td043_disable(struct omap_dss_device
*dssdev)
static int tpo_td043_probe(struct omap_dss_device *dssdev)
{
struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
+ struct panel_tpo_td043_data *pdata = get_panel_data(dssdev);
int ret = 0;
dev_dbg(&dssdev->dev, "probe\n");
@@ -414,6 +418,11 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
return -ENODEV;
}
+ if (!pdata)
+ return -EINVAL;
+
+ tpo_td043->nreset_gpio = pdata->nreset_gpio;
+
dssdev->panel.timings = tpo_td043_timings;
dssdev->ctrl.pixel_size = 24;
@@ -427,9 +436,10 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
goto fail_regulator;
}
- if (gpio_is_valid(nreset_gpio)) {
- ret = gpio_request_one(nreset_gpio, GPIOF_OUT_INIT_LOW,
- "lcd reset");
+ if (gpio_is_valid(tpo_td043->nreset_gpio)) {
+ ret = devm_gpio_request_one(&dssdev->dev,
+ tpo_td043->nreset_gpio, GPIOF_OUT_INIT_LOW,
+ "lcd reset");
if (ret < 0) {
dev_err(&dssdev->dev, "couldn't request reset GPIO\n");
goto fail_gpio_req;
@@ -452,14 +462,11 @@ fail_regulator:
static void tpo_td043_remove(struct omap_dss_device *dssdev)
{
struct tpo_td043_device *tpo_td043 = dev_get_drvdata(&dssdev->dev);
- int nreset_gpio = dssdev->reset_gpio;
dev_dbg(&dssdev->dev, "remove\n");
sysfs_remove_group(&dssdev->dev.kobj, &tpo_td043_attr_group);
regulator_put(tpo_td043->vcc_reg);
- if (gpio_is_valid(nreset_gpio))
- gpio_free(nreset_gpio);
}
static void tpo_td043_set_timings(struct omap_dss_device *dssdev,
@@ -519,7 +526,6 @@ static int tpo_td043_spi_probe(struct spi_device *spi)
return -ENOMEM;
tpo_td043->spi = spi;
- tpo_td043->nreset_gpio = dssdev->reset_gpio;
dev_set_drvdata(&spi-
[PATCH 22/33] arm: omap: board-omap3pandora: use tpo panel's gpio handling
The omap3pandora board file currently passes the reset gpio number to the
tpo-td043mtea1 panel driver via the reset_gpio field in omap_dss_device.
Platform related information should be passed via the panel driver's platform
data struct.
Add the reset gpio information to panel_tpo_td043_data so that it's passed to
the panel driver.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-omap3pandora.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index a53a668..ddd6322 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -43,6 +43,7 @@
#include "common.h"
#include
+#include
#include
#include "mux.h"
@@ -229,12 +230,16 @@ static struct twl4030_keypad_data pandora_kp_data = {
.rep= 1,
};
+static struct panel_tpo_td043_data lcd_data = {
+ .nreset_gpio= 157,
+};
+
static struct omap_dss_device pandora_lcd_device = {
.name = "lcd",
.driver_name= "tpo_td043mtea1_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
- .reset_gpio = 157,
+ .data = &lcd_data,
};
static struct omap_dss_device pandora_tv_device = {
--
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 23/33] OMAPDSS: tpo-td043: remove platform_enable/disable callbacks
The tpo-td043 panel driver now manages the gpios required to configure the
panel.
This was previously done in omap_dss_device's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_tpo_td043_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the platform_enable/disable
ops can be safely removed now.
Signed-off-by: Archit Taneja
---
.../video/omap2/displays/panel-tpo-td043mtea1.c|9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index c8244bc..24bb0ff 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -348,12 +348,6 @@ static int tpo_td043_enable_dss(struct omap_dss_device
*dssdev)
if (r)
goto err0;
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
/*
* If we are resuming from system suspend, SPI clocks might not be
* enabled yet, so we'll program the LCD from SPI PM resume callback.
@@ -380,9 +374,6 @@ static void tpo_td043_disable_dss(struct omap_dss_device
*dssdev)
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
omapdss_dpi_display_disable(dssdev);
if (!tpo_td043->spi_suspended)
--
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 24/33] OMAPDSS: picodlp panel: handle gpio data in panel driver
The picodlp panel driver leaves gpio requests to the platform's board file.
These should happen in the panel driver itself.
A platform data struct called picodlp_panel_data already exists to hold gpio
numbers and other platform data. Request all the gpios in the panel driver so
that the board files which use the the panel don't need to do it.
This will help in removing the need for the panel drivers to have platform
related callbacks.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-picodlp.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
index 56d536c..bc8ac77 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -423,10 +423,13 @@ static int picodlp_panel_probe(struct omap_dss_device
*dssdev)
struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
struct i2c_adapter *adapter;
struct i2c_client *picodlp_i2c_client;
- int picodlp_adapter_id;
+ int r, picodlp_adapter_id;
dssdev->panel.timings = pico_ls_timings;
+ if (!picodlp_pdata)
+ return -EINVAL;
+
picod = devm_kzalloc(&dssdev->dev, sizeof(*picod), GFP_KERNEL);
if (!picod)
return -ENOMEM;
@@ -452,6 +455,22 @@ static int picodlp_panel_probe(struct omap_dss_device
*dssdev)
dev_set_drvdata(&dssdev->dev, picod);
+ if (gpio_is_valid(picodlp_pdata->emu_done_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev,
+ picodlp_pdata->emu_done_gpio,
+ GPIOF_IN, "DLP EMU DONE");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(picodlp_pdata->pwrgood_gpio)) {
+ r = devm_gpio_request_one(&dssdev->dev,
+ picodlp_pdata->pwrgood_gpio,
+ GPIOF_OUT_INIT_LOW, "DLP PWRGOOD");
+ if (r)
+ return r;
+ }
+
return 0;
}
--
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 25/33] arm: omap: dss-common: use picodlp panel's gpio handling
The dss-common file currently requests gpios required by the picodlp DPI
panel on the 4430sdp/blaze board. It also requests DISPLAY_SEL_GPIO and
DLP_POWER_ON_GPIO gpios which are board specific gpios to switch between lcd2
panel and picodlp, and setting intermediate power supplies for picodlp
respectively. These gpios are toggled through platform_enable/disable functions
called by the picodlp driver.
Remove the gpio requests for the gpios which are already requested by the panel
driver, and remove the platform callback functions and set the platform specific
gpios in such a way that lcd2 panel is selected for the LCD2 overlay manager and
the power supplies for picodlp are disabled.
Note: We need to revisit this so that we can enable and switch to picodlp if
that's the only panel driver available for the LCD2 overlay manager.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/dss-common.c | 53 --
1 file changed, 16 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 9c49bbe..b073e8b 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -177,45 +177,12 @@ static struct picodlp_panel_data sdp4430_picodlp_pdata = {
.pwrgood_gpio = 45,
};
-static void sdp4430_picodlp_init(void)
-{
- int r;
- const struct gpio picodlp_gpios[] = {
- {DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON"},
- {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
- "DLP EMU DONE"},
- {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
- "DLP PWRGOOD"},
- };
-
- r = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
- if (r)
- pr_err("Cannot request PicoDLP GPIOs, error %d\n", r);
-}
-
-static int sdp4430_panel_enable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DISPLAY_SEL_GPIO, 0);
- gpio_set_value(DLP_POWER_ON_GPIO, 1);
-
- return 0;
-}
-
-static void sdp4430_panel_disable_picodlp(struct omap_dss_device *dssdev)
-{
- gpio_set_value(DLP_POWER_ON_GPIO, 0);
- gpio_set_value(DISPLAY_SEL_GPIO, 1);
-}
-
static struct omap_dss_device sdp4430_picodlp_device = {
.name = "picodlp",
.driver_name= "picodlp_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
.channel= OMAP_DSS_CHANNEL_LCD2,
- .platform_enable= sdp4430_panel_enable_picodlp,
- .platform_disable = sdp4430_panel_disable_picodlp,
.data = &sdp4430_picodlp_pdata,
};
@@ -232,17 +199,26 @@ static struct omap_dss_board_info sdp4430_dss_data = {
.default_device = &sdp4430_lcd_device,
};
+/*
+ * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
+ * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
+ * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
+ * selected by default
+ */
void __init omap_4430sdp_display_init(void)
{
int r;
- /* Enable LCD2 by default (instead of Pico DLP) */
r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
"display_sel");
if (r)
pr_err("%s: Could not get display_sel GPIO\n", __func__);
- sdp4430_picodlp_init();
+ r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ "DLP POWER ON");
+ if (r)
+ pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
+
omap_display_init(&sdp4430_dss_data);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -262,12 +238,15 @@ void __init omap_4430sdp_display_init_of(void)
{
int r;
- /* Enable LCD2 by default (instead of Pico DLP) */
r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
"display_sel");
if (r)
pr_err("%s: Could not get display_sel GPIO\n", __func__);
- sdp4430_picodlp_init();
+ r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ "DLP POWER ON");
+ if (r)
+ pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
+
omap_display_init(&sdp4430_dss_data);
}
--
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 26/33] OMAPDSS: picodlp panel: remove platform_enable/disable callbacks
The picodlp panel driver now manages the gpios required to configure the
panel. This was previously done in omap_dss_device's platform_enable/disable
callbacks defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_generic_dpi_data struct, which is needed by the panel driver
to configure the gpios connected to the panel. Hence, the
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-picodlp.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
index bc8ac77..62f2db0 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -354,12 +354,6 @@ static int picodlp_panel_power_on(struct omap_dss_device
*dssdev)
struct picodlp_data *picod = dev_get_drvdata(&dssdev->dev);
struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
- if (dssdev->platform_enable) {
- r = dssdev->platform_enable(dssdev);
- if (r)
- return r;
- }
-
gpio_set_value(picodlp_pdata->pwrgood_gpio, 0);
msleep(1);
gpio_set_value(picodlp_pdata->pwrgood_gpio, 1);
@@ -398,9 +392,6 @@ static int picodlp_panel_power_on(struct omap_dss_device
*dssdev)
err:
omapdss_dpi_display_disable(dssdev);
err1:
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
-
return r;
}
@@ -412,9 +403,6 @@ static void picodlp_panel_power_off(struct omap_dss_device
*dssdev)
gpio_set_value(picodlp_pdata->emu_done_gpio, 0);
gpio_set_value(picodlp_pdata->pwrgood_gpio, 0);
-
- if (dssdev->platform_disable)
- dssdev->platform_disable(dssdev);
}
static int picodlp_panel_probe(struct omap_dss_device *dssdev)
--
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 13/33] arm: omap: board-omap3evm: use sharp panel's gpio handling
The omap3evm board file currently requests gpios required by the sharp_ls dpi
panel, and provides platform_enable/disable callbacks to configure them.
These tasks have been moved to the sharp_ls panel driver itself and shouldn't
be done in the board files.
Remove the gpio requests and the platform callbacks from the board file.
Add the gpio information to panel_sharp_ls037v7dw01_data so that it's passed
to the panel driver.
Note: The GPIOs OMAP3EVM_LCD_PANEL_ENVDD and OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO
aren't directly connected to the sharp panel, hence they aren't passed to the
panel driver as platform data. These are set to a default value such that LCD
is enabled and backlight is on. These used to previously toggle through the
platform_enable/disable callbacks, but now these are always on. This needs to
be revisited.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-omap3evm.c | 59 --
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 335127d..dfb5e1b 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -154,61 +154,43 @@ static inline void __init omap3evm_init_smsc911x(void) {
return; }
#define OMAP3EVM_LCD_PANEL_LR 2
#define OMAP3EVM_LCD_PANEL_UD 3
#define OMAP3EVM_LCD_PANEL_INI 152
-#define OMAP3EVM_LCD_PANEL_ENVDD 153
#define OMAP3EVM_LCD_PANEL_QVGA154
#define OMAP3EVM_LCD_PANEL_RESB155
+
+#define OMAP3EVM_LCD_PANEL_ENVDD 153
#define OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO210
+
+/*
+ * OMAP3EVM DVI control signals
+ */
#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
-static struct gpio omap3_evm_dss_gpios[] __initdata = {
- { OMAP3EVM_LCD_PANEL_RESB, GPIOF_OUT_INIT_HIGH, "lcd_panel_resb" },
- { OMAP3EVM_LCD_PANEL_INI, GPIOF_OUT_INIT_HIGH, "lcd_panel_ini" },
- { OMAP3EVM_LCD_PANEL_QVGA, GPIOF_OUT_INIT_LOW, "lcd_panel_qvga" },
- { OMAP3EVM_LCD_PANEL_LR,GPIOF_OUT_INIT_HIGH, "lcd_panel_lr"},
- { OMAP3EVM_LCD_PANEL_UD,GPIOF_OUT_INIT_HIGH, "lcd_panel_ud"},
- { OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW, "lcd_panel_envdd" },
+static struct panel_sharp_ls037v7dw01_data omap3_evm_lcd_data = {
+ .resb_gpio = OMAP3EVM_LCD_PANEL_RESB,
+ .ini_gpio = OMAP3EVM_LCD_PANEL_INI,
+ .mo_gpio = OMAP3EVM_LCD_PANEL_QVGA,
+ .lr_gpio = OMAP3EVM_LCD_PANEL_LR,
+ .ud_gpio = OMAP3EVM_LCD_PANEL_UD,
};
-static int lcd_enabled;
-static int dvi_enabled;
-
static void __init omap3_evm_display_init(void)
{
int r;
- r = gpio_request_array(omap3_evm_dss_gpios,
- ARRAY_SIZE(omap3_evm_dss_gpios));
+ r = gpio_request_one(OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW,
+ "lcd_panel_envdd");
if (r)
- printk(KERN_ERR "failed to get lcd_panel_* gpios\n");
-}
+ pr_err("failed to get lcd_panel_envdd GPIO\n");
-static int omap3_evm_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
- gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
+ r = gpio_request_one(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO,
+ GPIOF_OUT_INIT_LOW, "lcd_panel_bklight");
+ if (r)
+ pr_err("failed to get lcd_panel_bklight GPIO\n");
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
-
- lcd_enabled = 1;
- return 0;
-}
-
-static void omap3_evm_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 1);
-
- if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
- gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
- else
- gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
-
- lcd_enabled = 0;
}
static struct omap_dss_device omap3_evm_lcd_device = {
@@ -216,8 +198,7 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.driver_name= "sharp_ls_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 18,
- .platform_enable= omap3_evm_enable_lcd,
- .platform_disable = omap3_evm_disable_lcd,
+ .data = &omap3_evm_lcd_data,
};
static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
--
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 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
The n8x0 panel driver leaves gpio configurations to the platform_enable and
disable calls in the platform's board file. These should happen in the panel
driver itself.
A platform data struct called panel_n8x0_data already exists to hold gpio
numbers and other platform data. However, the gpio requests are expected to be
done in the board file and not the panel driver.
Request all the gpios in the panel driver so that the board files which use
the the panel don't need to do it. This will help in removing the need for the
panel drivers to have platform related callbacks.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-n8x0.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c
b/drivers/video/omap2/displays/panel-n8x0.c
index 9c55c91..c146a3d 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -426,6 +426,7 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
{
struct panel_n8x0_data *bdata = get_board_data(dssdev);
struct panel_drv_data *ddata;
+ int r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
+ if (gpio_is_valid(bdata->panel_reset)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
+ GPIOF_OUT_INIT_LOW, "PANEL RESET");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(bdata->ctrl_pwrdown)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
+ GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
+ if (r)
+ return r;
+ }
+
return 0;
}
--
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 28/33] OMAPDSS: n8x0 panel: remove platform_enable/disable callbacks
The n8x0 panel driver now manages the gpios required to configure the panel.
This was previously done in panel_n8x0_data's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_n8x0_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the platform_enable/disable
ops can be safely removed now.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-n8x0.c | 12
include/video/omap-panel-data.h |2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-n8x0.c
b/drivers/video/omap2/displays/panel-n8x0.c
index c146a3d..f94ead6 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -295,12 +295,6 @@ static int n8x0_panel_power_on(struct omap_dss_device
*dssdev)
gpio_direction_output(bdata->ctrl_pwrdown, 1);
- if (bdata->platform_enable) {
- r = bdata->platform_enable(dssdev);
- if (r)
- goto err_plat_en;
- }
-
omapdss_rfbi_set_size(dssdev, dssdev->panel.timings.x_res,
dssdev->panel.timings.y_res);
omapdss_rfbi_set_pixel_size(dssdev, dssdev->ctrl.pixel_size);
@@ -373,9 +367,6 @@ err_inv_panel:
err_inv_chip:
omapdss_rfbi_display_disable(dssdev);
err_rfbi_en:
- if (bdata->platform_disable)
- bdata->platform_disable(dssdev);
-err_plat_en:
gpio_direction_output(bdata->ctrl_pwrdown, 0);
return r;
}
@@ -392,9 +383,6 @@ static void n8x0_panel_power_off(struct omap_dss_device
*dssdev)
send_display_off(spi);
send_sleep_in(spi);
- if (bdata->platform_disable)
- bdata->platform_disable(dssdev);
-
/*
* HACK: we should turn off the panel here, but there is some problem
* with the initialization sequence, and we fail to init the panel if we
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 7cac89e..84f332e 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -48,8 +48,6 @@ struct panel_generic_dpi_data {
* struct panel_n8x0_data - N800 panel driver configuration data
*/
struct panel_n8x0_data {
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
int panel_reset;
int ctrl_pwrdown;
};
--
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 29/33] arm: omap boards: Remove unnecessary platform_enable/disable callbacks for VENC devices
The omap_dss_device's platform_enable/disable callbacks don't do anything for
any of the boards. The platform calls from the VENC driver will also be removed
in the future. Remove these calls from the board which have a VENC device.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/board-3430sdp.c | 11 ---
arch/arm/mach-omap2/board-am3517evm.c| 11 ---
arch/arm/mach-omap2/board-cm-t35.c | 11 ---
arch/arm/mach-omap2/board-omap3evm.c | 11 ---
arch/arm/mach-omap2/board-omap3stalker.c | 11 ---
5 files changed, 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 13f1431..717dd15 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -124,15 +124,6 @@ static void __init sdp3430_display_init(void)
}
-static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct panel_sharp_ls037v7dw01_data sdp3430_lcd_data = {
.resb_gpio = SDP3430_LCD_PANEL_ENABLE_GPIO,
.ini_gpio = -1,
@@ -167,8 +158,6 @@ static struct omap_dss_device sdp3430_tv_device = {
.driver_name= "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable= sdp3430_panel_enable_tv,
- .platform_disable = sdp3430_panel_disable_tv,
};
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index eb245a6..edb4cce 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -138,22 +138,11 @@ static struct omap_dss_device am3517_evm_lcd_device = {
.phy.dpi.data_lines = 16,
};
-static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void am3517_evm_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device am3517_evm_tv_device = {
.type = OMAP_DISPLAY_TYPE_VENC,
.name = "tv",
.driver_name= "venc",
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable= am3517_evm_panel_enable_tv,
- .platform_disable = am3517_evm_panel_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 563d5ab..cb3b078 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -189,15 +189,6 @@ static inline void cm_t35_init_nand(void) {}
#define CM_T35_LCD_BL_GPIO 58
#define CM_T35_DVI_EN_GPIO 54
-static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct panel_generic_dpi_data lcd_panel = {
.name = "toppoly_tdo35s",
.num_gpios = 2,
@@ -233,8 +224,6 @@ static struct omap_dss_device cm_t35_tv_device = {
.driver_name= "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable= cm_t35_panel_enable_tv,
- .platform_disable = cm_t35_panel_disable_tv,
};
static struct omap_dss_device *cm_t35_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index dfb5e1b..a471476 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -201,22 +201,11 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.data = &omap3_evm_lcd_data,
};
-static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_evm_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static struct omap_dss_device omap3_evm_tv_device = {
.name = "tv",
.driver_name= "venc",
.type = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
- .platform_enable= omap3_evm_enable_tv,
- .platform_disable = omap3_evm_disable_tv,
};
static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 621ace1..8f1b0a1 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -93,15 +93,6 @@ static void __init omap3_stalker_display_init(void)
return;
}
-static int omap3_stalker_enable_tv(struct omap_dss_device *dssdev)
-{
- return 0;
-}
-
-static void omap3_stalker_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
static
[PATCH 30/33] OMAPDSS: VENC: remove platform_enable/disable calls
The platform_enable/disable callbacks in board files for VENC omap_dss_device instances don't do anything. Hence, we can remove these callbacks from the VENC driver. Signed-off-by: Archit Taneja --- drivers/video/omap2/dss/venc.c |9 - 1 file changed, 9 deletions(-) diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c index 006caf3..1598d27 100644 --- a/drivers/video/omap2/dss/venc.c +++ b/drivers/video/omap2/dss/venc.c @@ -519,10 +519,6 @@ int omapdss_venc_display_enable(struct omap_dss_device *dssdev) goto err0; } - if (dssdev->platform_enable) - dssdev->platform_enable(dssdev); - - r = venc_power_on(dssdev); if (r) goto err1; @@ -533,8 +529,6 @@ int omapdss_venc_display_enable(struct omap_dss_device *dssdev) return 0; err1: - if (dssdev->platform_disable) - dssdev->platform_disable(dssdev); omap_dss_stop_device(dssdev); err0: mutex_unlock(&venc.venc_lock); @@ -551,9 +545,6 @@ void omapdss_venc_display_disable(struct omap_dss_device *dssdev) omap_dss_stop_device(dssdev); - if (dssdev->platform_disable) - dssdev->platform_disable(dssdev); - mutex_unlock(&venc.venc_lock); } -- 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 31/33] OMAPDSS: remove platform_enable/disable callbacks from omap_dss_device
None of the omapdss panel drivers call platform_enable/disable callbacks, and
none of the omap board files define these callbacks for any omap_dss_device.
Hence these callbacks can be removed form the omap_dss_device struct.
Signed-off-by: Archit Taneja
---
include/video/omapdss.h |4
1 file changed, 4 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index f0b65a5..e1ebb48 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -650,10 +650,6 @@ struct omap_dss_device {
enum omap_dss_display_state state;
enum omap_dss_audio_state audio_state;
-
- /* platform specific */
- int (*platform_enable)(struct omap_dss_device *dssdev);
- void (*platform_disable)(struct omap_dss_device *dssdev);
};
struct omap_dss_hdmi_data
--
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 32/33] arm: dss-common: don't use reset_gpio from omap4_panda_dvi_device
gpio reset info is passed to the tfp410 panel driver via the panel's platform
data struct 'tfp410_platform_data'. The tfp driver doesn't use the reset_gpio
field in the omap4_panda_dvi_device struct. Remove this field.
Cc: Tony Lindgren
Signed-off-by: Archit Taneja
---
arch/arm/mach-omap2/dss-common.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index b073e8b..393aeef 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -52,7 +52,6 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.driver_name= "tfp410",
.data = &omap4_dvi_panel,
.phy.dpi.data_lines = 24,
- .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
.channel= OMAP_DSS_CHANNEL_LCD2,
};
--
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 33/33] OMAPDSS: remove reset_gpio field from omap_dss_device
The reset_gpio field isn't used by any panel driver to retrieve a reset gpio
number. All the panel drivers receive gpio data from their corresponding
platform_data structs. Remove the reset_gpio field.
Signed-off-by: Archit Taneja
---
include/video/omapdss.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index e1ebb48..fe8672c 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -629,8 +629,6 @@ struct omap_dss_device {
struct rfbi_timings rfbi_timings;
} ctrl;
- int reset_gpio;
-
const char *name;
/* used to match device to driver */
--
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: [RFC 1/1] ARM: omap2: gpmc: Move binding documentation to memory-controller
On 02/13/2013 05:13 AM, Ezequiel Garcia wrote:
> GPMC stands for General Purpose Memory Controller, and it's primarily
> used to handle memories such as NOR, NAND, SRAM.
> Note that this controller is also used to handle network controllers
> such as smsc911x.
>
> This patch moves the documentation binding to memory-controllers,
> where it belongs.
>
> Signed-off-by: Ezequiel Garcia
> ---
> .../ti-gpmc.txt => memory-controllers/ti/gpmc.txt} |0
> 1 files changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt =>
> memory-controllers/ti/gpmc.txt} (100%)
>
> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> b/Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/bus/ti-gpmc.txt
> rename to Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
I am fine with that. However, make sure you CC the device-tree mailing list.
Cheers
Jon
--
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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
> The cm-t35 board file currently requests gpios required to configure the
> tdo35s
> panel, and provides platform_enable/disable callbacks to configure them.
>
> These tasks have been moved to the generic dpi panel driver itself and
> shouldn't
> be done in the board files.
>
> Remove the gpio requests and the platform callbacks from the board file.
> Add the gpio information to generic dpi panel's platform data so that it's
> passed to the panel driver.
>
> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio
> was
> enabled after a 50 millisecond delay. This code has been removed and is not
> taken care of in the generic panel driver. The impact of this needs to be
> tested. The panel's gpios are also not exported any more. Hence, they can't be
> accessed via sysfs interface.
Indeed, there is an impact - the LCD no longer works.
The reason for the LCD_EN gpio being pushed high after the 50ms delay,
is to get the LCD out of reset, so the SPI transaction will succeed
and initialize the LCD.
Now, when you remove the gpio handling for the LCD_EN pin,
the LCD no longer works.
I don't agree with this breakage.
>
> Cc: Tony Lindgren
> Signed-off-by: Archit Taneja
> ---
> arch/arm/mach-omap2/board-cm-t35.c | 46
>
> 1 file changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
> b/arch/arm/mach-omap2/board-cm-t35.c
> index f940a79..563d5ab 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -189,32 +189,6 @@ static inline void cm_t35_init_nand(void) {}
> #define CM_T35_LCD_BL_GPIO 58
> #define CM_T35_DVI_EN_GPIO 54
>
> -static int lcd_enabled;
> -static int dvi_enabled;
> -
> -static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
> -{
> - if (dvi_enabled) {
> - printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> - return -EINVAL;
> - }
> -
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
> -
> - lcd_enabled = 1;
> -
> - return 0;
> -}
> -
> -static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
> -{
> - lcd_enabled = 0;
> -
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
> -}
> -
> static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
> {
> return 0;
> @@ -226,8 +200,11 @@ static void cm_t35_panel_disable_tv(struct
> omap_dss_device *dssdev)
>
> static struct panel_generic_dpi_data lcd_panel = {
> .name = "toppoly_tdo35s",
> - .platform_enable= cm_t35_panel_enable_lcd,
> - .platform_disable = cm_t35_panel_disable_lcd,
> + .num_gpios = 2,
> + .gpios = {
> + CM_T35_LCD_BL_GPIO,
> + CM_T35_LCD_EN_GPIO
> + },
> };
>
> static struct omap_dss_device cm_t35_lcd_device = {
> @@ -303,19 +280,6 @@ static void __init cm_t35_init_display(void)
> spi_register_board_info(cm_t35_lcd_spi_board_info,
> ARRAY_SIZE(cm_t35_lcd_spi_board_info));
>
> - err = gpio_request_array(cm_t35_dss_gpios,
> - ARRAY_SIZE(cm_t35_dss_gpios));
> - if (err) {
> - pr_err("CM-T35: failed to request DSS control GPIOs\n");
> - return;
> - }
> -
> - gpio_export(CM_T35_LCD_EN_GPIO, 0);
> - gpio_export(CM_T35_LCD_BL_GPIO, 0);
> -
> - msleep(50);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> -
> err = omap_display_init(&cm_t35_dss_data);
> if (err) {
> pr_err("CM-T35: failed to register DSS device\n");
>
--
Regards,
Igor.
--
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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
On 2013-02-13 17:16, Igor Grinberg wrote: > Hi Archit, > > On 02/13/13 16:21, Archit Taneja wrote: >> The cm-t35 board file currently requests gpios required to configure the >> tdo35s >> panel, and provides platform_enable/disable callbacks to configure them. >> >> These tasks have been moved to the generic dpi panel driver itself and >> shouldn't >> be done in the board files. >> >> Remove the gpio requests and the platform callbacks from the board file. >> Add the gpio information to generic dpi panel's platform data so that it's >> passed to the panel driver. >> >> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio >> was >> enabled after a 50 millisecond delay. This code has been removed and is not >> taken care of in the generic panel driver. The impact of this needs to be >> tested. The panel's gpios are also not exported any more. Hence, they can't >> be >> accessed via sysfs interface. > > Indeed, there is an impact - the LCD no longer works. > The reason for the LCD_EN gpio being pushed high after the 50ms delay, > is to get the LCD out of reset, so the SPI transaction will succeed > and initialize the LCD. > Now, when you remove the gpio handling for the LCD_EN pin, > the LCD no longer works. So between what is the sleep done? It's not clear from the code. LCD_EN needs to be 0 for 50ms, or...? If the panel requires specific reset handling, does it work right even currently when the panel is turned off and later turned on? The msleep is only used at boot time. Tomi signature.asc Description: OpenPGP digital signature
Re: Use of of_parse_phandle()/of_node_put()
On 02/13/2013 07:04 AM, Kumar, Anil wrote:
> Hi Peter,
>
> Just trying to understand.
>
> In omap-twl4030.c file probe function :-
>
> dai_node = of_parse_phandle(node, "ti,mcbsp", 0);
> if (!dai_node) {
> dev_err(&pdev->dev, "McBSP node is not provided\n");
> return -EINVAL;
> }
>
> Here “of_parse_phandle()” is used to get “of_device” node pointer.
> of_parse_phandle() suggest to use of_node_put() on it when done.
>
> It looks when code request for an “of_device” node, kernel maintains
> “refcount” for this.
> It check “refcount” before giving pointer of of_device node and WARN_ON()
> in case of refcount > 0 and increase it on success.
>
> Should this code need to use of_node_put() on the requested “of_device” when
> done
> so that this can be get again ?
Hrm, one thing or sure we should not call it of_node_put() while we have the
card loaded since the node is used runtime by the core.
However when we unload the machine driver it might be needed, but not sure
about this. None of the existing machine drivers doing it (tegra, samsung,
omap, etc).
But if it is needed it might be better to be done by the core?
>
> I am taking reference of Linux-next kernel.
>
> I'm sorry if this question is very vague or missing something.
>
> Thanks,
> Anil
>
>
>
>
>
>
--
Péter
--
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 3/5] arm: dts: omap4-panda: Add I2c pinctrl data
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
> Booting 3.8-rc6 on omap4 panda results in the following error
>
> [0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
> [0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
> [0.473937] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
> [0.474670] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz
> [0.474822] omap_i2c 4806.i2c: did not get pins for i2c error: -19
> [0.476379] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz
> [0.477294] omap_i2c 4835.i2c: did not get pins for i2c error: -19
> [0.477996] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz
> [0.483398] Switching to clocksource 32k_counter
>
> This happens because omap4 panda dts file is not adapted to use i2c through
> pinctrl framework. Populating i2c pinctrl data to get rid of the error.
What about the panda-es and panda-a4?
> Tested on omap4460 panda with 3.8-rc6 kernel.
>
> Signed-off-by: Sourav Poddar
> Reported-by: Luciano Coelho
> ---
> arch/arm/boot/dts/omap4-panda.dts | 40
> +
> 1 files changed, 40 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda.dts
> b/arch/arm/boot/dts/omap4-panda.dts
> index 4122efe..f951e6b 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -110,9 +110,40 @@
> 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
> MODE3 */
> >;
> };
> +
> + i2c1_pins: pinmux_i2c1_pins {
> + pinctrl-single,pins = <
> + 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
> MODE0 */
> + 0xe4 0x118/* i2c1_sda PULLUP | INPUTENABLE |
> MODE0 */
> + >;
> + };
> +
> + i2c2_pins: pinmux_i2c2_pins {
> + pinctrl-single,pins = <
> + 0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
> MODE0 */
> + 0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
> MODE0 */
> + >;
> + };
> +
> + i2c3_pins: pinmux_i2c3_pins {
> + pinctrl-single,pins = <
> + 0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
> MODE0 */
> + 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
> */
> + >;
> + };
> +
> + i2c4_pins: pinmux_i2c4_pins {
> + pinctrl-single,pins = <
> + 0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
> MODE0 */
> + 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
> */
> + >;
> + };
> };
A quick look at the data manual shows that omap4430 and omap4460 has the
same pin mux options for i2c. Furthermore, the data manual shows only
one mux option for i2c1-4. Therefore, should these mux options be placed
in omap4.dtsi? Boards not using specific i2c controllers can disabled
them in there board dts file (same way we do for mmc).
Cheers
Jon
--
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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
On 2013-02-13 17:28, Tomi Valkeinen wrote: > On 2013-02-13 17:16, Igor Grinberg wrote: >> Hi Archit, >> >> On 02/13/13 16:21, Archit Taneja wrote: >>> The cm-t35 board file currently requests gpios required to configure the >>> tdo35s >>> panel, and provides platform_enable/disable callbacks to configure them. >>> >>> These tasks have been moved to the generic dpi panel driver itself and >>> shouldn't >>> be done in the board files. >>> >>> Remove the gpio requests and the platform callbacks from the board file. >>> Add the gpio information to generic dpi panel's platform data so that it's >>> passed to the panel driver. >>> >>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN >>> gpio was >>> enabled after a 50 millisecond delay. This code has been removed and is not >>> taken care of in the generic panel driver. The impact of this needs to be >>> tested. The panel's gpios are also not exported any more. Hence, they can't >>> be >>> accessed via sysfs interface. >> >> Indeed, there is an impact - the LCD no longer works. >> The reason for the LCD_EN gpio being pushed high after the 50ms delay, >> is to get the LCD out of reset, so the SPI transaction will succeed >> and initialize the LCD. >> Now, when you remove the gpio handling for the LCD_EN pin, >> the LCD no longer works. > > So between what is the sleep done? It's not clear from the code. LCD_EN > needs to be 0 for 50ms, or...? > > If the panel requires specific reset handling, does it work right even > currently when the panel is turned off and later turned on? The msleep > is only used at boot time. Okay, so I just realized there's an spi backlight driver used here, and that backlight driver is actually handling the SPI transactions with the panel, instead of the panel driver. So this looks quite messed up. For a quick solution, can we just set the LCD_EN at boot time (with the msleep), and not touch it after that? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/5] arm: dts: omap4-panda: Add I2c pinctrl data
On 02/13/2013 09:57 AM, Jon Hunter wrote:
>
> On 02/13/2013 03:28 AM, Sourav Poddar wrote:
>> Booting 3.8-rc6 on omap4 panda results in the following error
>>
>> [0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
>> [0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
>> [0.473937] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
>> [0.474670] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz
>> [0.474822] omap_i2c 4806.i2c: did not get pins for i2c error: -19
>> [0.476379] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz
>> [0.477294] omap_i2c 4835.i2c: did not get pins for i2c error: -19
>> [0.477996] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz
>> [0.483398] Switching to clocksource 32k_counter
>>
>> This happens because omap4 panda dts file is not adapted to use i2c through
>> pinctrl framework. Populating i2c pinctrl data to get rid of the error.
>
> What about the panda-es and panda-a4?
>
>> Tested on omap4460 panda with 3.8-rc6 kernel.
>>
>> Signed-off-by: Sourav Poddar
>> Reported-by: Luciano Coelho
>> ---
>> arch/arm/boot/dts/omap4-panda.dts | 40
>> +
>> 1 files changed, 40 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4-panda.dts
>> b/arch/arm/boot/dts/omap4-panda.dts
>> index 4122efe..f951e6b 100644
>> --- a/arch/arm/boot/dts/omap4-panda.dts
>> +++ b/arch/arm/boot/dts/omap4-panda.dts
>> @@ -110,9 +110,40 @@
>> 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
>> MODE3 */
>> >;
>> };
>> +
>> +i2c1_pins: pinmux_i2c1_pins {
>> +pinctrl-single,pins = <
>> +0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
>> MODE0 */
>> +0xe4 0x118/* i2c1_sda PULLUP | INPUTENABLE |
>> MODE0 */
>> +>;
>> +};
>> +
>> +i2c2_pins: pinmux_i2c2_pins {
>> +pinctrl-single,pins = <
>> +0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
>> MODE0 */
>> +0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
>> MODE0 */
>> +>;
>> +};
>> +
>> +i2c3_pins: pinmux_i2c3_pins {
>> +pinctrl-single,pins = <
>> +0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
>> MODE0 */
>> +0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
>> */
>> +>;
>> +};
>> +
>> +i2c4_pins: pinmux_i2c4_pins {
>> +pinctrl-single,pins = <
>> +0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
>> MODE0 */
>> +0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
>> */
>> +>;
>> +};
>> };
>
> A quick look at the data manual shows that omap4430 and omap4460 has the
> same pin mux options for i2c. Furthermore, the data manual shows only
> one mux option for i2c1-4. Therefore, should these mux options be placed
> in omap4.dtsi? Boards not using specific i2c controllers can disabled
> them in there board dts file (same way we do for mmc).
I guess for i2c, a given omap4 board may use external pull-ups and not
use the internal ones and so putting this in the omap4.dtsi may not be
desirable. However, it seems that a common omap4-panda.dtsi could be
used here.
Cheers
Jon
--
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 3/5] arm: dts: omap4-panda: Add I2c pinctrl data
* Jon Hunter [130213 08:10]: > On 02/13/2013 09:57 AM, Jon Hunter wrote: > > On 02/13/2013 03:28 AM, Sourav Poddar wrote: > > > > A quick look at the data manual shows that omap4430 and omap4460 has the > > same pin mux options for i2c. Furthermore, the data manual shows only > > one mux option for i2c1-4. Therefore, should these mux options be placed > > in omap4.dtsi? Boards not using specific i2c controllers can disabled > > them in there board dts file (same way we do for mmc). > > I guess for i2c, a given omap4 board may use external pull-ups and not > use the internal ones and so putting this in the omap4.dtsi may not be > desirable. However, it seems that a common omap4-panda.dtsi could be > used here. Yes the mux options need to be board specific. If something is complex and common, it's best to put it into omap4-i2c1.dts file that can be included from the board specific .dts files as needed. 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: Use of of_parse_phandle()/of_node_put()
Hi,
On Wed, Feb 13, 2013 at 9:22 PM, Peter Ujfalusi wrote:
> On 02/13/2013 07:04 AM, Kumar, Anil wrote:
>> Hi Peter,
>>
>> Just trying to understand.
>>
>> In omap-twl4030.c file probe function :-
>>
>> dai_node = of_parse_phandle(node, "ti,mcbsp", 0);
>> if (!dai_node) {
>> dev_err(&pdev->dev, "McBSP node is not provided\n");
>> return -EINVAL;
>> }
>>
>> Here “of_parse_phandle()” is used to get “of_device” node pointer.
>> of_parse_phandle() suggest to use of_node_put() on it when done.
>>
>> It looks when code request for an “of_device” node, kernel maintains
>> “refcount” for this.
>> It check “refcount” before giving pointer of of_device node and WARN_ON()
>> in case of refcount > 0 and increase it on success.
>>
>> Should this code need to use of_node_put() on the requested “of_device” when
>> done
>> so that this can be get again ?
>
> Hrm, one thing or sure we should not call it of_node_put() while we have the
> card loaded since the node is used runtime by the core.
>
> However when we unload the machine driver it might be needed, but not sure
> about this. None of the existing machine drivers doing it (tegra, samsung,
> omap, etc).
> But if it is needed it might be better to be done by the core?
>
It looks issue is different here.
I have done some testing here with patch[1]. In this patch i tried to
get same "of_device" node pointer
again and found refcount for this dt node is 1 [Result].
As of_parse_phandle() says it "returns the device_node pointer with
refcount incremented".
But why refcount value is 1 [Result] again ?
-8-
Patch[1]:-
diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c
index fd98509..0828a5c 100644
--- a/sound/soc/omap/omap-twl4030.c
+++ b/sound/soc/omap/omap-twl4030.c
@@ -297,6 +297,16 @@ static int omap_twl4030_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "McBSP node is not provided\n");
return -EINVAL;
}
+ printk(KERN_ERR"refcount 0x%x",
atomic_read(&dai_node->kref.refcount));
+
+ dai_node = of_parse_phandle(node, "ti,mcbsp", 0);
+if (!dai_node) {
+dev_err(&pdev->dev, "McBSP node is not provided\n");
+return -EINVAL;
+}
+ printk(KERN_ERR"refcount 0x%x",
atomic_read(&dai_node->kref.refcount));
+
+
omap_twl4030_dai_links[0].cpu_dai_name = NULL;
omap_twl4030_dai_links[0].cpu_of_node = dai_node;
[Result]:-
root@DevKit8000:/# insmod snd-soc-omap-twl4030.ko
[ 95.718109] refcount 0x1
[ 95.720611] refcount 0x1 [ 95.818054] omap-twl4030 sound.20:
twl4030-hifi <-> 49022000.mcbsp mapping ok
Thanks,
Anil
[...]
--
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 00/13] drivers: mailbox: framework creation
> On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote: > > On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna wrote: > > > > > I have hosted the series at [3]. > > > [3] > > > https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox > > > > Suman, I suggest you ask Stepgen Rothwell to include this branch into > > the linux-next tree, so we can get some rotation of this stuff in > > preparation for the v3.10 merge window. (It's not going in now > > anyway.) > > Best wait until after v3.9-rc1 - remember that linux-next is supposed to be a > staging tree for the _next_ merge window only. Yes, will do. Anyway, we need a new revision of one patch (so far) to address Mark Rutland's comments. Thanks Suman -- 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 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
* Archit Taneja [130213 06:26]: > init functions in omap board files request panel specific gpios, and provide > functions which omapdss panel drivers call to enable or disable them. > > Instead of the board files requesting these gpios, they should just pass the > platform specific data(like the gpio numbers), the panel should retrieve the > platform data and request the gpios. Doing this prevents the need of the panel > driver calling platform functions in board files. > > Panel drivers have their own platform data struct, and the board files > populate > these structs and pass the pointer to the 'data' field of omap_dss_device. > This > work will make it easier for the panel drivers be more adaptable to the > DT model. > > There is also removal of passing panel reset_gpio numbers through > omap_dss_device struct directly, reset gpios are passed through platform data > only. To avoid merge conflicts and dependencies between drivers and core Soc code, please break thes kind of patches into following parts: 1. Any platform_data header changes needed so both I and Tomi can pull it in as needed. 2. Changes to DSS drivers. Please keep stubs around for the board specific callback functions so omap2plus_defconfig won't break with just #1 merged into arm soc tree. 3. All the arch/arm/*omap* changes based on #1 above to drop obsolete callback functions and add new pdata if still needed. This needs to build and boot on #1 so I can merge this in via arm soc tree. 4. Any .dts changes needed. 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: Use of of_parse_phandle()/of_node_put()
Hi Peter,
On Wed, Feb 13, 2013 at 10:10 PM, Anil Kumar wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 9:22 PM, Peter Ujfalusi wrote:
>> On 02/13/2013 07:04 AM, Kumar, Anil wrote:
>>> Hi Peter,
>>>
>>> Just trying to understand.
>>>
>>> In omap-twl4030.c file probe function :-
>>>
>>> dai_node = of_parse_phandle(node, "ti,mcbsp", 0);
>>> if (!dai_node) {
>>> dev_err(&pdev->dev, "McBSP node is not provided\n");
>>> return -EINVAL;
>>> }
>>>
>>> Here “of_parse_phandle()” is used to get “of_device” node pointer.
>>> of_parse_phandle() suggest to use of_node_put() on it when done.
>>>
>>> It looks when code request for an “of_device” node, kernel maintains
>>> “refcount” for this.
>>> It check “refcount” before giving pointer of of_device node and WARN_ON()
>>> in case of refcount > 0 and increase it on success.
>>>
>>> Should this code need to use of_node_put() on the requested “of_device”
>>> when done
>>> so that this can be get again ?
>>
>> Hrm, one thing or sure we should not call it of_node_put() while we have the
>> card loaded since the node is used runtime by the core.
>>
>> However when we unload the machine driver it might be needed, but not sure
>> about this. None of the existing machine drivers doing it (tegra, samsung,
>> omap, etc).
>> But if it is needed it might be better to be done by the core?
>>
Sorry i forgot to mention.
Yes, I think soc core may have something like[1] to release cpu_of_node.
[1]
8---
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index b7e84a7..9000f4a 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1044,6 +1044,13 @@ static void soc_remove_dai_links(struct
snd_soc_card *card)
soc_remove_link_dais(card, dai, order);
}
+ /* release cpu_of_node */
+ if(card->dai_link) {
+ int i;
+ for(i = 0; i < card->num_links; i++)
+ of_node_put(card->dai_link[i].cpu_of_node);
+ }
+
Thanks,
Anil
>
> It looks issue is different here.
> I have done some testing here with patch[1]. In this patch i tried to
> get same "of_device" node pointer
> again and found refcount for this dt node is 1 [Result].
>
> As of_parse_phandle() says it "returns the device_node pointer with
> refcount incremented".
> But why refcount value is 1 [Result] again ?
>
> -8-
> Patch[1]:-
> diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c
> index fd98509..0828a5c 100644
> --- a/sound/soc/omap/omap-twl4030.c
> +++ b/sound/soc/omap/omap-twl4030.c
> @@ -297,6 +297,16 @@ static int omap_twl4030_probe(struct platform_device
> *pdev)
> dev_err(&pdev->dev, "McBSP node is not provided\n");
> return -EINVAL;
> }
> + printk(KERN_ERR"refcount 0x%x",
> atomic_read(&dai_node->kref.refcount));
> +
> + dai_node = of_parse_phandle(node, "ti,mcbsp", 0);
> +if (!dai_node) {
> +dev_err(&pdev->dev, "McBSP node is not provided\n");
> +return -EINVAL;
> +}
> + printk(KERN_ERR"refcount 0x%x",
> atomic_read(&dai_node->kref.refcount));
> +
> +
> omap_twl4030_dai_links[0].cpu_dai_name = NULL;
> omap_twl4030_dai_links[0].cpu_of_node = dai_node;
>
> [Result]:-
> root@DevKit8000:/# insmod snd-soc-omap-twl4030.ko
> [ 95.718109] refcount 0x1
> [ 95.720611] refcount 0x1 [ 95.818054] omap-twl4030 sound.20:
> twl4030-hifi <-> 49022000.mcbsp mapping ok
>
>
> Thanks,
> Anil
> [...]
--
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 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
> +static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device
> *dssdev)
> +{
> + return (struct panel_acx565akm_data *) dssdev->data;
> +}
> +
> static int acx_panel_probe(struct omap_dss_device *dssdev)
> {
> int r;
> struct acx565akm_device *md = &acx_dev;
> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
Why the get_panel_data function is needed, isn't the cast unnecessary?
A.
--
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 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
Hi,
On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
> @@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device
> *dssdev)
> dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
> dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
>
> + if (gpio_is_valid(bdata->panel_reset)) {
> + r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
> + GPIOF_OUT_INIT_LOW, "PANEL RESET");
> + if (r)
> + return r;
> + }
> +
> + if (gpio_is_valid(bdata->ctrl_pwrdown)) {
> + r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
> + GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
> + if (r)
> + return r;
> + }
> +
In the error case, the other GPIO is not freed. Also maybe you should
free them on module removal, because now the module owns the GPIOs.
A.
--
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 1/1] OMAP4: DSS: Add panel for Blaze Tablet boards
Hi Andi,
Thanks for your review,
On Mon, Feb 11, 2013 at 1:51 AM, Andi Shyti wrote:
> Hi Ruslan,
>
>> TC358765 is DSI-to-LVDS transmitter from Toshiba, used in
>> OMAP44XX Blaze Tablet and Blaze Tablet2 boards.
>
> I think it's fine, just some nitpicks and checkpatch warnings
>
>> +struct {
>> + struct device *dev;
>> + struct dentry *dir;
>> +} tc358765_debug;
>
> Should this be static?
Agree.
>
>> +struct tc358765_reg {
>> + const char *name;
>> + u16 reg;
>> + u8 perm:2;
>> +} tc358765_regs[] = {
>
> Should this be static as well?
Agree.
>
>> + { "D1S_ZERO", D1S_ZERO, A_RW },
>> + { "D2S_ZERO", D2S_ZERO, A_RW },
>> + { "D3S_ZERO", D3S_ZERO, A_RW },
>> + { "PPI_CLRFLG", PPI_CLRFLG, A_RW },
>> + { "PPI_CLRSIPO", PPI_CLRSIPO, A_RW },
>> + { "PPI_HSTimeout", PPI_HSTimeout, A_RW },
>
> WARNING: Avoid CamelCase:
> #136: FILE: video/omap2/displays/panel-tc358765.c:136:
> + { "PPI_HSTimeout", PPI_HSTimeout, A_RW },
>
>> + { "PPI_HSTimeoutEnable", PPI_HSTimeoutEnable, A_RW },
>
> WARNING: Avoid CamelCase:
> #137: FILE: video/omap2/displays/panel-tc358765.c:137:
> + { "PPI_HSTimeoutEnable", PPI_HSTimeoutEnable, A_RW },
Hmm... I though these registers had such naming in the documentation,
however, after looking into it I found the names are in upper case there
so this will be fixed.
>
>
>> +static int tc358765_read_block(u16 reg, u8 *data, int len)
>> +{
>> + unsigned char wb[2];
>> + struct i2c_msg msg[2];
>> + int r;
>> + mutex_lock(&tc358765_i2c->xfer_lock);
>> + wb[0] = (reg & 0xff00) >> 8;
>> + wb[1] = reg & 0xff;
>> + msg[0].addr = tc358765_i2c->client->addr;
>> + msg[0].len = 2;
>> + msg[0].flags = 0;
>> + msg[0].buf = wb;
>> + msg[1].addr = tc358765_i2c->client->addr;
>> + msg[1].flags = I2C_M_RD;
>> + msg[1].len = len;
>> + msg[1].buf = data;
>> +
>> + r = i2c_transfer(tc358765_i2c->client->adapter, msg, ARRAY_SIZE(msg));
>> + mutex_unlock(&tc358765_i2c->xfer_lock);
>> +
>> + if (r == ARRAY_SIZE(msg))
>> + return len;
>> +
>> + return r;
>
> If you like, here you could do
>
> return (r == ARRAY_SIZE(msg)) ? len : r;
>
> Usually I like more this notation because keeps the code more
> compact and immediate to read, but you don't have to
Yes, makes sense for "beautification" :)
Will change
>
>> + mutex_lock(&tc358765_i2c->xfer_lock);
>> + ret = i2c_transfer(tc358765_i2c->client->adapter, &msg, 1);
>> + mutex_unlock(&tc358765_i2c->xfer_lock);
>> +
>> + if (ret != 1)
>> + return ret;
>> + return 0;
>
> Also here you could do
>
> return (ret != 1) ? ret : 0;
>
> But this is more taste :)
>
>> +static ssize_t tc358765_seq_write(struct file *filp, const char __user
>> *ubuf,
>> + size_t size, loff_t *ppos)
>> +{
>> + struct device *dev = tc358765_debug.dev;
>> + unsigned i, reg_count;
>> + u32 value = 0;
>> + int error = 0;
>> + /* kids, don't use register names that long */
>
> I won't, promised, but please, drop this comment :)
>
>> + char name[30];
>> + char buf[50];
>> +
>> + if (size >= sizeof(buf))
>> + size = sizeof(buf);
>
> what's the point of this?
This is a way to limit copied from userspace data by available buffer size,
widely used in current kernel sources. Are you implying there is some
better (more graceful) way?
>
>> +static void tc358765_uninitialize_debugfs(void)
>> +{
>> + if (tc358765_debug.dir)
>> + debugfs_remove_recursive(tc358765_debug.dir);
>
> WARNING: debugfs_remove_recursive(NULL) is safe this check is probably not
> required
> #435: FILE: video/omap2/displays/panel-tc358765.c:435:
> + if (tc358765_debug.dir)
> + debugfs_remove_recursive(tc358765_debug.dir);
Will fix it..
>
>
>> +static struct tc358765_board_data *get_board_data(struct omap_dss_device
>> + *dssdev)
>> +{
>> + return (struct tc358765_board_data *)dssdev->data;
>
> You shouldn't need for this cast, does it complain?
yes, we don't need this :)
>
>> +}
>> +
>> +static void tc358765_get_timings(struct omap_dss_device *dssdev,
>> + struct omap_video_timings *timings)
>> +{
>> + *timings = dssdev->panel.timings;
>> +}
>> +
>> +static void tc358765_set_timings(struct omap_dss_device *dssdev,
>> + struct omap_video_timings *timings)
>> +{
>> + dev_info(&dssdev->dev, "set_timings() not implemented\n");
>
> ... then drop the function :)
I need to check if this will have any side effects in places where
this is used. I mean next:
| if (blabla->set_timings)
|blabla->set_timings();
| else
|do_another_thing();
But it seems this may be safely removed
>
>> + if ((pins[2] & 1) || (pins[3] & 1)) {
>> + lanes |= (1 << 1);
>> + ret |= tc358765_write_regist
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
On Wed, 13 Feb 2013, J, KEERTHY wrote: > So the patch needs to be rebased after 3.9 right? No, I've already done that. At this point, I don't think there's anything further that you need to do with it. Will let you know if that turns out not to be true. - Paul -- 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 00/13] drivers: mailbox: framework creation
Hi Suman, I'll send new version of patch 11 taking into account Mark Rutland's comments. Regards, Loic On 02/13/2013 05:41 PM, Anna, Suman wrote: >> On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote: >>> On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna wrote: >>> I have hosted the series at [3]. [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox >>> >>> Suman, I suggest you ask Stepgen Rothwell to include this branch into >>> the linux-next tree, so we can get some rotation of this stuff in >>> preparation for the v3.10 merge window. (It's not going in now >>> anyway.) >> >> Best wait until after v3.9-rc1 - remember that linux-next is supposed to be a >> staging tree for the _next_ merge window only. > > Yes, will do. Anyway, we need a new revision of one patch (so far) to address > Mark Rutland's comments. > > Thanks > Suman-- 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 v3 10/13] mailbox: create dbx500 mailbox driver
From: Loic Pallardy
Add STEriccson DBX500 PRCM mailbox support.
Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 +
drivers/mailbox/Kconfig| 7 +
drivers/mailbox/Makefile | 1 +
drivers/mailbox/mailbox-dbx500.c | 648 +
include/linux/platform_data/mailbox-dbx500.h | 12 +
5 files changed, 695 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
create mode 100644 drivers/mailbox/mailbox-dbx500.c
create mode 100644 include/linux/platform_data/mailbox-dbx500.h
diff --git a/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
new file mode 100644
index 000..7a10e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
@@ -0,0 +1,27 @@
+ST-Ericsson DBx500 PRCM Mailbox Driver
+
+Required properties:
+- compatible : Should be
+ "stericsson,db8500-mailbox" for db8500 and db9500
+ "stericsson,db9540-mailbox" for db9540
+- reg : Physical base address and length of mailbox's
+ registers and shared memory
+- reg-names: Should contain the reg names "prcm-reg" and
+ "prcmu-tcdm"
+- interrupts : contains the IRQ line for the PRCM mailbox
+- interrupt-names : Should contain the interrupt name "irq"
+- legacy-offset: Memory offset in shared mem for legacy
mailboxes
+
+Optional properties:
+- upap-offset : Memory offset in shared mem for upap mailboxes
+
+Examples:
+
+mailbox {
+ compatible = "stericsson,db8500-mailbox";
+ reg = <0x80157000 0x1000>, <0x801B8000 0x2000>;
+ reg-names = "prcm-reg", "prcmu-tcdm";
+ interrupts = <0 47 0x4>;
+ interrupt-names = "irq";
+ legacy-offset = <0xdd4>;
+};
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c28897d..d352028 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -24,6 +24,12 @@ config OMAP2PLUS_MBOX
OMAP2/3; or IPU, IVA HD and DSP in OMAP4. Say Y here if you want
to use OMAP2+ Mailbox framework support.
+config DBX500_MBOX
+ tristate "DBx500 Mailbox driver support"
+ depends on ARCH_U8500
+ help
+ Say Y here if you want to use DBx500 Mailbox driver support for
+ power coprocessor access on Ux500 and Ux540 families
config MBOX_KFIFO_SIZE
int "Mailbox kfifo default buffer size (bytes)"
@@ -35,6 +41,7 @@ config MBOX_KFIFO_SIZE
config MBOX_DATA_SIZE
int "Mailbox associated data max size (bytes)"
+ default 64 if DBX500_MBOX
default 4
help
Specify the default size of mailbox's associated data buffer
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4085b71..c04ce79 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_MAILBOX) += mailbox.o
obj-$(CONFIG_OMAP1_MBOX) += mailbox-omap1.o
obj-$(CONFIG_OMAP2PLUS_MBOX) += mailbox-omap2.o
+obj-$(CONFIG_DBX500_MBOX) += mailbox-dbx500.o
diff --git a/drivers/mailbox/mailbox-dbx500.c b/drivers/mailbox/mailbox-dbx500.c
new file mode 100644
index 000..e9d2b0a
--- /dev/null
+++ b/drivers/mailbox/mailbox-dbx500.c
@@ -0,0 +1,648 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2012
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Loic Pallardy for ST-Ericsson
+ * DBX500 PRCM Mailbox driver
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mailbox_internal.h"
+
+#define MAILBOX_LEGACY 0
+#define MAILBOX_UPAP 1
+
+enum {
+ MAILBOX_BLOCKING,
+ MAILBOX_ATOMIC,
+};
+
+/* CPU mailbox registers */
+#define PRCM_MBOX_CPU_VAL 0x0fc
+#define PRCM_MBOX_CPU_SET 0x100
+#define PRCM_MBOX_CPU_CLR 0x104
+
+#define PRCM_ARM_IT1_CLR 0x48C
+#define PRCM_ARM_IT1_VAL 0x494
+
+#define NUM_MB 8
+#define MBOX_BIT BIT
+#define ALL_MBOX_BITS (MBOX_BIT(NUM_MB) - 1)
+
+/* CPU mailbox shared memory */
+#define PRCM_MBOX_LEGACY_SIZE 0x220
+#define _PRCM_MBOX_HEADER 0x214 /* 16 bytes */
+#define PRCM_MBOX_HEADER_REQ_MB0 (_PRCM_MBOX_HEADER + 0x0)
+#define PRCM_MBOX_HEADER_REQ_MB1 (_PRCM_MBOX_HEADER + 0x1)
+#define PRCM_MBOX_HEADER_REQ_MB2 (_PRCM_MBOX_HEADER + 0x2)
+#define PRCM_MBOX_HEADER_REQ_MB3 (_PRCM_MBOX_HEADER + 0x3)
+#define PRCM_MBOX_HEADER_REQ_MB4 (_PRCM_MBOX_HEADER + 0x4)
+#define PRCM_MBOX_HEADER_REQ_MB5 (_PRCM_MBOX_HEADER + 0x5)
+#define PRCM_MBOX_HEADER_ACK_MB0 (_PRCM_MBOX_HEADER + 0x8)
+
+/* Req Mailboxes */
+#define PRCM_REQ_MB0 0x208 /* 12
Re: [PATCH v3 10/13] mailbox: create dbx500 mailbox driver
On Wed, Feb 13, 2013 at 09:42:07PM +0100, Loic Pallardy wrote: > From: Loic Pallardy > > Add STEriccson DBX500 PRCM mailbox support. > > Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762 These mean nothing when submitting kernel patches, please never include them. thanks, greg k-h -- 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 v3 10/13] mailbox: create dbx500 mailbox driver
Sorry my mistake, I forgot to clean this before sending. Regards, Loic On 02/13/2013 09:55 PM, Greg Kroah-Hartman wrote: > On Wed, Feb 13, 2013 at 09:42:07PM +0100, Loic Pallardy wrote: >> From: Loic Pallardy >> >> Add STEriccson DBX500 PRCM mailbox support. >> >> Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762 > > These mean nothing when submitting kernel patches, please never include > them. > > thanks, > > greg k-h-- 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: DT GPMC SRAM and NOR flash support ?
On 02/07/2013 03:51 AM, Mark Jackson wrote:
> Okay ... I have made some progress, but it's not ideal.
>
> Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
> handles setting up the
> chip selects and timings for NOR devices, e.g.
>
> gpmc: gpmc@5000 {
> status = "okay";
> ranges = <0 0 0x0800 0x0800>; /* CS0: NOR 16M
> */
Is that really 16M? Looks more like 128M :-)
> nor@0,0 {
> compatible = "spansion,s29gl064n90t",
> "cfi-flash";
> reg = <0 0 0>;
I think that cfi-flash is expecting a length here. Here is
what I have ...
+&gpmc {
+ ranges = <0 0 0x0800 0x0400>;
+
+ nor@0,0 {
+ compatible = "cfi-flash";
+ linux,mtd-name= "intel,ge28f256l18b85";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0 0x0400>;
+ bank-width = <2>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0 0x2>;
+ };
+ partition@0x2 {
+ label = "params";
+ reg = <0x2 0x2>;
+ };
+ partition@0x4 {
+ label = "kernel";
+ reg = <0x4 0x20>;
+ };
+ partition@0x24 {
+ label = "file-system";
+ reg = <0x24 0x3dc>;
+ };
+ };
> nor-flash@0800 {
> compatible = "spansion,s29gl064n90t", "cfi-flash";
> reg = <0x0800 0x0080>;
> bank-width = <2>;
> };
You don't need this extra entry if you add "simple-bus" to
the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = "ti,omap2420-gpmc", "simple-bus";
+ ti,hwmods = "gpmc";
+ reg = <0x6800a000 0x1000>;
+ interrupts = <20>;
+
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ };
Currently I have the following and this is working for me.
Please note that on my board the bootloader is configuring
the timings for me and so this is missing from the below
implementation and still needs to be added.
Cheers
Jon
>From c0ede833fad704ab452b116154177e3a59166c7e Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash
---
arch/arm/mach-omap2/gpmc.c | 69
1 file changed, 69 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bc90155..421320b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)
return r;
}
+static int gpmc_cs_remap(int cs, u32 base)
+{
+ int r;
+ u32 old_base, size;
+
+ gpmc_cs_get_memconf(cs, &old_base, &size);
+ if (base == old_base)
+ return 0;
+ gpmc_cs_disable_mem(cs);
+ r = gpmc_cs_delete_mem(cs);
+ if (IS_ERR_VALUE(r))
+ return r;
+ r = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(r))
+ return r;
+ gpmc_cs_enable_mem(cs, base, size);
+
+ return 0;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = &gpmc_cs_mem[cs];
@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_nor_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ struct resource res;
+ unsigned long base;
+ int rc, cs;
+
+ if (of_property_read_u32(child, "reg", &cs) < 0) {
+ dev_err(&pdev->dev, "%s has no 'reg' property\n",
+ child->full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, &res)) {
+ dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
+ child->full_name);
+ return -ENODEV;
+ }
+
+ rc = gpmc_cs_request(cs, res.end - res.start, &base);
+ if (rc < 0)
+ pr_err("%s: cannot request GPMC CS %d\n", __func__, cs);
+
+ /*
+* gpmc_cs_request() will map the CS to an arbitary location
+* in the gpmc address space. When booting with device-tree we
+* want the NOR flash to be mapped to the location specified
+* in
[PATCH v4 10/13] mailbox: create dbx500 mailbox driver
From: Loic Pallardy
Add STEriccson DBX500 PRCM mailbox support.
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 +
drivers/mailbox/Kconfig| 7 +
drivers/mailbox/Makefile | 1 +
drivers/mailbox/mailbox-dbx500.c | 648 +
include/linux/platform_data/mailbox-dbx500.h | 12 +
5 files changed, 695 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
create mode 100644 drivers/mailbox/mailbox-dbx500.c
create mode 100644 include/linux/platform_data/mailbox-dbx500.h
diff --git a/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
new file mode 100644
index 000..7a10e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt
@@ -0,0 +1,27 @@
+ST-Ericsson DBx500 PRCM Mailbox Driver
+
+Required properties:
+- compatible : Should be
+ "stericsson,db8500-mailbox" for db8500 and db9500
+ "stericsson,db9540-mailbox" for db9540
+- reg : Physical base address and length of mailbox's
+ registers and shared memory
+- reg-names: Should contain the reg names "prcm-reg" and
+ "prcmu-tcdm"
+- interrupts : contains the IRQ line for the PRCM mailbox
+- interrupt-names : Should contain the interrupt name "irq"
+- legacy-offset: Memory offset in shared mem for legacy
mailboxes
+
+Optional properties:
+- upap-offset : Memory offset in shared mem for upap mailboxes
+
+Examples:
+
+mailbox {
+ compatible = "stericsson,db8500-mailbox";
+ reg = <0x80157000 0x1000>, <0x801B8000 0x2000>;
+ reg-names = "prcm-reg", "prcmu-tcdm";
+ interrupts = <0 47 0x4>;
+ interrupt-names = "irq";
+ legacy-offset = <0xdd4>;
+};
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c28897d..d352028 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -24,6 +24,12 @@ config OMAP2PLUS_MBOX
OMAP2/3; or IPU, IVA HD and DSP in OMAP4. Say Y here if you want
to use OMAP2+ Mailbox framework support.
+config DBX500_MBOX
+ tristate "DBx500 Mailbox driver support"
+ depends on ARCH_U8500
+ help
+ Say Y here if you want to use DBx500 Mailbox driver support for
+ power coprocessor access on Ux500 and Ux540 families
config MBOX_KFIFO_SIZE
int "Mailbox kfifo default buffer size (bytes)"
@@ -35,6 +41,7 @@ config MBOX_KFIFO_SIZE
config MBOX_DATA_SIZE
int "Mailbox associated data max size (bytes)"
+ default 64 if DBX500_MBOX
default 4
help
Specify the default size of mailbox's associated data buffer
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4085b71..c04ce79 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_MAILBOX) += mailbox.o
obj-$(CONFIG_OMAP1_MBOX) += mailbox-omap1.o
obj-$(CONFIG_OMAP2PLUS_MBOX) += mailbox-omap2.o
+obj-$(CONFIG_DBX500_MBOX) += mailbox-dbx500.o
diff --git a/drivers/mailbox/mailbox-dbx500.c b/drivers/mailbox/mailbox-dbx500.c
new file mode 100644
index 000..e9d2b0a
--- /dev/null
+++ b/drivers/mailbox/mailbox-dbx500.c
@@ -0,0 +1,648 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2012
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Loic Pallardy for ST-Ericsson
+ * DBX500 PRCM Mailbox driver
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mailbox_internal.h"
+
+#define MAILBOX_LEGACY 0
+#define MAILBOX_UPAP 1
+
+enum {
+ MAILBOX_BLOCKING,
+ MAILBOX_ATOMIC,
+};
+
+/* CPU mailbox registers */
+#define PRCM_MBOX_CPU_VAL 0x0fc
+#define PRCM_MBOX_CPU_SET 0x100
+#define PRCM_MBOX_CPU_CLR 0x104
+
+#define PRCM_ARM_IT1_CLR 0x48C
+#define PRCM_ARM_IT1_VAL 0x494
+
+#define NUM_MB 8
+#define MBOX_BIT BIT
+#define ALL_MBOX_BITS (MBOX_BIT(NUM_MB) - 1)
+
+/* CPU mailbox shared memory */
+#define PRCM_MBOX_LEGACY_SIZE 0x220
+#define _PRCM_MBOX_HEADER 0x214 /* 16 bytes */
+#define PRCM_MBOX_HEADER_REQ_MB0 (_PRCM_MBOX_HEADER + 0x0)
+#define PRCM_MBOX_HEADER_REQ_MB1 (_PRCM_MBOX_HEADER + 0x1)
+#define PRCM_MBOX_HEADER_REQ_MB2 (_PRCM_MBOX_HEADER + 0x2)
+#define PRCM_MBOX_HEADER_REQ_MB3 (_PRCM_MBOX_HEADER + 0x3)
+#define PRCM_MBOX_HEADER_REQ_MB4 (_PRCM_MBOX_HEADER + 0x4)
+#define PRCM_MBOX_HEADER_REQ_MB5 (_PRCM_MBOX_HEADER + 0x5)
+#define PRCM_MBOX_HEADER_ACK_MB0 (_PRCM_MBOX_HEADER + 0x8)
+
+/* Req Mailboxes */
+#define PRCM_REQ_MB0 0x208 /* 12 bytes */
+#define PRCM_REQ_MB1 0x1
Re: [PATCH 1/1] ARM: OMAP4: Add OMAP4 Blaze Tablet support
Hi Tony, Jon, On Mon, Feb 11, 2013 at 9:00 PM, Tony Lindgren wrote: > * Jon Hunter [130211 10:58]: >> >> Please note that the blaze is derived from the omap4-sdp board and so I >> would hope that we can use the existing for sdp dts and board file for >> blaze. In fact this is what I do today for basic booting. >> >> So unless there is some feature on the blaze that is not compatible with >> the original sdp, we should just use the sdp dts. > > Sounds like we need some common .dts file and separate files > for sdp, blaze and tablet that include the common .dts file? > > There's a different LCD panel at least between blaze and the > tablet. Please note, that, although 'Blaze' board is very close to 'SDP' board, there are quite big differences comparing to 'Blaze Tablet' board. At least: - LCD panels - touchscreen controllers - LEDs - Keypad (on 'Blaze') / gpio keys (on 'Blaze Tablet') - Sensors - HS USB Host related stuff - cameras (there is no embedded cameras on 'Blaze Tablet' board) As per my point of view, next should be done: 1) Add the DTS file for BlazeTablet board 2) Figure out what is common for both and move it to some common file (if that makes sense) I'm currently working on step '#1'. So after that step #2 should not be an issue for us. Best regards, Ruslan > > 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 v2 0/1] OMAP4: DSS: Add panel for Blaze Tablet boards
Hi Tomi, On Wed, Feb 13, 2013 at 10:18 AM, Tomi Valkeinen wrote: > Hi, > > On 2013-02-08 17:43, Ruslan Bilovol wrote: >> Hi, >> >> This patch adds support for TC358765 DSI-to-LVDS transmitter >> from Toshiba, that is used in OMAP4 Blaze Tablet development >> platform. It was originally developed a long time ago and >> was used internally survived few kernel migrations. >> Different people worked in this driver during last two >> years changing its sources to what each new version of >> kernel expects. >> >> Current version is ported from internal kernel v3.4 to 3.8.0-rc6 >> Tested basic functioning under busybox. > > Thanks for updating the driver to a recent kernel. > > I didn't review the patch line by line, but with a brief look it looks > fine. However, I'm not quite sure what to do with this patch. > > The problem is that the driver is a combined driver for the TC358765 > chip and the panel on Blaze Tablet, and we are very much trying to fix > that design issue so that the drivers for the chip and panel could be > separate, as they should. > > So I fear that if I now accept the patch, it'll increase my burden of > managing the display drivers during this design rework. Furthermore, to > my knowledge the Blaze Tablet is quite a rare board, and it's not even > supported in the mainline kernel, so this driver wouldn't be usable by > itself. This patch is exactly a part of mainlining of the BlazeTablet board support :) The goal is to have as much as possible support of this board in the 'vanilla' kernel. The BlazeTablet mainlining is already ongoing ( https://patchwork.kernel.org/patch/2118281/ ) and I hope we will have some support of this board in near future. The BlazeTablet's LCD panel support is very important thing for us to have it in mainline because without it the BlazeTablet becomes a 'black brick' and it is painful for us to port this driver against each new version of kernel. > > So if I'm right about the blaze tablet status, I'm inclined to say that > I think this should be still kept out of tree. Considering my information above, (and your information that design rework will be started later), can we pick this driver for now in its current state? Regards, Ruslan > > Tomi > > -- 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: OMAP: Clock: Remove CK_* flags
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, February 14, 2013 1:14 AM > To: J, KEERTHY > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags > > On Wed, 13 Feb 2013, J, KEERTHY wrote: > > > So the patch needs to be rebased after 3.9 right? > > No, I've already done that. At this point, I don't think there's > anything > further that you need to do with it. Will let you know if that turns > out > not to be true. Ok. Thanks Paul. > > - Paul -- 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 27/33] OMAPDSS: n8x0 panel: handle gpio data in panel driver
Hi,
On Wednesday 13 February 2013 11:05 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:19PM +0530, Archit Taneja wrote:
@@ -444,6 +445,20 @@ static int n8x0_panel_probe(struct omap_dss_device *dssdev)
dssdev->ctrl.rfbi_timings = n8x0_panel_timings;
dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
+ if (gpio_is_valid(bdata->panel_reset)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->panel_reset,
+ GPIOF_OUT_INIT_LOW, "PANEL RESET");
+ if (r)
+ return r;
+ }
+
+ if (gpio_is_valid(bdata->ctrl_pwrdown)) {
+ r = devm_gpio_request_one(&dssdev->dev, bdata->ctrl_pwrdown,
+ GPIOF_OUT_INIT_LOW, "PANEL PWRDOWN");
+ if (r)
+ return r;
+ }
+
In the error case, the other GPIO is not freed. Also maybe you should
free them on module removal, because now the module owns the GPIOs.
Wouldn't the usage of devm_* functions take care of this? If the device
isn't registered successfully, then all allocations/requests done using
devm_* functions will be free'd automatically.
Archit
--
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 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
+static struct panel_acx565akm_data *get_panel_data(struct omap_dss_device
*dssdev)
+{
+ return (struct panel_acx565akm_data *) dssdev->data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
int r;
struct acx565akm_device *md = &acx_dev;
+ struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
Why the get_panel_data function is needed, isn't the cast unnecessary?
the 'data' member of omap_dss_device has the type 'void *', we need to
cast it to access the panel_acx565akm_data struct pointer.
Archit
--
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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/13/13 17:59, Tomi Valkeinen wrote: > On 2013-02-13 17:28, Tomi Valkeinen wrote: >> On 2013-02-13 17:16, Igor Grinberg wrote: >>> Hi Archit, >>> >>> On 02/13/13 16:21, Archit Taneja wrote: The cm-t35 board file currently requests gpios required to configure the tdo35s panel, and provides platform_enable/disable callbacks to configure them. These tasks have been moved to the generic dpi panel driver itself and shouldn't be done in the board files. Remove the gpio requests and the platform callbacks from the board file. Add the gpio information to generic dpi panel's platform data so that it's passed to the panel driver. Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio was enabled after a 50 millisecond delay. This code has been removed and is not taken care of in the generic panel driver. The impact of this needs to be tested. The panel's gpios are also not exported any more. Hence, they can't be accessed via sysfs interface. >>> >>> Indeed, there is an impact - the LCD no longer works. >>> The reason for the LCD_EN gpio being pushed high after the 50ms delay, >>> is to get the LCD out of reset, so the SPI transaction will succeed >>> and initialize the LCD. >>> Now, when you remove the gpio handling for the LCD_EN pin, >>> the LCD no longer works. >> >> So between what is the sleep done? It's not clear from the code. LCD_EN >> needs to be 0 for 50ms, or...? >> >> If the panel requires specific reset handling, does it work right even >> currently when the panel is turned off and later turned on? The msleep >> is only used at boot time. > > Okay, so I just realized there's an spi backlight driver used here, and > that backlight driver is actually handling the SPI transactions with the > panel, instead of the panel driver. So this looks quite messed up. Yep, it always was. The whole DSS specific panel handling inside the drivers/video/omap2/displays is a mess. Those panels can be (and are) used not only with OMAP based boards. > > For a quick solution, can we just set the LCD_EN at boot time (with the > msleep), and not touch it after that? That would be sensible for now, so this series can be merged. As a more appropriate (and long term) solution, I plan on moving the panel reset pin handling to the spi backlight driver itself. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHIqCAAoJEBDE8YO64Efamw0P/R2wt0tpCI1ecrnutVGMX4bF Pyjk2B65uDWqoqZ/cpJUqnvmupXl5UdrA7eqKjTBh1A+g81UVFcNDMuJsbPIIiYI 1pimZieAq0T6Vag00PKImKlkhJYfC7JVBbESij/NONlzYtPkbZ91Y+Ik4DZXnyZf 1TS4GbHQ25tjl73PkwlzLUcJIDIogsimSrkM+aWXPE8LmvrBEQs0LhAObPsAFtgL 1An3hvA2Tkhh9QgerWQd9YiqX994tv1PGRLBEXTbjh1yihzKSNleuvw3NdM+wf9i 9Y5l9IV6L2dtYBMLCpzkiGQBDdOzoq+fObRnSgK6Kr1mfXot+MAlLrk9gCeWcq1b c2oU/imKWB4sZys21pTnjIxAIzzRDoGW40qXuibTW4DoAYaVHuEBPtphjMVCBCcQ sJaIVXpsChQ3vvtHOgllnInMjCnlXJ3Piqr4y5glTPxu9mZHdPr6VDpWdqRmvyr9 V7fRQztwXB3Td+SZVDD1yBqoXKlKCX4QPlLAqH3FI9s1WhDHcJePcoDJY0/QyXB1 IeQRlEwBBEZAYy/kr9/pwbZzXeh5V5dK6wAq8aT+thS22zl3nJbKjW//vN06+ib+ WAnHRSZ8iCbUX2cRVF1k+DCQOTi8QCbI6WTcLsgenLeSrbEuzilfgsrsvd6LHfjD oTODiiD9QInP2sBfknUp =tWsB -END PGP SIGNATURE- -- 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 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
On 2013-02-14 08:51, Archit Taneja wrote:
> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>> Hi,
>>
>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>> omap_dss_device *dssdev)
>>> +{
>>> +return (struct panel_acx565akm_data *) dssdev->data;
>>> +}
>>> +
>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>> {
>>> int r;
>>> struct acx565akm_device *md = &acx_dev;
>>> +struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>
>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>
> the 'data' member of omap_dss_device has the type 'void *', we need to
> cast it to access the panel_acx565akm_data struct pointer.
You don't need an explicit cast to assign a void pointer to a pointer to
something else (or vice versa, I think).
I remember us having similar constructs in some other panel drivers
also. I think they are unnecessary also.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
On 2013-02-14 08:56, Igor Grinberg wrote: > On 02/13/13 17:59, Tomi Valkeinen wrote: >> Okay, so I just realized there's an spi backlight driver used here, and >> that backlight driver is actually handling the SPI transactions with the >> panel, instead of the panel driver. So this looks quite messed up. > > Yep, it always was. > The whole DSS specific panel handling inside the > drivers/video/omap2/displays is a mess. Well, that's not mess itself, it's just omap specific panel framework. But dividing single device handling into two separate places is a mess. > Those panels can be (and are) used not only with OMAP based boards. True, but as there's no generic panel framework, that's the best we can do. But see CDF (common display framework) discussions if you're interested in what's hopefully coming soon. >> For a quick solution, can we just set the LCD_EN at boot time (with the >> msleep), and not touch it after that? > > That would be sensible for now, so this series can be merged. > As a more appropriate (and long term) solution, > I plan on moving the panel reset pin handling to the spi backlight > driver itself. Well, if you must. But I suggest moving the whole panel handling into a (omap specific) panel driver, as it's done for other panels. That way you'll have a proper panel driver for it, for omap, and when CDF comes, you'll get a platform independent panel driver for it. Of course, if you have multiple platforms already using that backlight driver, the omap specific approach may not be enticing. So perhaps it's easier to just do the quick fix and wait for CDF. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
On 2013-02-14 08:51, Archit Taneja wrote:
On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
Hi,
On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
+static struct panel_acx565akm_data *get_panel_data(struct
omap_dss_device *dssdev)
+{
+return (struct panel_acx565akm_data *) dssdev->data;
+}
+
static int acx_panel_probe(struct omap_dss_device *dssdev)
{
int r;
struct acx565akm_device *md = &acx_dev;
+struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
Why the get_panel_data function is needed, isn't the cast unnecessary?
the 'data' member of omap_dss_device has the type 'void *', we need to
cast it to access the panel_acx565akm_data struct pointer.
You don't need an explicit cast to assign a void pointer to a pointer to
something else (or vice versa, I think).
I remember us having similar constructs in some other panel drivers
also. I think they are unnecessary also.
Ah okay, I'll take care of it.
Archit
--
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
