diff mbox

[02/23] ARM: dts: n950: add display support

Message ID 1457455195-1938-3-git-send-email-sre@kernel.org (mailing list archive)
State New, archived
Headers show

Commit Message

Sebastian Reichel March 8, 2016, 4:39 p.m. UTC
Signed-off-By: Sebastian Reichel <sre@kernel.org>
---
 arch/arm/boot/dts/omap3-n950.dts | 71 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

Comments

Laurent Pinchart March 17, 2016, 12:14 p.m. UTC | #1
Hi Sebastian,

Thank you for the patch.

On Tuesday 08 March 2016 17:39:34 Sebastian Reichel wrote:
> Signed-off-By: Sebastian Reichel <sre@kernel.org>
> ---
>  arch/arm/boot/dts/omap3-n950.dts | 71 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-n950.dts
> b/arch/arm/boot/dts/omap3-n950.dts index 0885b34d5d7d..41b8fb585272 100644
> --- a/arch/arm/boot/dts/omap3-n950.dts
> +++ b/arch/arm/boot/dts/omap3-n950.dts
> @@ -17,6 +17,26 @@
>  	compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
>  };
> 
> +&omap3_pmx_core {
> +	dsi_pins: pinmux_dsi_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE1) /* dsi_dx0 -
> data0+ */
> +			OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE1) /* dsi_dy0 -
> data0- */
> +			OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE1) /* dsi_dx1 -
> clk+   */
> +			OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE1) /* dsi_dy1 -
> clk-   */
> +			OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE1) /* dsi_dx2 -
> data1+ */
> +			OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE1) /* dsi_dy2 -
> data1- */
> +		>;
> +	};
> +
> +	display_pins: pinmux_display_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x20ca, PIN_INPUT | MUX_MODE4) /* gpio 62 -
> display te */
> +			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE4) /* gpio 87 -
> display reset */
> +		>;
> +	};
> +};
> +
>  &i2c2 {
>  	smia_1: camera@10 {
>  		compatible = "nokia,smia";
> @@ -53,3 +73,54 @@
>  		};
>  	};
>  };
> +
> +&dss {
> +	status = "ok";
> +
> +	vdda_video-supply = <&vdac>;
> +};
> +
> +&dsi {
> +	status = "ok";
> +
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&dsi_pins>;
> +
> +	vdd-supply = <&vpll2>;
> +
> +	port {
> +		dsi_out_ep: endpoint {
> +			remote-endpoint = <&lcd0_in>;
> +			lanes = <2 3 0 1 4 5>;
> +		};
> +	};
> +
> +	lcd0: display {
> +		compatible = "nokia,himalaya", "panel-dsi-cm";
> +		label = "lcd0";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&display_pins>;
> +
> +		vpnl-supply = <&vmmc2>;
> +		vddi-supply = <&vio>;
> +
> +		reset-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;	/* 87 */
> +		te-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;	/* 62 */
> +
> +		has-dsi-backlight;
> +
> +		/* panel is 480x464 with top and bottom 5 lines not visible */

I assume you mean 480x864 ?

> +		/* physical dimensions: 48960µm x 88128µm */
> +		resolution-x = <480>;
> +		resolution-y = <854>;
> +		offset-x = <0>;
> +		offset-y = <5>;
> +
> +		port {
> +			lcd0_in: endpoint {
> +				remote-endpoint = <&dsi_out_ep>;
> +			};
> +		};
> +	};
> +};
Sebastian Reichel March 17, 2016, 5:49 p.m. UTC | #2
Hi Laurent,

On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote:
> [...]
> > +
> > +		/* panel is 480x464 with top and bottom 5 lines not visible */
> 
> I assume you mean 480x864 ?

Yes, nice catch. Basically the screen is 480x864, but only
480x854 are visible.

> > +		/* physical dimensions: 48960µm x 88128µm */
> > +		resolution-x = <480>;
> > +		resolution-y = <854>;
> > +		offset-x = <0>;
> > +		offset-y = <5>;
> [...]

-- Sebastian
Jani Nikula March 23, 2016, 12:40 p.m. UTC | #3
On Thu, 17 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
> On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote:
>> [...]
>> > +
>> > +		/* panel is 480x464 with top and bottom 5 lines not visible */
>> 
>> I assume you mean 480x864 ?
>
> Yes, nice catch. Basically the screen is 480x864, but only
> 480x854 are visible.

It's been a while, but I thought the full 480x864 was actually usable
and visible.

BR,
Jani.
Sebastian Reichel March 23, 2016, 2:01 p.m. UTC | #4
Hi,

On Wed, Mar 23, 2016 at 02:40:53PM +0200, Jani Nikula wrote:
> On Thu, 17 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
> > On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote:
> >> [...]
> >> > +
> >> > +		/* panel is 480x464 with top and bottom 5 lines not visible */
> >> 
> >> I assume you mean 480x864 ?
> >
> > Yes, nice catch. Basically the screen is 480x864, but only
> > 480x854 are visible.
> 
> It's been a while, but I thought the full 480x864 was actually usable
> and visible.

