* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-05-05 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140430174751.GA12362@atomide.com>
* Tony Lindgren <tony@atomide.com> [140430 10:48]:
> * Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> > On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > > Looks like quite a few omaps have sharp ls037v7dw01 that's configured
> > > as various panel dpi entries for whatever legacy reasons. For device
> > > tree based support, let's just configure these properly for panel
> > > ls037v7dw01 instead of panel dpi.
> > >
> > > This patch creates a common file for panel ls037v7dw01, and makes
> > > boards ldp and omap3-evm to use it. The panel for ldp is configured
> > > in the qvga mode and omap3-evm panel in vga mode.
> > >
> > > The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
> > > controller for the omaps, so let's add a basic configuration for
> > > the touchscreen also using the default values.
> > >
> > > Note that we can now remove the regulator-name = "vdds_dsi"
> > > entry for ldp, that's no longer needed as we have the entry
> > > for vdds_dsi-supply = <&vpll2>.
> > >
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > ---
> > > .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> > > arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> > > arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> > > arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> > > 4 files changed, 205 insertions(+), 5 deletions(-)
> > > create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> >
> > > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > > index 0abe986..50fdac9 100644
> > > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > > @@ -164,6 +164,7 @@
> > >
> > > #include "twl4030.dtsi"
> > > #include "twl4030_omap3.dtsi"
> > > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> > >
> > > &i2c2 {
> > > clock-frequency = <400000>;
> > > @@ -173,6 +174,31 @@
> > > clock-frequency = <400000>;
> > > };
> > >
> > > +&lcd_3v3 {
> > > + gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > +};
> > > +
> > > +&lcd0 {
> > > + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> > > + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
> >
> > enable-gpios ?
>
> Oops yes, changed from gpios to enable-gpios while reading the panel
> binding doc, probably forgot to commit the change, will update.
Here's an updated version of this one.
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 0000000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+ regulator-always-on;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+ panel-timing {
+ clock-frequency = <5400000>;
+ hback-porch = <39>;
+ hactive = <240>;
+ hfront-porch = <3>;
+ hsync-len = <3>;
+ vback-porch = <7>;
+ vactive = <320>;
+ vfront-porch = <2>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &dss_dpi_pins1
+ &dss_dpi_pins2
+ >;
+};
+
&omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
+
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3) /* dss_data18.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3) /* dss_data19.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3) /* dss_data20.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3) /* dss_data21.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3) /* dss_data22.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /* dss_data23.dss_data5 */
+ >;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
};
};
+&omap3_pmx_wkup {
+ dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+ pinctrl-single,pins = <
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18 */
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19 */
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20 */
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21 */
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22 */
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23 */
+ >;
+ };
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..0ab9650 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -61,6 +66,48 @@
};
};
+&lcd_3v3 {
+ gpio = <&gpio5 25 GPIO_ACTIVE_LOW>; /* gpio153 */
+ enable-active-low;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ /*
+ * The LCD is sideways, so we want the VGA mode instead of
+ * QVGA mode. Probably also want to have omapfb.rotate=3
+ * in the kernel cmdline until there's a binding for that.
+ */
+ enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
+ &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+
+ panel-timing {
+ clock-frequency = <19200000>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 0>; /* gpio175 */
+ pendown-gpio = <&gpio6 15 0>;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmc1>;
vmmc_aux-supply = <&vsim>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..01b0808 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +178,27 @@
clock-frequency = <400000>;
};
+&lcd_3v3 {
+ gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
+ enable-gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
+ 0 /* lcd LR */
+ 0 /* lcd UD */
+ 0>; /* lcd INI */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio2>;
+ interrupts = <22 0>; /* gpio54 */
+ pendown-gpio = <&gpio2 22 0>;
+ };
+};
+
&mmc1 {
/* See 35xx errata 2.1.1.128 in SPRZ278F */
compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +273,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
^ permalink raw reply related
* Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
From: Tony Lindgren @ 2014-05-05 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [140429 16:53]:
> Hi all,
>
> Here are few patches to add devicetree support for panel ls037v7dw01
> that's found on many omap3 boards. They seem to be often mis-configured
> as various panel dpi entries, but really should be move to use panel
> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
> ldp, omap3 evm and few other development boards.
Tomi, assuming no more comments, do you want to pick up the first
three patches of this series? I can queue the .dts changes or you
can also set up a separate .dts changes branch for DSS that I can
merge in too.
Tony
> Regards,
>
> Tony
>
> Tony Lindgren (4):
> OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
> OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
> OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
> ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and
> ldp
>
> .../bindings/panel/sharp,ls037v7dw01.txt | 53 +++++++
> .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++
> arch/arm/boot/dts/omap3-evm-37xx.dts | 50 ++++++
> arch/arm/boot/dts/omap3-evm-common.dtsi | 47 ++++++
> arch/arm/boot/dts/omap3-ldp.dts | 31 +++-
> .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 176 ++++++++++++++-------
> drivers/video/fbdev/omap2/dss/dss.c | 5 +-
> 7 files changed, 379 insertions(+), 65 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
>
> --
> 1.8.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 0/3] Add display support for gta04 device
From: Belisko Marek @ 2014-05-07 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398284120-4986-1-git-send-email-marek@goldelico.com>
Tomi,
any objections to this patch set? If not can you please take it? Thanks.
On Wed, Apr 23, 2014 at 10:15 PM, Marek Belisko <marek@goldelico.com> wrote:
> This 3 patches adding display support for openmoko gta04 device.
> First patch add DT bindings for topolly td028 panel. Second add description for
> dss + panel and third fix panel probing when panel is compiled as module.
>
> Changes from v1:
> - extend panel compatible string by 'omapdss'
> - add tpo-td028 panel to dss_compat_conv_list
> - add MODULE_ALIAS macro to properly probe panel when is compiled as module
>
> Marek Belisko (3):
> omapdss: panel-tpo-td028ec1: Add DT support.
> ARM: dts: oma3-gta04: Add display support
> omapdss: panel-tpo-td028ec1: Add module alias
>
> .../bindings/video/toppoly,td028ttec1.txt | 30 ++++++++
> arch/arm/boot/dts/omap3-gta04.dts | 86 ++++++++++++++++++++++
> arch/arm/mach-omap2/display.c | 1 +
> .../omap2/displays-new/panel-tpo-td028ttec1.c | 33 ++++++++-
> 4 files changed, 149 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
>
> --
> 1.8.3.2
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: oma3-gta04: Add display support
From: Tomi Valkeinen @ 2014-05-07 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398284120-4986-3-git-send-email-marek@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On 23/04/14 23:15, Marek Belisko wrote:
> This patch add support for lcd display on gta04 board. Display control
> is connected on spi (used spi bitbang driver).
>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 86 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
<snip>
> +&dss {
> + pinctrl-names = "default";
> + pinctrl-0 = < &dss_dpi_pins >;
> +
> + status = "okay";
> +
> + vdds_dsi-supply = <&vpll2>;
> +
> + dpi_out: endpoint {
> + remote-endpoint = <&lcd_in>;
> + data-lines = <24>;
> + };
> +
> +};
>
Did you try this on 3.15-rc? The above is not right, and I don't think
it works. You need 'port' node for the dpi_out endpoint.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: oma3-gta04: Add display support
From: Belisko Marek @ 2014-05-07 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369DAC6.6050608@ti.com>
Hi Tomi,
On Wed, May 7, 2014 at 9:03 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 23/04/14 23:15, Marek Belisko wrote:
>> This patch add support for lcd display on gta04 board. Display control
>> is connected on spi (used spi bitbang driver).
>>
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-gta04.dts | 86 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 86 insertions(+)
>
> <snip>
>
>> +&dss {
>> + pinctrl-names = "default";
>> + pinctrl-0 = < &dss_dpi_pins >;
>> +
>> + status = "okay";
>> +
>> + vdds_dsi-supply = <&vpll2>;
>> +
>> + dpi_out: endpoint {
>> + remote-endpoint = <&lcd_in>;
>> + data-lines = <24>;
>> + };
>> +
>> +};
>>
>
> Did you try this on 3.15-rc? The above is not right, and I don't think
> it works. You need 'port' node for the dpi_out endpoint.
This patches was tested against 3.15 series and it works. I'l recheck.
>
> Tomi
>
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-07 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-4-git-send-email-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]
On 30/04/14 02:52, Tony Lindgren wrote:
> We can pass the GPIO configuration for ls037v7dw01 in a standard
> gpios property.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> .../bindings/panel/sharp,ls037v7dw01.txt | 53 ++++++++++++++
> .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 84 ++++++++++++++++++++--
> 2 files changed, 133 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
>
> diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> new file mode 100644
> index 0000000..7f6f5e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> @@ -0,0 +1,53 @@
> +SHARP LS037V7DW01 TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "sharp,ls037v7dw01"
> +
> +Optional properties:
> +- reset-gpios: a GPIO spec for the optional reset pin
> +- enable-gpios: a GPIO array for the optional configuration GPIOs
> + ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> +
> +This panel can have zero to five GPIOs to configure
> +to change configuration between QVGA and VGA mode
> +and the scan direction. As these pins can be also
> +configured with external pulls, all the GPIOs are
> +considered optional with holes in the array.
> +
> +Example when connected to a omap2+ based device:
> +
> + lcd0: display {
> + compatible = "sharp,ls037v7dw01";
> + power-supply = <&lcd_3v3>;
> + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
> + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
have anything to do with enabling the panel. Why not just have one
'gpios' array with all the gpios, as they are quite a mixed bunch?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
From: Tomi Valkeinen @ 2014-05-07 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-3-git-send-email-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
On 30/04/14 02:52, Tony Lindgren wrote:
> Using gpiod will make it easier to add device tree support
> for this panel in the following patches.
>
> Note that all the GPIOs for this panel are optional, any
> of the the GPIOs could be configured with external pulls
> instead of GPIOs, so let's not error out if GPIOs are not
> found to make the panel more generic.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 92 +++++++++-------------
> 1 file changed, 38 insertions(+), 54 deletions(-)
<snip>
> +static struct gpio_desc *
> +sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
> + char *desc)
> +{
> + int r;
> +
> + r = devm_gpio_request_one(dev, gpio, flags, desc);
> + if (r) {
> + dev_err(dev, "no %s gpio\n", desc);
As it's fine to not have a gpio, I guess this error print should be removed.
Also, if the error is EPROBE_DEFER, the driver should fail and return
that. The same goes for the DT version in the next patch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 13/13] video: omap: allow building on !MMU
From: Tomi Valkeinen @ 2014-05-07 9:14 UTC (permalink / raw)
To: Peter Griffin, Arnd Bergmann, Tony Lindgren
Cc: linux-kernel, linaro-kernel, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-omap
In-Reply-To: <1398342509-10243-14-git-send-email-peter.griffin@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On 24/04/14 15:28, Peter Griffin wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The omap lcdc driver has an elaborate mmap_kern function
> to map the frame buffer into kernel address space as
> write-combined. This uses functions that are only available
> on MMU-enabled builds.
>
> It does seem equivalent to ioremap_wc though, so we should
> be able to just use that instead.
>
> This patch is build-tested only, it needs to be run on real
> hardware before applying.
I don't have omap1 boards, and I don't know anyone that has. I don't
even know if the omap1 fb is working or not...
Tony, any idea of omap1's fb? Are you able to test this?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-07 9:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]
On 30/04/14 15:36, Alexander Shiyan wrote:
>> Hmm what? So is the old driver totally broken, and cannot be used at the
>> moment? Or why you can't test on real hardware?
>
> Firstly, the driver uses a fixed values for xres, yres, pixclock and specific
> variable ac_precale.
> Secondly, the driver uses a fixed value for the physical address of the buffer.
> Totally, it does not give me the ability to use the driver in the current state.
> Unlikely that this will look good if I make these two significant changes in
> a single patch...
>
> At this time the driver has three user.
> Only one of them should theoretically work.
> clps711x-autcpu12 should not work in the absence of memblock_reserve().
> clps711x-p720t should not work due to physical address limitation as i
> noticed before. Board means to use SRAM instead of SDRAM.
> Only clps711x-edb7211 should work fine (in theory).
> Is this a good reason to replace the driver? I think yes.
Ok, if the situation is that bad, maybe we can just switch to the new
driver. Have you verified that those boards do not work from anyone? Or
asked someone to test the new driver with those boards?
I'm still not really happy about it, and I'd much rather see the current
driver fixed. But if no one having those boards is up to the task
(probably not if they have not been working at all), maybe just ditching
the old driver and adding a new is the only way forward.
One change that I think would be good is to change the series to first
remove the old driver, and then add the new one, with the same file name
as the old one. That way git log will show the history for both the new
and the old driver.
>> Note that I don't know anything about the fb hardware in question, nor
>> the driver. Maybe there's a valid reason to write a new driver from
>> scratch. But there very rarely is.
>>
>> And "because I already wrote a new driver, and it's a waste of time for
>> me to throw away my work and patch the old one", is not a very good reason.
>
>>> if you imagine a new file as a diff to the old, this can be clearly seen.
>>>
>>> There is no reason to waste time on a series of changes since I
>>> can not even check these changes on real hardware, but only in the
>>> last stage when the driver will be the current version.
>
> Summing up, I want to ask why the driver can not be reviewed as a
> new and not compared to the old?
It can, of course. But we normally should not.
Fixing the old driver will keep all the fixes and tweaks that have been
debugged and solved with the old driver. Creating a new driver easily
makes those old fixes disappear.
Fixing the old driver also keeps the history, making it possible to see
where an issue was introduced etc.
> And yes, the time can be spent on more productive things to do than
> to create a series, leading eventually to the same result.
Yes, your time. But if, say, the new driver introduces bugs that already
were fixed in the old driver, causing problems to other people, and to
me as the maintainer, I'm sure the other people and me are not going to
say "well this is ok, as this saved Alexander's time" =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-07 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369EAE7.3030705@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 01:13]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > We can pass the GPIO configuration for ls037v7dw01 in a standard
> > gpios property.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > .../bindings/panel/sharp,ls037v7dw01.txt | 53 ++++++++++++++
> > .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 84 ++++++++++++++++++++--
> > 2 files changed, 133 insertions(+), 4 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> >
> > diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> > new file mode 100644
> > index 0000000..7f6f5e1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> > @@ -0,0 +1,53 @@
> > +SHARP LS037V7DW01 TFT-LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "sharp,ls037v7dw01"
> > +
> > +Optional properties:
> > +- reset-gpios: a GPIO spec for the optional reset pin
> > +- enable-gpios: a GPIO array for the optional configuration GPIOs
> > + ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
> > +
> > +This binding is compatible with the simple-panel binding, which is specified
> > +in simple-panel.txt in this directory.
> > +
> > +This panel can have zero to five GPIOs to configure
> > +to change configuration between QVGA and VGA mode
> > +and the scan direction. As these pins can be also
> > +configured with external pulls, all the GPIOs are
> > +considered optional with holes in the array.
> > +
> > +Example when connected to a omap2+ based device:
> > +
> > + lcd0: display {
> > + compatible = "sharp,ls037v7dw01";
> > + power-supply = <&lcd_3v3>;
> > + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> > + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> > + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> > + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
> > + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
>
> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
> have anything to do with enabling the panel. Why not just have one
> 'gpios' array with all the gpios, as they are quite a mixed bunch?
Yeah that's what I had initially, but reading simple-panel.txt noticed
there are some standardized GPIOs for reset and enable.
How about we set up one reset-gpios, one enable-gpios and an array of
three unlabelled GPIOs?
Or if we want to add something generic, we could add new mode-gpios
property that other panels might be able to use too?
BTW, I'm also personally fine with all five gpios showing in a single
gpios property, I'm not too exited about naming anything in DT..
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-07 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140507150343.GA9502@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
On 07/05/14 18:03, Tony Lindgren wrote:
>>> + lcd0: display {
>>> + compatible = "sharp,ls037v7dw01";
>>> + power-supply = <&lcd_3v3>;
>>> + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
>>> + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
>>> + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
>>> + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
>>> + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
>>
>> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
>> have anything to do with enabling the panel. Why not just have one
>> 'gpios' array with all the gpios, as they are quite a mixed bunch?
>
> Yeah that's what I had initially, but reading simple-panel.txt noticed
> there are some standardized GPIOs for reset and enable.
I'm not sure if it's worth to try to make it compatible with
simple-panel. simple-panel bindings do not work with omapdss anyway, and
simple-panel doesn't have the support for input ports/endpoints.
Can the panel be used with only one gpio (I guess that would be INI or
RESB)? If not, simple-panel doesn't work.
> How about we set up one reset-gpios, one enable-gpios and an array of
> three unlabelled GPIOs?
>
> Or if we want to add something generic, we could add new mode-gpios
> property that other panels might be able to use too?
>
> BTW, I'm also personally fine with all five gpios showing in a single
> gpios property, I'm not too exited about naming anything in DT..
I don't have a strong opinion here. I don't have much experience with
DT, especially with making bindings compatible with other ones.
I'd just forget the simple-panel, and have single gpio array.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-07 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536A5920.1020908@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> On 07/05/14 18:03, Tony Lindgren wrote:
>
> >>> + lcd0: display {
> >>> + compatible = "sharp,ls037v7dw01";
> >>> + power-supply = <&lcd_3v3>;
> >>> + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> >>> + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> >>> + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> >>> + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
> >>> + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
> >>
> >> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
> >> have anything to do with enabling the panel. Why not just have one
> >> 'gpios' array with all the gpios, as they are quite a mixed bunch?
> >
> > Yeah that's what I had initially, but reading simple-panel.txt noticed
> > there are some standardized GPIOs for reset and enable.
>
> I'm not sure if it's worth to try to make it compatible with
> simple-panel. simple-panel bindings do not work with omapdss anyway, and
> simple-panel doesn't have the support for input ports/endpoints.
>
> Can the panel be used with only one gpio (I guess that would be INI or
> RESB)? If not, simple-panel doesn't work.
I guess in theory yes.
> > How about we set up one reset-gpios, one enable-gpios and an array of
> > three unlabelled GPIOs?
> >
> > Or if we want to add something generic, we could add new mode-gpios
> > property that other panels might be able to use too?
> >
> > BTW, I'm also personally fine with all five gpios showing in a single
> > gpios property, I'm not too exited about naming anything in DT..
>
> I don't have a strong opinion here. I don't have much experience with
> DT, especially with making bindings compatible with other ones.
>
> I'd just forget the simple-panel, and have single gpio array.
Well if it's a don't care flag for both of us, let's try to use
the existing standard for simple-panel.txt and add mode-gpios
property. I'll post a patch for that.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-08 8:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
V2VkLCA3IE1heSAyMDE0IDEyOjQwOjQ5ICswMzAwINC+0YIgVG9taSBWYWxrZWluZW4gPHRvbWku
dmFsa2VpbmVuQHRpLmNvbT46Cj4gT24gMzAvMDQvMTQgMTU6MzYsIEFsZXhhbmRlciBTaGl5YW4g
d3JvdGU6Cj4gCj4gPj4gSG1tIHdoYXQ/IFNvIGlzIHRoZSBvbGQgZHJpdmVyIHRvdGFsbHkgYnJv
a2VuLCBhbmQgY2Fubm90IGJlIHVzZWQgYXQgdGhlCj4gPj4gbW9tZW50PyBPciB3aHkgeW91IGNh
bid0IHRlc3Qgb24gcmVhbCBoYXJkd2FyZT8KPiA+IAo+ID4gRmlyc3RseSwgdGhlIGRyaXZlciB1
c2VzIGEgZml4ZWQgdmFsdWVzIGZvciB4cmVzLCB5cmVzLCBwaXhjbG9jayBhbmQgc3BlY2lmaWMK
PiA+IHZhcmlhYmxlIGFjX3ByZWNhbGUuCj4gPiBTZWNvbmRseSwgdGhlIGRyaXZlciB1c2VzIGEg
Zml4ZWQgdmFsdWUgZm9yIHRoZSBwaHlzaWNhbCBhZGRyZXNzIG9mIHRoZSBidWZmZXIuCj4gPiBU
b3RhbGx5LCBpdCBkb2VzIG5vdCBnaXZlIG1lIHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgZHJpdmVy
IGluIHRoZSBjdXJyZW50IHN0YXRlLgo+ID4gVW5saWtlbHkgdGhhdCB0aGlzIHdpbGwgbG9vayBn
b29kIGlmIEkgbWFrZSB0aGVzZSB0d28gc2lnbmlmaWNhbnQgY2hhbmdlcyBpbgo+ID4gYSBzaW5n
bGUgcGF0Y2guLi4KPiA+IAo+ID4gQXQgdGhpcyB0aW1lIHRoZSBkcml2ZXIgaGFzIHRocmVlIHVz
ZXIuCj4gPiBPbmx5IG9uZSBvZiB0aGVtIHNob3VsZCB0aGVvcmV0aWNhbGx5IHdvcmsuCj4gPiBj
bHBzNzExeC1hdXRjcHUxMiBzaG91bGQgbm90IHdvcmsgaW4gdGhlIGFic2VuY2Ugb2YgbWVtYmxv
Y2tfcmVzZXJ2ZSgpLgo+ID4gY2xwczcxMXgtcDcyMHQgc2hvdWxkIG5vdCB3b3JrIGR1ZSB0byBw
aHlzaWNhbCBhZGRyZXNzIGxpbWl0YXRpb24gYXMgaQo+ID4gbm90aWNlZCBiZWZvcmUuIEJvYXJk
IG1lYW5zIHRvIHVzZSBTUkFNIGluc3RlYWQgb2YgU0RSQU0uCj4gPiBPbmx5IGNscHM3MTF4LWVk
YjcyMTEgc2hvdWxkIHdvcmsgZmluZSAoaW4gdGhlb3J5KS4KPiA+IElzIHRoaXMgYSBnb29kIHJl
YXNvbiB0byByZXBsYWNlIHRoZSBkcml2ZXI/IEkgdGhpbmsgeWVzLgo+IAo+IE9rLCBpZiB0aGUg
c2l0dWF0aW9uIGlzIHRoYXQgYmFkLCBtYXliZSB3ZSBjYW4ganVzdCBzd2l0Y2ggdG8gdGhlIG5l
dwo+IGRyaXZlci4gSGF2ZSB5b3UgdmVyaWZpZWQgdGhhdCB0aG9zZSBib2FyZHMgZG8gbm90IHdv
cmsgZnJvbSBhbnlvbmU/IE9yCj4gYXNrZWQgc29tZW9uZSB0byB0ZXN0IHRoZSBuZXcgZHJpdmVy
IHdpdGggdGhvc2UgYm9hcmRzPwoKSSdtIG5vdCBmYW1pbGlhciB3aXRoIG90aGVyIHVzZXJzIG9m
IHRoaXMgcGxhdGZvcm0gLgpJIGFtIGRvIG5vdCBoYXZlIHRoZXNlIGJvYXJkcywgYWxsIHRoYXQg
SSBoYXZlIHdyaXR0ZW4gYmVmb3JlIHRoYXQgaXQncyBqdXN0IGEgdGhlb3J5LgpGaXJtIGluIHdo
aWNoIEkgd29yaywgdXNlcyBpdHMgb3duIGJvYXJkIHdpdGggQ0xQUzcxMVggQ1BVICwgdGhpcyBi
b2FyZCBpcyB0aGUKb25seSB3YXkgdG8gY2hlY2sgZm9yIGNoYW5nZXMgb24gcmVhbCBoYXJkd2Fy
ZSAuCgo+IEknbSBzdGlsbCBub3QgcmVhbGx5IGhhcHB5IGFib3V0IGl0LCBhbmQgSSdkIG11Y2gg
cmF0aGVyIHNlZSB0aGUgY3VycmVudAo+IGRyaXZlciBmaXhlZC4gQnV0IGlmIG5vIG9uZSBoYXZp
bmcgdGhvc2UgYm9hcmRzIGlzIHVwIHRvIHRoZSB0YXNrCj4gKHByb2JhYmx5IG5vdCBpZiB0aGV5
IGhhdmUgbm90IGJlZW4gd29ya2luZyBhdCBhbGwpLCBtYXliZSBqdXN0IGRpdGNoaW5nCj4gdGhl
IG9sZCBkcml2ZXIgYW5kIGFkZGluZyBhIG5ldyBpcyB0aGUgb25seSB3YXkgZm9yd2FyZC4KPiAK
PiBPbmUgY2hhbmdlIHRoYXQgSSB0aGluayB3b3VsZCBiZSBnb29kIGlzIHRvIGNoYW5nZSB0aGUg
c2VyaWVzIHRvIGZpcnN0Cj4gcmVtb3ZlIHRoZSBvbGQgZHJpdmVyLCBhbmQgdGhlbiBhZGQgdGhl
IG5ldyBvbmUsIHdpdGggdGhlIHNhbWUgZmlsZSBuYW1lCj4gYXMgdGhlIG9sZCBvbmUuIFRoYXQg
d2F5IGdpdCBsb2cgd2lsbCBzaG93IHRoZSBoaXN0b3J5IGZvciBib3RoIHRoZSBuZXcKPiBhbmQg
dGhlIG9sZCBkcml2ZXIuCgpJbiB0aGlzIGNhc2UgZ2l0LWJpc2VjdCB3aWxsIGJlIGJyb2tlbi4g
SXMgdGhpcyBPSz8KCi0tLQoK
^ permalink raw reply
* [RFC 1/6] omapdss: remove check for simpler port/endpoint binding
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
The support for simpler port/endpoint binding was removed in the merged version
of omapdss DT. But dss_init_ports still tries to get to an endpoint even if no
port exists. Remove this as this doesn't work.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dss.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..31ef262 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -784,12 +784,8 @@ static int __init dss_init_ports(struct platform_device *pdev)
return 0;
port = omapdss_of_get_next_port(parent, NULL);
- if (!port) {
-#ifdef CONFIG_OMAP2_DSS_DPI
- dpi_init_port(pdev, parent);
-#endif
+ if (!port)
return 0;
- }
do {
u32 reg;
--
1.8.3.2
^ permalink raw reply related
* [RFC 2/6] omapdss: add init port functions for different omap revs
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
The init/uninit port functions are used to set up the DPI and SDI outputs under
the dss platform device. A 'reg' property is used to determine whether the node
is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
output exists.
For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
'reg' property to specify the DPI output number.
The current functions work fine if there is only one DPI output instance in
DSS. For multiple DPI instances, it would get complicated to figure out whether
'reg' is used to specify whether the output is SDI, or a later DPI instance.
Create DSS revision specific init/uninit_port functions such that we have a
separate functions for OMAP34xx, this helps us deal with the SDI case
separately.
Also, make the uninit_port functions iterative since we will have multiple DPI
ports in the future.
dpi_uninit_port/sdi_uninit_port functions have to be removed from the exit
section as dss_features(which is initconst data) uses it, this prevents the
section mismatch.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dpi.c | 2 +-
drivers/video/fbdev/omap2/dss/dss.c | 88 ++++++++++++++++++++++++++++++++++---
drivers/video/fbdev/omap2/dss/dss.h | 4 +-
drivers/video/fbdev/omap2/dss/sdi.c | 2 +-
4 files changed, 86 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c
index 157921d..6593c8b 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -765,7 +765,7 @@ err_datalines:
return r;
}
-void __exit dpi_uninit_port(void)
+void dpi_uninit_port(struct platform_device *pdev, struct device_node *port)
{
if (!dpi.port_initialized)
return;
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index 31ef262..c415029 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -65,12 +65,18 @@ struct dss_reg {
static int dss_runtime_get(void);
static void dss_runtime_put(void);
+static int __init dss_init_ports(struct platform_device *pdev);
+static int __init dss_init_ports_omap34xx(struct platform_device *pdev);
+static void dss_uninit_ports(struct platform_device *pdev);
+static void dss_uninit_ports_omap34xx(struct platform_device *pdev);
struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *parent_clk_name;
int (*dpi_select_source)(enum omap_channel channel);
+ int (*init_ports)(struct platform_device *pdev);
+ void (*uninit_ports)(struct platform_device *pdev);
};
static struct {
@@ -698,6 +704,8 @@ static const struct dss_features omap24xx_dss_feats __initconst = {
.dss_fck_multiplier = 2,
.parent_clk_name = "core_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static const struct dss_features omap34xx_dss_feats __initconst = {
@@ -705,6 +713,8 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
.dss_fck_multiplier = 2,
.parent_clk_name = "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .init_ports = &dss_init_ports_omap34xx,
+ .uninit_ports = &dss_uninit_ports_omap34xx,
};
static const struct dss_features omap3630_dss_feats __initconst = {
@@ -712,6 +722,8 @@ static const struct dss_features omap3630_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name = "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static const struct dss_features omap44xx_dss_feats __initconst = {
@@ -719,6 +731,8 @@ static const struct dss_features omap44xx_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name = "dpll_per_x2_ck",
.dpi_select_source = &dss_dpi_select_source_omap4,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static const struct dss_features omap54xx_dss_feats __initconst = {
@@ -726,6 +740,8 @@ static const struct dss_features omap54xx_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name = "dpll_per_x2_ck",
.dpi_select_source = &dss_dpi_select_source_omap5,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static int __init dss_init_features(struct platform_device *pdev)
@@ -774,7 +790,7 @@ static int __init dss_init_features(struct platform_device *pdev)
return 0;
}
-static int __init dss_init_ports(struct platform_device *pdev)
+static int __init dss_init_ports_omap34xx(struct platform_device *pdev)
{
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
@@ -809,15 +825,75 @@ static int __init dss_init_ports(struct platform_device *pdev)
return 0;
}
-static void dss_uninit_ports(void)
+static int __init dss_init_ports(struct platform_device *pdev)
{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *port;
+
+ if (parent = NULL)
+ return 0;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return 0;
+
+ do {
#ifdef CONFIG_OMAP2_DSS_DPI
- dpi_uninit_port();
+ dpi_init_port(pdev, port);
+#endif
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+
+ return 0;
+}
+
+static void dss_uninit_ports_omap34xx(struct platform_device *pdev)
+{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *port;
+ int r;
+
+ if (parent = NULL)
+ return;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return;
+
+ do {
+ u32 reg;
+
+ r = of_property_read_u32(port, "reg", ®);
+ if (r)
+ reg = 0;
+
+#ifdef CONFIG_OMAP2_DSS_DPI
+ if (reg = 0)
+ dpi_uninit_port(pdev, port);
#endif
#ifdef CONFIG_OMAP2_DSS_SDI
- sdi_uninit_port();
+ if (reg = 1)
+ sdi_uninit_port();
#endif
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+}
+
+static void dss_uninit_ports(struct platform_device *pdev)
+{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *port;
+
+ if (parent = NULL)
+ return;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return;
+ do {
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_uninit_port(pdev, port);
+#endif
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
}
/* DSS HW IP initialisation */
@@ -878,7 +954,7 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
- dss_init_ports(pdev);
+ dss.feat->init_ports(pdev);
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO "OMAP DSS rev %d.%d\n",
@@ -899,7 +975,7 @@ err_setup_clocks:
static int __exit omap_dsshw_remove(struct platform_device *pdev)
{
- dss_uninit_ports();
+ dss.feat->uninit_ports(pdev);
pm_runtime_disable(&pdev->dev);
diff --git a/drivers/video/fbdev/omap2/dss/dss.h b/drivers/video/fbdev/omap2/dss/dss.h
index 560078f..9f4ee49 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -245,7 +245,7 @@ int sdi_init_platform_driver(void) __init;
void sdi_uninit_platform_driver(void) __exit;
int sdi_init_port(struct platform_device *pdev, struct device_node *port) __init;
-void sdi_uninit_port(void) __exit;
+void sdi_uninit_port(void);
/* DSI */
@@ -359,7 +359,7 @@ int dpi_init_platform_driver(void) __init;
void dpi_uninit_platform_driver(void) __exit;
int dpi_init_port(struct platform_device *pdev, struct device_node *port) __init;
-void dpi_uninit_port(void) __exit;
+void dpi_uninit_port(struct platform_device *pdev, struct device_node *port);
/* DISPC */
int dispc_init_platform_driver(void) __init;
diff --git a/drivers/video/fbdev/omap2/dss/sdi.c b/drivers/video/fbdev/omap2/dss/sdi.c
index 911dcc9..71a3083 100644
--- a/drivers/video/fbdev/omap2/dss/sdi.c
+++ b/drivers/video/fbdev/omap2/dss/sdi.c
@@ -424,7 +424,7 @@ err_datapairs:
return r;
}
-void __exit sdi_uninit_port(void)
+void sdi_uninit_port(void)
{
if (!sdi.port_initialized)
return;
--
1.8.3.2
^ permalink raw reply related
* [RFC 3/6] omapdss: DT: Get source endpoint by matching reg-id
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
In omapdss_of_find_source_for_first_ep, we retrieve a source endpoint's DT node,
and then see what omapdss output has the matching device_node pointer in
omap_dss_find_output_by_node.
For all DPI and SDI outputs, the device_node pointer is set as the parent's DSS
device_node pointer. If the source is one of these outputs, the above method
won't work.
To get the correct output for ports within DSS with the existing omapdss DT
framework, we check in omapdss_of_find_source_for_first_ep, whether the source
node is of the DSS parent device. If so, we take an extra step of extracting
the 'reg' property from the port corresponding to the endpoint source, and get
the omap_dss_device output by matching both device_node and reg-id.
We would want to get rid of this eventually, and support multiple ports in
general. That would involve making some more changes the omapdss DT
framework.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dss-of.c | 41 ++++++++++++++++++++++++++++++----
drivers/video/fbdev/omap2/dss/dss.c | 6 +++++
drivers/video/fbdev/omap2/dss/dss.h | 2 ++
drivers/video/fbdev/omap2/dss/output.c | 15 +++++++++++++
include/video/omapdss.h | 6 +++++
5 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c b/drivers/video/fbdev/omap2/dss/dss-of.c
index a4b20aa..4261c14 100644
--- a/drivers/video/fbdev/omap2/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/dss/dss-of.c
@@ -19,6 +19,7 @@
#include <linux/seq_file.h>
#include <video/omapdss.h>
+#include "dss.h"
struct device_node *
omapdss_of_get_next_port(const struct device_node *parent,
@@ -142,12 +143,44 @@ omapdss_of_find_source_for_first_ep(struct device_node *node)
src_node = omapdss_of_get_remote_device_node(ep);
- of_node_put(ep);
-
- if (!src_node)
+ if (!src_node) {
+ of_node_put(ep);
return ERR_PTR(-EINVAL);
+ }
- src = omap_dss_find_output_by_node(src_node);
+ /*
+ * TODO: Find a better solution for this.
+ *
+ * DPI and SDI outputs share the same DSS device node. In order to find
+ * the correct omap_dss_device output, we need to match the reg-id
+ * property of the DPI/SDI port.
+ *
+ * For the special case of device_node being the parent DSS device, make
+ * sure we check for both device_node and reg-id to get the correct
+ * source
+ */
+ if (src_node = dss_device_node()) {
+ struct device_node *src_port;
+ u32 reg;
+ int r;
+
+ src_port = of_parse_phandle(ep, "remote-endpoint", 0);
+
+ /* the parent of the endpoint is always the port node */
+ src_port = of_get_next_parent(src_port);
+
+ r = of_property_read_u32(src_port, "reg", ®);
+ if (r)
+ reg = 0;
+
+ of_node_put(src_port);
+
+ src = omap_dss_find_output_by_node_and_reg(src_node, reg);
+ } else {
+ src = omap_dss_find_output_by_node(src_node);
+ }
+
+ of_node_put(ep);
of_node_put(src_node);
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index c415029..4087f3b 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -790,6 +790,12 @@ static int __init dss_init_features(struct platform_device *pdev)
return 0;
}
+/* of_node pointer for the DSS parent node */
+struct device_node *dss_device_node(void)
+{
+ return dss.pdev->dev.of_node;
+}
+
static int __init dss_init_ports_omap34xx(struct platform_device *pdev)
{
struct device_node *parent = pdev->dev.of_node;
diff --git a/drivers/video/fbdev/omap2/dss/dss.h b/drivers/video/fbdev/omap2/dss/dss.h
index 9f4ee49..6f68f72 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -240,6 +240,8 @@ typedef bool (*dss_div_calc_func)(unsigned long fck, void *data);
bool dss_div_calc(unsigned long pck, unsigned long fck_min,
dss_div_calc_func func, void *data);
+struct device_node *dss_device_node(void);
+
/* SDI */
int sdi_init_platform_driver(void) __init;
void sdi_uninit_platform_driver(void) __exit;
diff --git a/drivers/video/fbdev/omap2/dss/output.c b/drivers/video/fbdev/omap2/dss/output.c
index 2ab3afa..2b556f1 100644
--- a/drivers/video/fbdev/omap2/dss/output.c
+++ b/drivers/video/fbdev/omap2/dss/output.c
@@ -144,6 +144,21 @@ struct omap_dss_device *omap_dss_find_output_by_node(struct device_node *node)
}
EXPORT_SYMBOL(omap_dss_find_output_by_node);
+struct omap_dss_device
+ *omap_dss_find_output_by_node_and_reg(struct device_node *node,
+ u32 reg)
+{
+ struct omap_dss_device *out;
+
+ list_for_each_entry(out, &output_list, list) {
+ if (out->dev->of_node = node && out->reg = reg)
+ return omap_dss_get_device(out);
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL(omap_dss_find_output_by_node_and_reg);
+
struct omap_dss_device *omapdss_find_output_from_display(struct omap_dss_device *dssdev)
{
while (dssdev->src)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 6adb445..7ce2d83 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -789,6 +789,9 @@ struct omap_dss_device {
/* output instance */
enum omap_dss_output_id id;
+ /* the <reg> value in the DT node */
+ int reg;
+
/* dynamic fields */
struct omap_overlay_manager *manager;
@@ -909,6 +912,9 @@ void omapdss_unregister_output(struct omap_dss_device *output);
struct omap_dss_device *omap_dss_get_output(enum omap_dss_output_id id);
struct omap_dss_device *omap_dss_find_output(const char *name);
struct omap_dss_device *omap_dss_find_output_by_node(struct device_node *node);
+struct omap_dss_device
+ *omap_dss_find_output_by_node_and_reg(struct device_node *node,
+ u32 reg);
int omapdss_output_set_device(struct omap_dss_device *out,
struct omap_dss_device *dssdev);
int omapdss_output_unset_device(struct omap_dss_device *out);
--
1.8.3.2
^ permalink raw reply related
* [RFC 4/6] omapdss: DPI: support multiple DPI instances
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
SoCs containing DSS until now had only one DPI instance. DRA7x has 3 DPI
instances.
In order to support multiple instances, we allocate a driver data
struct(dpi_data) for each instance. This is somewhat similar to how DSI driver
was changed to support multiple instances.
One difference is that there are no platform devices for each instance when DT
is used. In the DT case, we store the dpi_data pointer in the DPI port's
(of the type struct device_node) data pointer. In the non DT case, we still
have dummy platform devices, and the device's private data pointer is used to
store the DPI instance's dpi_data.
When an encoder/panel driver calls a dpi op, we get dpi_data using the function
dpi_get_data_from_dssdev. This function iterates through the ports under DSS
device node, and returns the port which has reg-id matching the reg-id specified
in omap_dss_device.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dpi.c | 282 +++++++++++++++++++++++++-----------
1 file changed, 200 insertions(+), 82 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c
index 6593c8b..b891e17 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -37,7 +37,7 @@
#include "dss.h"
#include "dss_features.h"
-static struct {
+struct dpi_data {
struct platform_device *pdev;
struct regulator *vdds_dsi_reg;
@@ -52,7 +52,45 @@ static struct {
struct omap_dss_device output;
bool port_initialized;
-} dpi;
+};
+
+static struct dpi_data *dpi_get_data_from_dssdev(struct omap_dss_device *dssdev)
+{
+ struct device_node *parent = dssdev->dev->of_node;
+ struct device_node *port;
+
+ /* non DT */
+ if (!parent) {
+ struct omap_dss_device *out = dssdev->src;
+
+ return dev_get_drvdata(out->dev);
+ }
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return NULL;
+
+ do {
+ int r;
+ u32 reg;
+
+ r = of_property_read_u32(port, "reg", ®);
+ if (r)
+ reg = 0;
+
+ if (reg = dssdev->reg)
+ return port->data;
+
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+
+ return NULL;
+}
+
+/* use only for non DT mode */
+static struct dpi_data *dpi_get_data_from_pdev(struct platform_device *pdev)
+{
+ return dev_get_drvdata(&pdev->dev);
+}
static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
{
@@ -197,15 +235,16 @@ static bool dpi_calc_dss_cb(unsigned long fck, void *data)
dpi_calc_dispc_cb, ctx);
}
-static bool dpi_dsi_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
+static bool dpi_dsi_clk_calc(struct dpi_data *dpi, unsigned long pck,
+ struct dpi_clk_calc_ctx *ctx)
{
unsigned long clkin;
unsigned long pll_min, pll_max;
- clkin = dsi_get_pll_clkin(dpi.dsidev);
+ clkin = dsi_get_pll_clkin(dpi->dsidev);
memset(ctx, 0, sizeof(*ctx));
- ctx->dsidev = dpi.dsidev;
+ ctx->dsidev = dpi->dsidev;
ctx->pck_min = pck - 1000;
ctx->pck_max = pck + 1000;
ctx->dsi_cinfo.clkin = clkin;
@@ -213,7 +252,7 @@ static bool dpi_dsi_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
pll_min = 0;
pll_max = 0;
- return dsi_pll_calc(dpi.dsidev, clkin,
+ return dsi_pll_calc(dpi->dsidev, clkin,
pll_min, pll_max,
dpi_calc_pll_cb, ctx);
}
@@ -249,7 +288,7 @@ static bool dpi_dss_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
-static int dpi_set_dsi_clk(enum omap_channel channel,
+static int dpi_set_dsi_clk(struct dpi_data *dpi, enum omap_channel channel,
unsigned long pck_req, unsigned long *fck, int *lck_div,
int *pck_div)
{
@@ -257,18 +296,18 @@ static int dpi_set_dsi_clk(enum omap_channel channel,
int r;
bool ok;
- ok = dpi_dsi_clk_calc(pck_req, &ctx);
+ ok = dpi_dsi_clk_calc(dpi, pck_req, &ctx);
if (!ok)
return -EINVAL;
- r = dsi_pll_set_clock_div(dpi.dsidev, &ctx.dsi_cinfo);
+ r = dsi_pll_set_clock_div(dpi->dsidev, &ctx.dsi_cinfo);
if (r)
return r;
dss_select_lcd_clk_source(channel,
dpi_get_alt_clk_src(channel));
- dpi.mgr_config.clock_info = ctx.dispc_cinfo;
+ dpi->mgr_config.clock_info = ctx.dispc_cinfo;
*fck = ctx.dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
*lck_div = ctx.dispc_cinfo.lck_div;
@@ -277,8 +316,8 @@ static int dpi_set_dsi_clk(enum omap_channel channel,
return 0;
}
-static int dpi_set_dispc_clk(unsigned long pck_req, unsigned long *fck,
- int *lck_div, int *pck_div)
+static int dpi_set_dispc_clk(struct dpi_data *dpi, unsigned long pck_req,
+ unsigned long *fck, int *lck_div, int *pck_div)
{
struct dpi_clk_calc_ctx ctx;
int r;
@@ -292,7 +331,7 @@ static int dpi_set_dispc_clk(unsigned long pck_req, unsigned long *fck,
if (r)
return r;
- dpi.mgr_config.clock_info = ctx.dispc_cinfo;
+ dpi->mgr_config.clock_info = ctx.dispc_cinfo;
*fck = ctx.fck;
*lck_div = ctx.dispc_cinfo.lck_div;
@@ -301,19 +340,21 @@ static int dpi_set_dispc_clk(unsigned long pck_req, unsigned long *fck,
return 0;
}
-static int dpi_set_mode(struct omap_overlay_manager *mgr)
+static int dpi_set_mode(struct dpi_data *dpi)
{
- struct omap_video_timings *t = &dpi.timings;
+ struct omap_dss_device *out = &dpi->output;
+ struct omap_overlay_manager *mgr = out->manager;
+ struct omap_video_timings *t = &dpi->timings;
int lck_div = 0, pck_div = 0;
unsigned long fck = 0;
unsigned long pck;
int r = 0;
- if (dpi.dsidev)
- r = dpi_set_dsi_clk(mgr->id, t->pixelclock, &fck,
+ if (dpi->dsidev)
+ r = dpi_set_dsi_clk(dpi, mgr->id, t->pixelclock, &fck,
&lck_div, &pck_div);
else
- r = dpi_set_dispc_clk(t->pixelclock, &fck,
+ r = dpi_set_dispc_clk(dpi, t->pixelclock, &fck,
&lck_div, &pck_div);
if (r)
return r;
@@ -332,28 +373,32 @@ static int dpi_set_mode(struct omap_overlay_manager *mgr)
return 0;
}
-static void dpi_config_lcd_manager(struct omap_overlay_manager *mgr)
+static void dpi_config_lcd_manager(struct dpi_data *dpi)
{
- dpi.mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
+ struct omap_dss_device *out = &dpi->output;
+ struct omap_overlay_manager *mgr = out->manager;
- dpi.mgr_config.stallmode = false;
- dpi.mgr_config.fifohandcheck = false;
+ dpi->mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
- dpi.mgr_config.video_port_width = dpi.data_lines;
+ dpi->mgr_config.stallmode = false;
+ dpi->mgr_config.fifohandcheck = false;
- dpi.mgr_config.lcden_sig_polarity = 0;
+ dpi->mgr_config.video_port_width = dpi->data_lines;
- dss_mgr_set_lcd_config(mgr, &dpi.mgr_config);
+ dpi->mgr_config.lcden_sig_polarity = 0;
+
+ dss_mgr_set_lcd_config(mgr, &dpi->mgr_config);
}
static int dpi_display_enable(struct omap_dss_device *dssdev)
{
- struct omap_dss_device *out = &dpi.output;
+ struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
+ struct omap_dss_device *out = &dpi->output;
int r;
- mutex_lock(&dpi.lock);
+ mutex_lock(&dpi->lock);
- if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) && !dpi.vdds_dsi_reg) {
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) && !dpi->vdds_dsi_reg) {
DSSERR("no VDSS_DSI regulator\n");
r = -ENODEV;
goto err_no_reg;
@@ -366,7 +411,7 @@ static int dpi_display_enable(struct omap_dss_device *dssdev)
}
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)) {
- r = regulator_enable(dpi.vdds_dsi_reg);
+ r = regulator_enable(dpi->vdds_dsi_reg);
if (r)
goto err_reg_enable;
}
@@ -379,21 +424,21 @@ static int dpi_display_enable(struct omap_dss_device *dssdev)
if (r)
goto err_src_sel;
- if (dpi.dsidev) {
- r = dsi_runtime_get(dpi.dsidev);
+ if (dpi->dsidev) {
+ r = dsi_runtime_get(dpi->dsidev);
if (r)
goto err_get_dsi;
- r = dsi_pll_init(dpi.dsidev, 0, 1);
+ r = dsi_pll_init(dpi->dsidev, 0, 1);
if (r)
goto err_dsi_pll_init;
}
- r = dpi_set_mode(out->manager);
+ r = dpi_set_mode(dpi);
if (r)
goto err_set_mode;
- dpi_config_lcd_manager(out->manager);
+ dpi_config_lcd_manager(dpi);
mdelay(2);
@@ -401,78 +446,84 @@ static int dpi_display_enable(struct omap_dss_device *dssdev)
if (r)
goto err_mgr_enable;
- mutex_unlock(&dpi.lock);
+ mutex_unlock(&dpi->lock);
return 0;
err_mgr_enable:
err_set_mode:
- if (dpi.dsidev)
- dsi_pll_uninit(dpi.dsidev, true);
+ if (dpi->dsidev)
+ dsi_pll_uninit(dpi->dsidev, true);
err_dsi_pll_init:
- if (dpi.dsidev)
- dsi_runtime_put(dpi.dsidev);
+ if (dpi->dsidev)
+ dsi_runtime_put(dpi->dsidev);
err_get_dsi:
err_src_sel:
dispc_runtime_put();
err_get_dispc:
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
- regulator_disable(dpi.vdds_dsi_reg);
+ regulator_disable(dpi->vdds_dsi_reg);
err_reg_enable:
err_no_out_mgr:
err_no_reg:
- mutex_unlock(&dpi.lock);
+ mutex_unlock(&dpi->lock);
return r;
}
static void dpi_display_disable(struct omap_dss_device *dssdev)
{
- struct omap_overlay_manager *mgr = dpi.output.manager;
+ struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
+ struct omap_overlay_manager *mgr = dpi->output.manager;
- mutex_lock(&dpi.lock);
+ mutex_lock(&dpi->lock);
dss_mgr_disable(mgr);
- if (dpi.dsidev) {
+ if (dpi->dsidev) {
dss_select_lcd_clk_source(mgr->id, OMAP_DSS_CLK_SRC_FCK);
- dsi_pll_uninit(dpi.dsidev, true);
- dsi_runtime_put(dpi.dsidev);
+ dsi_pll_uninit(dpi->dsidev, true);
+ dsi_runtime_put(dpi->dsidev);
}
dispc_runtime_put();
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
- regulator_disable(dpi.vdds_dsi_reg);
+ regulator_disable(dpi->vdds_dsi_reg);
- mutex_unlock(&dpi.lock);
+ mutex_unlock(&dpi->lock);
}
static void dpi_set_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
+ struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
+
DSSDBG("dpi_set_timings\n");
- mutex_lock(&dpi.lock);
+ mutex_lock(&dpi->lock);
- dpi.timings = *timings;
+ dpi->timings = *timings;
- mutex_unlock(&dpi.lock);
+ mutex_unlock(&dpi->lock);
}
static void dpi_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
- mutex_lock(&dpi.lock);
+ struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
+
+ mutex_lock(&dpi->lock);
- *timings = dpi.timings;
+ *timings = dpi->timings;
- mutex_unlock(&dpi.lock);
+ mutex_unlock(&dpi->lock);
}
static int dpi_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
- struct omap_overlay_manager *mgr = dpi.output.manager;
+ struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
+ struct omap_overlay_manager *mgr = dpi->output.manager;
int lck_div, pck_div;
unsigned long fck;
unsigned long pck;
@@ -485,8 +536,8 @@ static int dpi_check_timings(struct omap_dss_device *dssdev,
if (timings->pixelclock = 0)
return -EINVAL;
- if (dpi.dsidev) {
- ok = dpi_dsi_clk_calc(timings->pixelclock, &ctx);
+ if (dpi->dsidev) {
+ ok = dpi_dsi_clk_calc(dpi, timings->pixelclock, &ctx);
if (!ok)
return -EINVAL;
@@ -511,11 +562,13 @@ static int dpi_check_timings(struct omap_dss_device *dssdev,
static void dpi_set_data_lines(struct omap_dss_device *dssdev, int data_lines)
{
- mutex_lock(&dpi.lock);
+ struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
- dpi.data_lines = data_lines;
+ mutex_lock(&dpi->lock);
- mutex_unlock(&dpi.lock);
+ dpi->data_lines = data_lines;
+
+ mutex_unlock(&dpi->lock);
}
static int dpi_verify_dsi_pll(struct platform_device *dsidev)
@@ -540,36 +593,36 @@ static int dpi_verify_dsi_pll(struct platform_device *dsidev)
return 0;
}
-static int dpi_init_regulator(void)
+static int dpi_init_regulator(struct dpi_data *dpi)
{
struct regulator *vdds_dsi;
if (!dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
return 0;
- if (dpi.vdds_dsi_reg)
+ if (dpi->vdds_dsi_reg)
return 0;
- vdds_dsi = devm_regulator_get(&dpi.pdev->dev, "vdds_dsi");
+ vdds_dsi = devm_regulator_get(&dpi->pdev->dev, "vdds_dsi");
if (IS_ERR(vdds_dsi)) {
if (PTR_ERR(vdds_dsi) != -EPROBE_DEFER)
DSSERR("can't get VDDS_DSI regulator\n");
return PTR_ERR(vdds_dsi);
}
- dpi.vdds_dsi_reg = vdds_dsi;
+ dpi->vdds_dsi_reg = vdds_dsi;
return 0;
}
-static void dpi_init_pll(void)
+static void dpi_init_pll(struct dpi_data *dpi)
{
struct platform_device *dsidev;
- if (dpi.dsidev)
+ if (dpi->dsidev)
return;
- dsidev = dpi_get_dsidev(dpi.output.dispc_channel);
+ dsidev = dpi_get_dsidev(dpi->output.dispc_channel);
if (!dsidev)
return;
@@ -578,7 +631,7 @@ static void dpi_init_pll(void)
return;
}
- dpi.dsidev = dsidev;
+ dpi->dsidev = dsidev;
}
/*
@@ -614,14 +667,15 @@ static enum omap_channel dpi_get_channel(void)
static int dpi_connect(struct omap_dss_device *dssdev,
struct omap_dss_device *dst)
{
+ struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
struct omap_overlay_manager *mgr;
int r;
- r = dpi_init_regulator();
+ r = dpi_init_regulator(dpi);
if (r)
return r;
- dpi_init_pll();
+ dpi_init_pll(dpi);
mgr = omap_dss_get_overlay_manager(dssdev->dispc_channel);
if (!mgr)
@@ -672,7 +726,8 @@ static const struct omapdss_dpi_ops dpi_ops = {
static void dpi_init_output(struct platform_device *pdev)
{
- struct omap_dss_device *out = &dpi.output;
+ struct dpi_data *dpi = dpi_get_data_from_pdev(pdev);
+ struct omap_dss_device *out = &dpi->output;
out->dev = &pdev->dev;
out->id = OMAP_DSS_OUTPUT_DPI;
@@ -685,18 +740,72 @@ static void dpi_init_output(struct platform_device *pdev)
omapdss_register_output(out);
}
+static void dpi_init_output_port(struct platform_device *pdev,
+ struct device_node *port)
+{
+ struct dpi_data *dpi = port->data;
+ struct omap_dss_device *out = &dpi->output;
+ int r;
+ u32 reg;
+
+ r = of_property_read_u32(port, "reg", ®);
+ if (r)
+ reg = 0;
+
+ switch (reg) {
+ case 2:
+ out->name = "dpi.2";
+ break;
+ case 1:
+ out->name = "dpi.1";
+ break;
+ case 0:
+ default:
+ out->name = "dpi.0";
+ break;
+ }
+
+ out->dev = &pdev->dev;
+ out->id = OMAP_DSS_OUTPUT_DPI;
+ out->output_type = OMAP_DISPLAY_TYPE_DPI;
+ out->dispc_channel = dpi_get_channel();
+ out->ops.dpi = &dpi_ops;
+ out->reg = reg;
+ out->owner = THIS_MODULE;
+
+ omapdss_register_output(out);
+}
+
static void __exit dpi_uninit_output(struct platform_device *pdev)
{
- struct omap_dss_device *out = &dpi.output;
+ struct dpi_data *dpi = dpi_get_data_from_pdev(pdev);
+ struct omap_dss_device *out = &dpi->output;
+
+ omapdss_unregister_output(out);
+}
+
+static void dpi_uninit_output_port(struct platform_device *pdev,
+ struct device_node *port)
+{
+ struct dpi_data *dpi = port->data;
+ struct omap_dss_device *out = &dpi->output;
omapdss_unregister_output(out);
}
static int omap_dpi_probe(struct platform_device *pdev)
{
- dpi.pdev = pdev;
+ struct dpi_data *dpi;
+
+ dpi = devm_kzalloc(&pdev->dev, sizeof(*dpi), GFP_KERNEL);
+ if (!dpi)
+ return -ENOMEM;
+
+ dpi->pdev = pdev;
+
+ dev_set_drvdata(&pdev->dev, dpi);
- mutex_init(&dpi.lock);
+ mutex_init(&dpi->lock);
dpi_init_output(pdev);
@@ -731,10 +840,15 @@ void __exit dpi_uninit_platform_driver(void)
int __init dpi_init_port(struct platform_device *pdev, struct device_node *port)
{
+ struct dpi_data *dpi;
struct device_node *ep;
u32 datalines;
int r;
+ dpi = devm_kzalloc(&pdev->dev, sizeof(*dpi), GFP_KERNEL);
+ if (!dpi)
+ return -ENOMEM;
+
ep = omapdss_of_get_next_endpoint(port, NULL);
if (!ep)
return 0;
@@ -745,17 +859,19 @@ int __init dpi_init_port(struct platform_device *pdev, struct device_node *port)
goto err_datalines;
}
- dpi.data_lines = datalines;
-
of_node_put(ep);
- dpi.pdev = pdev;
+ dpi->data_lines = datalines;
- mutex_init(&dpi.lock);
+ port->data = dpi;
- dpi_init_output(pdev);
+ dpi->pdev = pdev;
- dpi.port_initialized = true;
+ mutex_init(&dpi->lock);
+
+ dpi_init_output_port(pdev, port);
+
+ dpi->port_initialized = true;
return 0;
@@ -767,8 +883,10 @@ err_datalines:
void dpi_uninit_port(struct platform_device *pdev, struct device_node *port)
{
- if (!dpi.port_initialized)
+ struct dpi_data *dpi = port->data;
+
+ if (!dpi->port_initialized)
return;
- dpi_uninit_output(dpi.pdev);
+ dpi_uninit_output_port(pdev, port);
}
--
1.8.3.2
^ permalink raw reply related
* [RFC 5/6] omapdss: DPI: make dpi_get_channel take DPI reg-id
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
To support multiple DPI instances, dpi_get_channel needs to take the DPI
instance's reg-id to get the corresponding channel. Make it take this
argument.
We just pass 0 in the non-DT path, since we don't support multiple instances
in the non-DT case.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dpi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c
index b891e17..faf266e 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -640,7 +640,7 @@ static void dpi_init_pll(struct dpi_data *dpi)
* the channel in some more dynamic manner, or get the channel as a user
* parameter.
*/
-static enum omap_channel dpi_get_channel(void)
+static enum omap_channel dpi_get_channel(int reg)
{
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
@@ -733,7 +733,7 @@ static void dpi_init_output(struct platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_DPI;
out->output_type = OMAP_DISPLAY_TYPE_DPI;
out->name = "dpi.0";
- out->dispc_channel = dpi_get_channel();
+ out->dispc_channel = dpi_get_channel(0);
out->ops.dpi = &dpi_ops;
out->owner = THIS_MODULE;
@@ -768,7 +768,7 @@ static void dpi_init_output_port(struct platform_device *pdev,
out->dev = &pdev->dev;
out->id = OMAP_DSS_OUTPUT_DPI;
out->output_type = OMAP_DISPLAY_TYPE_DPI;
- out->dispc_channel = dpi_get_channel();
+ out->dispc_channel = dpi_get_channel(reg);
out->ops.dpi = &dpi_ops;
out->reg = reg;
out->owner = THIS_MODULE;
--
1.8.3.2
^ permalink raw reply related
* [RFC 6/6] omapdss: DSS: add reg-id param to dpi_select_source
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
Add an argument which describes which DPI instance we are referring to when
selecting it's overlay manager. This will come into use when a DSS version
supports multiple DPI instances.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dpi.c | 2 +-
drivers/video/fbdev/omap2/dss/dss.c | 12 ++++++------
drivers/video/fbdev/omap2/dss/dss.h | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c
index faf266e..def8e68 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -420,7 +420,7 @@ static int dpi_display_enable(struct omap_dss_device *dssdev)
if (r)
goto err_get_dispc;
- r = dss_dpi_select_source(out->manager->id);
+ r = dss_dpi_select_source(out->reg, out->manager->id);
if (r)
goto err_src_sel;
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index 4087f3b..ffa6d84 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -74,7 +74,7 @@ struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *parent_clk_name;
- int (*dpi_select_source)(enum omap_channel channel);
+ int (*dpi_select_source)(int id, enum omap_channel channel);
int (*init_ports)(struct platform_device *pdev);
void (*uninit_ports)(struct platform_device *pdev);
};
@@ -570,7 +570,7 @@ enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void)
return REG_GET(DSS_CONTROL, 15, 15);
}
-static int dss_dpi_select_source_omap2_omap3(enum omap_channel channel)
+static int dss_dpi_select_source_omap2_omap3(int id, enum omap_channel channel)
{
if (channel != OMAP_DSS_CHANNEL_LCD)
return -EINVAL;
@@ -578,7 +578,7 @@ static int dss_dpi_select_source_omap2_omap3(enum omap_channel channel)
return 0;
}
-static int dss_dpi_select_source_omap4(enum omap_channel channel)
+static int dss_dpi_select_source_omap4(int id, enum omap_channel channel)
{
int val;
@@ -598,7 +598,7 @@ static int dss_dpi_select_source_omap4(enum omap_channel channel)
return 0;
}
-static int dss_dpi_select_source_omap5(enum omap_channel channel)
+static int dss_dpi_select_source_omap5(int id, enum omap_channel channel)
{
int val;
@@ -624,9 +624,9 @@ static int dss_dpi_select_source_omap5(enum omap_channel channel)
return 0;
}
-int dss_dpi_select_source(enum omap_channel channel)
+int dss_dpi_select_source(int id, enum omap_channel channel)
{
- return dss.feat->dpi_select_source(channel);
+ return dss.feat->dpi_select_source(id, channel);
}
static int dss_get_clocks(void)
diff --git a/drivers/video/fbdev/omap2/dss/dss.h b/drivers/video/fbdev/omap2/dss/dss.h
index 6f68f72..f3ddcc9 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -209,7 +209,7 @@ int dss_init_platform_driver(void) __init;
void dss_uninit_platform_driver(void);
unsigned long dss_get_dispc_clk_rate(void);
-int dss_dpi_select_source(enum omap_channel channel);
+int dss_dpi_select_source(int id, enum omap_channel channel);
void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
const char *dss_get_generic_clk_source_name(enum omap_dss_clk_source clk_src);
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v2 2/3] ARM: dts: oma3-gta04: Add display support
From: Tomi Valkeinen @ 2014-05-08 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv36L_vh+iwrqsePsF8oOxOJ=JXUAk2nJ6F120w+0ivAn8w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
On 07/05/14 10:21, Belisko Marek wrote:
>> Did you try this on 3.15-rc? The above is not right, and I don't think
>> it works. You need 'port' node for the dpi_out endpoint.
> This patches was tested against 3.15 series and it works. I'l recheck.
Ah, we still have some code that makes that work. But it's against the
bindings documentations, and that code will be removed. So better add
the port node.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-08 10:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]
On 08/05/14 11:27, Alexander Shiyan wrote:
>>> At this time the driver has three user.
>>> Only one of them should theoretically work.
>>> clps711x-autcpu12 should not work in the absence of memblock_reserve().
>>> clps711x-p720t should not work due to physical address limitation as i
>>> noticed before. Board means to use SRAM instead of SDRAM.
>>> Only clps711x-edb7211 should work fine (in theory).
>>> Is this a good reason to replace the driver? I think yes.
>>
>> Ok, if the situation is that bad, maybe we can just switch to the new
>> driver. Have you verified that those boards do not work from anyone? Or
>> asked someone to test the new driver with those boards?
>
> I'm not familiar with other users of this platform .
> I am do not have these boards, all that I have written before that it's just a theory.
> Firm in which I work, uses its own board with CLPS711X CPU , this board is the
> only way to check for changes on real hardware .
Ok. That makes me a bit nervous... You're removing a driver, which may
(or may not) have been working for other users. And adding a new one,
which may not (or may) work for the other users.
>> I'm still not really happy about it, and I'd much rather see the current
>> driver fixed. But if no one having those boards is up to the task
>> (probably not if they have not been working at all), maybe just ditching
>> the old driver and adding a new is the only way forward.
>>
>> One change that I think would be good is to change the series to first
>> remove the old driver, and then add the new one, with the same file name
>> as the old one. That way git log will show the history for both the new
>> and the old driver.
>
> In this case git-bisect will be broken. Is this OK?
I think this is such a big change for the users of the driver that it's
not an issue. Of course, kernel should still build at all steps, but I
think it's fine if the fb driver in question will be out for a commit or
two.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7][ 1/5] video: mx3fb: Use devm_kzalloc
From: Tomi Valkeinen @ 2014-05-08 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394788369-5096-1-git-send-email-denis@eukrea.com>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On 14/03/14 11:12, Denis Carikli wrote:
> Replace kzalloc by devm_kzalloc and remove the kfree() calls.
>
> Signed-off-by: Denis Carikli <denis@eukrea.com>
> ---
> ChangeLog v6->v7:
> - Removed the Cc from the patch, they went into
> git send-email instead.
> ChangeLog v5->v6:
> - New patch need
> ---
> drivers/video/fbdev/mx3fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
I've picked this patch for 3.16. I didn't pick the DT related patches in
this series as there seemed to be unanswered questions about them.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: exynos: Add a dependency to the menu
From: Tomi Valkeinen @ 2014-05-08 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140408120056.57556a00@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
On 08/04/14 13:00, Jean Delvare wrote:
> All drivers under menu EXYNOS_VIDEO depend on either ARCH_S5PV210 or
> ARCH_EXYNOS, so add these as dependencies to the menu itself. This
> avoids presenting an empty and useless menu on other architectures.
>
> Then drivers under the menu only need a dependency if they depend on
> one of the supported architectures specifically.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> ---
> drivers/video/exynos/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-3.15-rc0.orig/drivers/video/exynos/Kconfig 2014-04-07 10:23:07.316226676 +0200
> +++ linux-3.15-rc0/drivers/video/exynos/Kconfig 2014-04-08 11:50:17.406723187 +0200
> @@ -4,6 +4,7 @@
>
> menuconfig EXYNOS_VIDEO
> bool "Exynos Video driver support"
> + depends on ARCH_S5PV210 || ARCH_EXYNOS
> help
> This enables support for EXYNOS Video device.
>
> @@ -15,7 +16,6 @@ if EXYNOS_VIDEO
>
> config EXYNOS_MIPI_DSI
> bool "EXYNOS MIPI DSI driver support."
> - depends on ARCH_S5PV210 || ARCH_EXYNOS
> select GENERIC_PHY
> help
> This enables support for MIPI-DSI device.
>
>
I've applied this for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] video: mx3fb: Add backlight support
From: Tomi Valkeinen @ 2014-05-08 10:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1399273010-24706-1-git-send-email-alexander.stein@systec-electronic.com>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
Hi,
On 05/05/14 09:56, Alexander Stein wrote:
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
Please always have a commit description, even if it's more or less the
same as the subject.
Is the backlight PWM hardware part of the display hardware on mx3fb? If
so, I guess it's ok to have the backlight in the fb driver, as you're
doing here.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] video: mx3fb: Add backlight support
From: Tomi Valkeinen @ 2014-05-08 10:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1399273010-24706-1-git-send-email-alexander.stein@systec-electronic.com>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On 08/05/14 13:47, Tomi Valkeinen wrote:
> Hi,
>
> On 05/05/14 09:56, Alexander Stein wrote:
>> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
>> ---
>
> Please always have a commit description, even if it's more or less the
> same as the subject.
Oh, and I'd rather have a bit more explanation than "add backlight
support". The current driver seems to have some backlight code. So what
are you actually adding with this patch? Etc.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox