OMAPDSS and panel-dpi

OMAPDSS and panel-dpi

[Joachim Eastwood]

Hi Tomi,

My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
now working (thanks) I also taken a look at panel-dpi.

I found the DT patch for panel-dpi on the mailing list.
OMAPDSS: panel-dpi: Add DT support:
http://marc.info/?l=devicetree&m=139030201815380&w=2

And I got my display working with DT :)
So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>

Could you upstream the panel-dpi DT support and the HDMI connector
gpio hpd patch in 3.16?
I hope it's easier to upstream the stuff when it gets some users in DT.

I will soon post my updated patches for the Variscite STK and DVK
boards, but for the display stuff to work they depend on the patches
mention above. It would also be nice if you could take a look at the
DT display nodes so I'll CC you on the set.

regards
Joachim Eastwood

Re: OMAPDSS and panel-dpi

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140417 11:05]:
> Hi Tomi,
> 
> My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
> now working (thanks) I also taken a look at panel-dpi.
> 
> I found the DT patch for panel-dpi on the mailing list.
> OMAPDSS: panel-dpi: Add DT support:
> http://marc.info/?l=devicetree&m=139030201815380&w=2
> 
> And I got my display working with DT :)
> So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>
> 
> Could you upstream the panel-dpi DT support and the HDMI connector
> gpio hpd patch in 3.16?
> I hope it's easier to upstream the stuff when it gets some users in DT.

Good to hear. The DPI panel support should use gpio-backlight
driver as discussed in the DPI thread. Did you have to patch
anything for the timings etc?

If you have the board working, care to take a look at making
the gpio-backlight change?

Otherwise we'll be creating unncessary churn and maintainer
headaches with patching half a dozen DPI using boards to change
them over to use gpio-backlight.

Regards,

Tony

Re: OMAPDSS and panel-dpi

[Joachim Eastwood]

On 17 April 2014 21:22, Tony Lindgren <tony@atomide.com> wrote:
> * Joachim Eastwood <manabian@gmail.com> [140417 11:05]:
>> Hi Tomi,
>>
>> My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
>> now working (thanks) I also taken a look at panel-dpi.
>>
>> I found the DT patch for panel-dpi on the mailing list.
>> OMAPDSS: panel-dpi: Add DT support:
>> http://marc.info/?l=devicetree&m=139030201815380&w=2
>>
>> And I got my display working with DT :)
>> So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>
>>
>> Could you upstream the panel-dpi DT support and the HDMI connector
>> gpio hpd patch in 3.16?
>> I hope it's easier to upstream the stuff when it gets some users in DT.
>
> Good to hear. The DPI panel support should use gpio-backlight
> driver as discussed in the DPI thread. Did you have to patch
> anything for the timings etc?

The only driver patches I use are those two from Tomi mentioned above.
(panel-dpi DT support and HDMI connector gpio-hpd)
> If you have the board working, care to take a look at making
> the gpio-backlight change?

I am already using the gpio-backlight driver.

You can take a look at the device tree for VAR-DVK-OM44 here:
http://slexy.org/raw/s2Pz4BELGe

I'll post the patch set on list tomorrow.

regards
Joachim Eastwood

Re: OMAPDSS and panel-dpi

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140417 13:51]:
> On 17 April 2014 21:22, Tony Lindgren <tony@atomide.com> wrote:
> > * Joachim Eastwood <manabian@gmail.com> [140417 11:05]:
> >> Hi Tomi,
> >>
> >> My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
> >> now working (thanks) I also taken a look at panel-dpi.
> >>
> >> I found the DT patch for panel-dpi on the mailing list.
> >> OMAPDSS: panel-dpi: Add DT support:
> >> http://marc.info/?l=devicetree&m=139030201815380&w=2
> >>
> >> And I got my display working with DT :)
> >> So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>
> >>
> >> Could you upstream the panel-dpi DT support and the HDMI connector
> >> gpio hpd patch in 3.16?
> >> I hope it's easier to upstream the stuff when it gets some users in DT.
> >
> > Good to hear. The DPI panel support should use gpio-backlight
> > driver as discussed in the DPI thread. Did you have to patch
> > anything for the timings etc?
> 
> The only driver patches I use are those two from Tomi mentioned above.
> (panel-dpi DT support and HDMI connector gpio-hpd)
>
> > If you have the board working, care to take a look at making
> > the gpio-backlight change?
> 
> I am already using the gpio-backlight driver.

OK great, so then we can just drop that GPIO backlight handling
from the DPI DT patch I presume.
 
> You can take a look at the device tree for VAR-DVK-OM44 here:
> http://slexy.org/raw/s2Pz4BELGe
> 
> I'll post the patch set on list tomorrow.

Thanks for the link, that pretty much clarifies all the parts
I was wondering about.

Regards,

Tony

Re: OMAPDSS and panel-dpi

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140417 15:50]:
> * Joachim Eastwood <manabian@gmail.com> [140417 13:51]:
> > On 17 April 2014 21:22, Tony Lindgren <tony@atomide.com> wrote:
> > > * Joachim Eastwood <manabian@gmail.com> [140417 11:05]:
> > >> Hi Tomi,
> > >>
> > >> My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
> > >> now working (thanks) I also taken a look at panel-dpi.
> > >>
> > >> I found the DT patch for panel-dpi on the mailing list.
> > >> OMAPDSS: panel-dpi: Add DT support:
> > >> http://marc.info/?l=devicetree&m=139030201815380&w=2
> > >>
> > >> And I got my display working with DT :)
> > >> So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>
> > >>
> > >> Could you upstream the panel-dpi DT support and the HDMI connector
> > >> gpio hpd patch in 3.16?
> > >> I hope it's easier to upstream the stuff when it gets some users in DT.
> > >
> > > Good to hear. The DPI panel support should use gpio-backlight
> > > driver as discussed in the DPI thread. Did you have to patch
> > > anything for the timings etc?
> > 
> > The only driver patches I use are those two from Tomi mentioned above.
> > (panel-dpi DT support and HDMI connector gpio-hpd)
> >
> > > If you have the board working, care to take a look at making
> > > the gpio-backlight change?
> > 
> > I am already using the gpio-backlight driver.
> 
> OK great, so then we can just drop that GPIO backlight handling
> from the DPI DT patch I presume.
>  
> > You can take a look at the device tree for VAR-DVK-OM44 here:
> > http://slexy.org/raw/s2Pz4BELGe
> > 
> > I'll post the patch set on list tomorrow.
> 
> Thanks for the link, that pretty much clarifies all the parts
> I was wondering about.

OK so based on the link above, I got the LDP panel DPI working with
the quirks now shrunk to the two panel specific GPIOs.

Probably best to set those up based on "omapdss,panel-dpi-ldp"
compatible flag?

That is after removing the backlight_gpio from panel_dpi_probe_of()
so the panel specific GPIOs can be handled easily based on the
compatible flag. Current work in progress patch below for reference
in case anybody has better ideas for dealing with the remaining
to GPIOs.

Regards,

Tony

8< ----------------------
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -25,6 +25,10 @@
 		};
 	};
 
+	aliases {
+		display0 = &lcd0;
+	};
+
 	gpio_keys {
 		compatible = "gpio-keys";
 		pinctrl-names = "default";
@@ -93,6 +97,50 @@
 			gpio-key,wakeup;
 		};
 	};
+
+	lcd0: display {
+		compatible = "panel-dpi";
+		label = "lcd";
+		gpios = <&twl_gpio 7 GPIO_ACTIVE_LOW>;
+
+		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>;
+			};
+		};
+	};
+
+	backlight {
+		compatible = "gpio-backlight";
+		gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&dss {
+	status = "ok";
+
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&lcd_in>;
+			data-lines = <18>;
+		};
+	};
 };
 
 &gpmc {
@@ -249,6 +297,6 @@
 };
 
 &vpll2 {
-       /* Needed for DSS */
-       regulator-name = "vdds_dsi";
+	/* Needed for DSS */
+	regulator-name = "vdds_dsi";
 };
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -148,6 +148,30 @@ static void __init omap3_evm_legacy_init(void)
 	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
 }
 
+int __init ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
+{
+	int r;
+
+	static struct gpio gpios[] = {
+		{ 55, GPIOF_OUT_INIT_HIGH, "LCD RESET" },
+		{ 56, 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 r;
+	}
+	omap_ads7846_init(1, 54, 310, NULL);
+
+	return 0;
+}
+
+static void __init omap3_ldp_legacy_init(void)
+{
+	twl_gpio_auxdata.setup = ldp_twl_gpio_setup;
+}
+
 static void __init omap3_zoom_legacy_init(void)
 {
 	legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
@@ -358,6 +382,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
 	{ "nokia,omap3-n950", hsmmc2_internal_input_clk, },
 	{ "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
 	{ "ti,omap3-evm-37xx", omap3_evm_legacy_init, },
+	{ "ti,omap3-ldp", omap3_ldp_legacy_init, },
 	{ "ti,omap3-zoom3", omap3_zoom_legacy_init, },
 	{ "ti,am3517-evm", am3517_evm_legacy_init, },
 #endif

Re: OMAPDSS and panel-dpi

[Joachim Eastwood]

On 18 April 2014 04:50, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [140417 15:50]:
>> * Joachim Eastwood <manabian@gmail.com> [140417 13:51]:
>> > On 17 April 2014 21:22, Tony Lindgren <tony@atomide.com> wrote:
>> > > * Joachim Eastwood <manabian@gmail.com> [140417 11:05]:
>> > >> Hi Tomi,
>> > >>
>> > >> My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
>> > >> now working (thanks) I also taken a look at panel-dpi.
>> > >>
>> > >> I found the DT patch for panel-dpi on the mailing list.
>> > >> OMAPDSS: panel-dpi: Add DT support:
>> > >> http://marc.info/?l=devicetree&m=139030201815380&w=2
>> > >>
>> > >> And I got my display working with DT :)
>> > >> So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>
>> > >>
>> > >> Could you upstream the panel-dpi DT support and the HDMI connector
>> > >> gpio hpd patch in 3.16?
>> > >> I hope it's easier to upstream the stuff when it gets some users in DT.
>> > >
>> > > Good to hear. The DPI panel support should use gpio-backlight
>> > > driver as discussed in the DPI thread. Did you have to patch
>> > > anything for the timings etc?
>> >
>> > The only driver patches I use are those two from Tomi mentioned above.
>> > (panel-dpi DT support and HDMI connector gpio-hpd)
>> >
>> > > If you have the board working, care to take a look at making
>> > > the gpio-backlight change?
>> >
>> > I am already using the gpio-backlight driver.
>>
>> OK great, so then we can just drop that GPIO backlight handling
>> from the DPI DT patch I presume.
>>
>> > You can take a look at the device tree for VAR-DVK-OM44 here:
>> > http://slexy.org/raw/s2Pz4BELGe
>> >
>> > I'll post the patch set on list tomorrow.
>>
>> Thanks for the link, that pretty much clarifies all the parts
>> I was wondering about.
>
> OK so based on the link above, I got the LDP panel DPI working with
> the quirks now shrunk to the two panel specific GPIOs.
>
> Probably best to set those up based on "omapdss,panel-dpi-ldp"
> compatible flag?
>
> That is after removing the backlight_gpio from panel_dpi_probe_of()
> so the panel specific GPIOs can be handled easily based on the
> compatible flag. Current work in progress patch below for reference
> in case anybody has better ideas for dealing with the remaining
> to GPIOs.

A reset gpio could be useful on more panels I think.
omapdss,panel-dsi-cm already have a reset-gpios property so maybe
omapdss,panel-dpi should have one too.

A lot of panels have mode pins, but usually these are hard coded on
the circuit board.
If it's just a bunch of static gpio values that need to be set maybe
you could have something like this:
mode-gpios = <&gpio1 10 0 &gpio1 11 0>;
mode-gpios-values = <1 1>;

Driver would set these gpios to values at init.

regards
Joachim Eastwood

> Regards,
>
> Tony
>
> 8< ----------------------
> --- a/arch/arm/boot/dts/omap3-ldp.dts
> +++ b/arch/arm/boot/dts/omap3-ldp.dts
> @@ -25,6 +25,10 @@
>                 };
>         };
>
> +       aliases {
> +               display0 = &lcd0;
> +       };
> +
>         gpio_keys {
>                 compatible = "gpio-keys";
>                 pinctrl-names = "default";
> @@ -93,6 +97,50 @@
>                         gpio-key,wakeup;
>                 };
>         };
> +
> +       lcd0: display {
> +               compatible = "panel-dpi";
> +               label = "lcd";
> +               gpios = <&twl_gpio 7 GPIO_ACTIVE_LOW>;
> +
> +               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>;
> +                       };
> +               };
> +       };
> +
> +       backlight {
> +               compatible = "gpio-backlight";
> +               gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
> +       };
> +};
> +
> +&dss {
> +       status = "ok";
> +
> +       port {
> +               dpi_out: endpoint {
> +                       remote-endpoint = <&lcd_in>;
> +                       data-lines = <18>;
> +               };
> +       };
>  };
>
>  &gpmc {
> @@ -249,6 +297,6 @@
>  };
>
>  &vpll2 {
> -       /* Needed for DSS */
> -       regulator-name = "vdds_dsi";
> +       /* Needed for DSS */
> +       regulator-name = "vdds_dsi";
>  };
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -148,6 +148,30 @@ static void __init omap3_evm_legacy_init(void)
>         legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
>  }
>
> +int __init ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
> +{
> +       int r;
> +
> +       static struct gpio gpios[] = {
> +               { 55, GPIOF_OUT_INIT_HIGH, "LCD RESET" },
> +               { 56, 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 r;
> +       }
> +       omap_ads7846_init(1, 54, 310, NULL);
> +
> +       return 0;
> +}
> +
> +static void __init omap3_ldp_legacy_init(void)
> +{
> +       twl_gpio_auxdata.setup = ldp_twl_gpio_setup;
> +}
> +
>  static void __init omap3_zoom_legacy_init(void)
>  {
>         legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
> @@ -358,6 +382,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
>         { "nokia,omap3-n950", hsmmc2_internal_input_clk, },
>         { "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
>         { "ti,omap3-evm-37xx", omap3_evm_legacy_init, },
> +       { "ti,omap3-ldp", omap3_ldp_legacy_init, },
>         { "ti,omap3-zoom3", omap3_zoom_legacy_init, },
>         { "ti,am3517-evm", am3517_evm_legacy_init, },
>  #endif

Re: OMAPDSS and panel-dpi

[Tony Lindgren]

* Joachim Eastwood <manabian@gmail.com> [140418 04:05]:
> On 18 April 2014 04:50, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [140417 15:50]:
> >> * Joachim Eastwood <manabian@gmail.com> [140417 13:51]:
> >> > On 17 April 2014 21:22, Tony Lindgren <tony@atomide.com> wrote:
> >> > > * Joachim Eastwood <manabian@gmail.com> [140417 11:05]:
> >> > >> Hi Tomi,
> >> > >>
> >> > >> My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
> >> > >> now working (thanks) I also taken a look at panel-dpi.
> >> > >>
> >> > >> I found the DT patch for panel-dpi on the mailing list.
> >> > >> OMAPDSS: panel-dpi: Add DT support:
> >> > >> http://marc.info/?l=devicetree&m=139030201815380&w=2
> >> > >>
> >> > >> And I got my display working with DT :)
> >> > >> So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>
> >> > >>
> >> > >> Could you upstream the panel-dpi DT support and the HDMI connector
> >> > >> gpio hpd patch in 3.16?
> >> > >> I hope it's easier to upstream the stuff when it gets some users in DT.
> >> > >
> >> > > Good to hear. The DPI panel support should use gpio-backlight
> >> > > driver as discussed in the DPI thread. Did you have to patch
> >> > > anything for the timings etc?
> >> >
> >> > The only driver patches I use are those two from Tomi mentioned above.
> >> > (panel-dpi DT support and HDMI connector gpio-hpd)
> >> >
> >> > > If you have the board working, care to take a look at making
> >> > > the gpio-backlight change?
> >> >
> >> > I am already using the gpio-backlight driver.
> >>
> >> OK great, so then we can just drop that GPIO backlight handling
> >> from the DPI DT patch I presume.
> >>
> >> > You can take a look at the device tree for VAR-DVK-OM44 here:
> >> > http://slexy.org/raw/s2Pz4BELGe
> >> >
> >> > I'll post the patch set on list tomorrow.
> >>
> >> Thanks for the link, that pretty much clarifies all the parts
> >> I was wondering about.
> >
> > OK so based on the link above, I got the LDP panel DPI working with
> > the quirks now shrunk to the two panel specific GPIOs.
> >
> > Probably best to set those up based on "omapdss,panel-dpi-ldp"
> > compatible flag?
> >
> > That is after removing the backlight_gpio from panel_dpi_probe_of()
> > so the panel specific GPIOs can be handled easily based on the
> > compatible flag. Current work in progress patch below for reference
> > in case anybody has better ideas for dealing with the remaining
> > to GPIOs.
> 
> A reset gpio could be useful on more panels I think.
> omapdss,panel-dsi-cm already have a reset-gpios property so maybe
> omapdss,panel-dpi should have one too.

OK. For handling the GPIOs, looks like gpio_backlight_probe_dt
is doing:

gbl->active = (gpio_flags & OF_GPIO_ACTIVE_LOW) ? 0 : 1

To handle the polarity. We should probably do the same for the
panels as we at least used to have the polarity flags in the
platform data earlier.
 
> A lot of panels have mode pins, but usually these are hard coded on
> the circuit board.
> If it's just a bunch of static gpio values that need to be set maybe
> you could have something like this:
> mode-gpios = <&gpio1 10 0 &gpio1 11 0>;
> mode-gpios-values = <1 1>;
> 
> Driver would set these gpios to values at init.

If mode-gpios can be is Linux generic, then it makes sense to add
it. But if it's specific to this panel, I'd like to avoid setting
up yet another custom DT *-gpios property..

In any case, with (gpio_flags & OF_GPIO_ACTIVE_LOW) mode-gpio-values
should not be needed.

If it does not make sense to set up a generic mode-gpios for the
panels, then panel dpi can parse the first two GPIOs for enable
and reset. Then we can allow the rest of the array be parsed if
needed based on the compatible flag.

Regards,

Tony

Re: OMAPDSS and panel-dpi

[Joachim Eastwood]

On 18 April 2014 17:40, Tony Lindgren <tony@atomide.com> wrote:
> * Joachim Eastwood <manabian@gmail.com> [140418 04:05]:
>> On 18 April 2014 04:50, Tony Lindgren <tony@atomide.com> wrote:
>> > * Tony Lindgren <tony@atomide.com> [140417 15:50]:
>> >> * Joachim Eastwood <manabian@gmail.com> [140417 13:51]:
>> >> > On 17 April 2014 21:22, Tony Lindgren <tony@atomide.com> wrote:
>> >> > > * Joachim Eastwood <manabian@gmail.com> [140417 11:05]:
>> >> > >> Hi Tomi,
>> >> > >>
>> >> > >> My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
>> >> > >> now working (thanks) I also taken a look at panel-dpi.
>> >> > >>
>> >> > >> I found the DT patch for panel-dpi on the mailing list.
>> >> > >> OMAPDSS: panel-dpi: Add DT support:
>> >> > >> http://marc.info/?l=devicetree&m=139030201815380&w=2
>> >> > >>
>> >> > >> And I got my display working with DT :)
>> >> > >> So you add can my: Tested-by: Joachim Eastwood <manabian@gmail.com>
>> >> > >>
>> >> > >> Could you upstream the panel-dpi DT support and the HDMI connector
>> >> > >> gpio hpd patch in 3.16?
>> >> > >> I hope it's easier to upstream the stuff when it gets some users in DT.
>> >> > >
>> >> > > Good to hear. The DPI panel support should use gpio-backlight
>> >> > > driver as discussed in the DPI thread. Did you have to patch
>> >> > > anything for the timings etc?
>> >> >
>> >> > The only driver patches I use are those two from Tomi mentioned above.
>> >> > (panel-dpi DT support and HDMI connector gpio-hpd)
>> >> >
>> >> > > If you have the board working, care to take a look at making
>> >> > > the gpio-backlight change?
>> >> >
>> >> > I am already using the gpio-backlight driver.
>> >>
>> >> OK great, so then we can just drop that GPIO backlight handling
>> >> from the DPI DT patch I presume.
>> >>
>> >> > You can take a look at the device tree for VAR-DVK-OM44 here:
>> >> > http://slexy.org/raw/s2Pz4BELGe
>> >> >
>> >> > I'll post the patch set on list tomorrow.
>> >>
>> >> Thanks for the link, that pretty much clarifies all the parts
>> >> I was wondering about.
>> >
>> > OK so based on the link above, I got the LDP panel DPI working with
>> > the quirks now shrunk to the two panel specific GPIOs.
>> >
>> > Probably best to set those up based on "omapdss,panel-dpi-ldp"
>> > compatible flag?
>> >
>> > That is after removing the backlight_gpio from panel_dpi_probe_of()
>> > so the panel specific GPIOs can be handled easily based on the
>> > compatible flag. Current work in progress patch below for reference
>> > in case anybody has better ideas for dealing with the remaining
>> > to GPIOs.
>>
>> A reset gpio could be useful on more panels I think.
>> omapdss,panel-dsi-cm already have a reset-gpios property so maybe
>> omapdss,panel-dpi should have one too.
>
> OK. For handling the GPIOs, looks like gpio_backlight_probe_dt
> is doing:
>
> gbl->active = (gpio_flags & OF_GPIO_ACTIVE_LOW) ? 0 : 1
>
> To handle the polarity. We should probably do the same for the
> panels as we at least used to have the polarity flags in the
> platform data earlier.

Yes, that sounds good.

>> A lot of panels have mode pins, but usually these are hard coded on
>> the circuit board.
>> If it's just a bunch of static gpio values that need to be set maybe
>> you could have something like this:
>> mode-gpios = <&gpio1 10 0 &gpio1 11 0>;
>> mode-gpios-values = <1 1>;
>>
>> Driver would set these gpios to values at init.
>
> If mode-gpios can be is Linux generic, then it makes sense to add
> it. But if it's specific to this panel, I'd like to avoid setting
> up yet another custom DT *-gpios property..
>
> In any case, with (gpio_flags & OF_GPIO_ACTIVE_LOW) mode-gpio-values
> should not be needed.

Yes, that's a good idea.

> If it does not make sense to set up a generic mode-gpios for the
> panels, then panel dpi can parse the first two GPIOs for enable
> and reset. Then we can allow the rest of the array be parsed if
> needed based on the compatible flag.

Looking through the panels in omap2/display-new the most common gpio
pins are; backlight, reset and enable.
So it makes sense to have enable and reset as properties.

Gpio is used for mode setting in: nl8048hl11 and ls037v7dw01.
nl8048hl11 has just a qvga gpio, while the other one has no less than
3 mode pins (qvga and 2 scanning direction pins). All these mode pins
are set once and then never touched again.

Using gpios property for setting up an arbitrary amount of mode pins
so like a solution to me.

regards
Joachim Eastwood

Re: OMAPDSS and panel-dpi

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

On Thu, 2014-04-17 at 19:50 -0700, Tony Lindgren wrote:

>  &vpll2 {
> -       /* Needed for DSS */
> -       regulator-name = "vdds_dsi";
> +	/* Needed for DSS */
> +	regulator-name = "vdds_dsi";
>  };

This vpll2 node shouldn't be needed with full DT solution.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: OMAPDSS and panel-dpi

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

On Fri, 2014-04-18 at 18:43 +0200, Joachim Eastwood wrote:

> > If it does not make sense to set up a generic mode-gpios for the
> > panels, then panel dpi can parse the first two GPIOs for enable
> > and reset. Then we can allow the rest of the array be parsed if
> > needed based on the compatible flag.
> 
> Looking through the panels in omap2/display-new the most common gpio
> pins are; backlight, reset and enable.
> So it makes sense to have enable and reset as properties.
> 
> Gpio is used for mode setting in: nl8048hl11 and ls037v7dw01.
> nl8048hl11 has just a qvga gpio, while the other one has no less than
> 3 mode pins (qvga and 2 scanning direction pins). All these mode pins
> are set once and then never touched again.
> 
> Using gpios property for setting up an arbitrary amount of mode pins
> so like a solution to me.

Generic reset gpio handling is a bit problematic, as even if we know
what the normal state for the gpio is, we don't know how to use it. How
long should it be set to reset-state? How long should be it in the
normal-state before we can reset again? How to handle the powers when
resetting?

We could have some big delays there, which would work for more or less
all the panels. It just doesn't feel quite right =).

If we need reset and panel specific mode pin handling, I think a
separate driver is the cleanest option.

Do we have any way to set some gpios to a specified value at boot time
via DT, in a fixed manner? So more or less what Tony does in
ldp_twl_gpio_setup(). If we could just fix the RESET and QVGA gpios, we
could use the panel-dpi just fine, and only handle the enable gpio in
the panel driver.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]