I tried that first and the first few lines were missing. The stock
kernel also uses only 854px:

https://github.com/nemomobile/kernel-adaptation-n950-n9/blob/mer-n9-2.6.32-20121301/arch/arm/mach-omap2/board-rm680-video.c

(search for partial_area)

-- Sebastian
Jani Nikula March 24, 2016, 10:03 a.m. UTC | #5
On Wed, 23 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
> On Wed, Mar 23, 2016 at 02:40:53PM +0200, Jani Nikula wrote:
>> On Thu, 17 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
>> > On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote:
>> >> [...]
>> >> > +
>> >> > +		/* panel is 480x464 with top and bottom 5 lines not visible */
>> >> 
>> >> I assume you mean 480x864 ?
>> >
>> > Yes, nice catch. Basically the screen is 480x864, but only
>> > 480x854 are visible.
>> 
>> It's been a while, but I thought the full 480x864 was actually usable
>> and visible.
>
> I tried that first and the first few lines were missing. The stock
> kernel also uses only 854px:
>
> https://github.com/nemomobile/kernel-adaptation-n950-n9/blob/mer-n9-2.6.32-20121301/arch/arm/mach-omap2/board-rm680-video.c
>
> (search for partial_area)

Heh, I was reminded by old colleagues that it was actually my commit
back in the day that changed the resolution 864->854 in the stock
kernel. And that I did it reluctantly, because there really was no
technical reason to do the change.

I don't really care all that much either way anymore. I just thought
you'd like to get those 4800 pixels back that you've been missing all
these years. Plus 864 was nicer to deal with because it has 2^5 as a
prime factor while 854 only has 2.

BR,
Jani.
Sebastian Reichel March 24, 2016, 2:26 p.m. UTC | #6
Hi,

On Thu, Mar 24, 2016 at 12:03:01PM +0200, Jani Nikula wrote:
> On Wed, 23 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
> > On Wed, Mar 23, 2016 at 02:40:53PM +0200, Jani Nikula wrote:
> >> On Thu, 17 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
> >> > On Thu, Mar 17, 2016 at 02:14:26PM +0200, Laurent Pinchart wrote:
> >> >> [...]
> >> >> > +
> >> >> > +		/* panel is 480x464 with top and bottom 5 lines not visible */
> >> >> 
> >> >> I assume you mean 480x864 ?
> >> >
> >> > Yes, nice catch. Basically the screen is 480x864, but only
> >> > 480x854 are visible.
> >> 
> >> It's been a while, but I thought the full 480x864 was actually usable
> >> and visible.
> >
> > I tried that first and the first few lines were missing. The stock
> > kernel also uses only 854px:
> >
> > https://github.com/nemomobile/kernel-adaptation-n950-n9/blob/mer-n9-2.6.32-20121301/arch/arm/mach-omap2/board-rm680-video.c
> >
> > (search for partial_area)
> 
> Heh, I was reminded by old colleagues that it was actually my commit
> back in the day that changed the resolution 864->854 in the stock
> kernel. And that I did it reluctantly, because there really was no
> technical reason to do the change.
> 
> I don't really care all that much either way anymore. I just thought
> you'd like to get those 4800 pixels back that you've been missing all
> these years. Plus 864 was nicer to deal with because it has 2^5 as a
> prime factor while 854 only has 2.

As I said: I did use 864 initially. That results in missing pixels.
This is what I observed before switching to 854:

In fbcon the first line was rendered half (only the bottom part of
each character was visible). Then, when I rotated fbcon (fbcon has
native rotation support, which does not work with DRM, but just
renders the text differently), the left part of each character was
missing. In my case the "[" prefix of kernel messages was rendered
as two dots. At least the vertical line was not visible at all.

I _think_, that your HW team decided to cover the first and the
last few pixels of the 864 display with plastic. So technically
it's a 864 display, but effectively it's 854.

-- Sebastian
Jani Nikula March 24, 2016, 3:11 p.m. UTC | #7
On Thu, 24 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
> As I said: I did use 864 initially. That results in missing pixels.

Sorry, I didn't mean to question this. Go with what works, not with some
old fart's ramblings!

> I _think_, that your HW team decided to cover the first and the
> last few pixels of the 864 display with plastic. So technically
> it's a 864 display, but effectively it's 854.

(*shudder* at "your HW team" ;)

It's plausible, the covers did change slightly for the developer
edition.

Good luck with the upstreaming efforts!


BR,
Jani.
Sebastian Reichel March 25, 2016, 12:15 a.m. UTC | #8
Hi,

On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote:
> On Thu, 24 Mar 2016, Sebastian Reichel <sre@kernel.org> wrote:
> > As I said: I did use 864 initially. That results in missing pixels.
> 
> Sorry, I didn't mean to question this. Go with what works, not with some
> old fart's ramblings!

No problem. I also wondered why this has been done. If I understood
Tomi right, the userspace team feared, that their software would not
work with 864, since it was originally written for 854.

Anyways I'm pretty sure, that the first 5 pixels are unusable
from the users point of view.

> > I _think_, that your HW team decided to cover the first and the
> > last few pixels of the 864 display with plastic. So technically
> > it's a 864 display, but effectively it's 854.
> 
> (*shudder* at "your HW team" ;)

;)

> It's plausible, the covers did change slightly for the developer
> edition.

Assuming the non-developer edition can use the full display it
can be "unlocked" with my proposed DT bindings by slight
modifications. I guess there exist just a couple of those, so
maybe we just ignore it for the mainline kernel?

> Good luck with the upstreaming efforts!

Thanks.

-- Sebastian
Tony Lindgren April 12, 2016, 8:51 p.m. UTC | #9
* Sebastian Reichel <sre@kernel.org> [160324 17:16]:
> On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote:
> > > I _think_, that your HW team decided to cover the first and the
> > > last few pixels of the 864 display with plastic. So technically
> > > it's a 864 display, but effectively it's 854.

Sebastian, should I apply this dts patch as is or are changes
still needed?

Tony
Tony Lindgren June 21, 2016, 11:01 a.m. UTC | #10
* Tony Lindgren <tony@atomide.com> [160412 13:53]:
> * Sebastian Reichel <sre@kernel.org> [160324 17:16]:
> > On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote:
> > > > I _think_, that your HW team decided to cover the first and the
> > > > last few pixels of the 864 display with plastic. So technically
> > > > it's a 864 display, but effectively it's 854.
> 
> Sebastian, should I apply this dts patch as is or are changes
> still needed?

Well please repost when ready, I'll untag this old thread here..

Tony
Sebastian Reichel June 24, 2016, 12:30 a.m. UTC | #11
Hi Tony,

On Tue, Jun 21, 2016 at 04:01:03AM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [160412 13:53]:
> > * Sebastian Reichel <sre@kernel.org> [160324 17:16]:
> > > On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote:
> > > > > I _think_, that your HW team decided to cover the first and the
> > > > > last few pixels of the 864 display with plastic. So technically
> > > > > it's a 864 display, but effectively it's 854.
> > 
> > Sebastian, should I apply this dts patch as is or are changes
> > still needed?
> 
> Well please repost when ready, I'll untag this old thread here..

Sounds fine to me. DTS changes should be merged once the driver
changes are accepted and they need at least one more cycle.

-- Sebastian
diff mbox

Patch

diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index 0885b34d5d7d..41b8fb585272 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -17,6 +17,26 @@ 
 	compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
 };
 
+&omap3_pmx_core {
+	dsi_pins: pinmux_dsi_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE1) /* dsi_dx0 - data0+ */
+			OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE1) /* dsi_dy0 - data0- */
+			OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE1) /* dsi_dx1 - clk+   */
+			OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE1) /* dsi_dy1 - clk-   */
+			OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE1) /* dsi_dx2 - data1+ */
+			OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE1) /* dsi_dy2 - data1- */
+		>;
+	};
+
+	display_pins: pinmux_display_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20ca, PIN_INPUT | MUX_MODE4) /* gpio 62 - display te */
+			OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE4) /* gpio 87 - display reset */
+		>;
+	};
+};
+
 &i2c2 {
 	smia_1: camera@10 {
 		compatible = "nokia,smia";
@@ -53,3 +73,54 @@ 
 		};
 	};
 };
+
+&dss {
+	status = "ok";
+
+	vdda_video-supply = <&vdac>;
+};
+
+&dsi {
+	status = "ok";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&dsi_pins>;
+
+	vdd-supply = <&vpll2>;
+
+	port {
+		dsi_out_ep: endpoint {
+			remote-endpoint = <&lcd0_in>;
+			lanes = <2 3 0 1 4 5>;
+		};
+	};
+
+	lcd0: display {
+		compatible = "nokia,himalaya", "panel-dsi-cm";
+		label = "lcd0";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&display_pins>;
+
+		vpnl-supply = <&vmmc2>;
+		vddi-supply = <&vio>;
+
+		reset-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;	/* 87 */
+		te-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;	/* 62 */
+
+		has-dsi-backlight;
+
+		/* panel is 480x464 with top and bottom 5 lines not visible */
+		/* physical dimensions: 48960µm x 88128µm */
+		resolution-x = <480>;
+		resolution-y = <854>;
+		offset-x = <0>;
+		offset-y = <5>;
+
+		port {
+			lcd0_in: endpoint {
+				remote-endpoint = <&dsi_out_ep>;
+			};
+		};
+	};
+};