[PATCHv2,10/10] ARM: dts: n950: add display support
diff mbox series

Message ID 20170305004309.28259-10-sre@kernel.org
State New, archived
Headers show
Series
  • Nokia N950 basic display support
Related show

Commit Message

Sebastian Reichel March 5, 2017, 12:43 a.m. UTC
Add basic panel support for the Nokia N950. It must be tweaked a
little bit later, since the panel was built into the device
upside-down. Also the first 5 and the last 5 pixels are covered
by plastic.

Signed-off-By: Sebastian Reichel <sre@kernel.org>
---
 arch/arm/boot/dts/omap3-n950.dts | 89 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)

Comments

Tony Lindgren March 24, 2017, 2:29 p.m. UTC | #1
* Sebastian Reichel <sre@kernel.org> [170304 16:45]:
> Add basic panel support for the Nokia N950. It must be tweaked a
> little bit later, since the panel was built into the device
> upside-down. Also the first 5 and the last 5 pixels are covered
> by plastic.

This one seems safe to apply separately to shrink the pending
patches a bit. Please confirm if that's the case and I'll apply
this one.

Regards,

Tony
Tomi Valkeinen March 24, 2017, 2:58 p.m. UTC | #2
On 24/03/17 16:29, Tony Lindgren wrote:
> * Sebastian Reichel <sre@kernel.org> [170304 16:45]:
>> Add basic panel support for the Nokia N950. It must be tweaked a
>> little bit later, since the panel was built into the device
>> upside-down. Also the first 5 and the last 5 pixels are covered
>> by plastic.
> 
> This one seems safe to apply separately to shrink the pending
> patches a bit. Please confirm if that's the case and I'll apply
> this one.

No, I think there are too many open questions to apply this one. And we
need to move to common DRM drivers at some point (hopefully soon) so the
bindings must be aligned with those if and when possible.

 Tomi
Tony Lindgren March 24, 2017, 3:12 p.m. UTC | #3
* Tomi Valkeinen <tomi.valkeinen@ti.com> [170324 08:01]:
> On 24/03/17 16:29, Tony Lindgren wrote:
> > * Sebastian Reichel <sre@kernel.org> [170304 16:45]:
> >> Add basic panel support for the Nokia N950. It must be tweaked a
> >> little bit later, since the panel was built into the device
> >> upside-down. Also the first 5 and the last 5 pixels are covered
> >> by plastic.
> > 
> > This one seems safe to apply separately to shrink the pending
> > patches a bit. Please confirm if that's the case and I'll apply
> > this one.
> 
> No, I think there are too many open questions to apply this one. And we
> need to move to common DRM drivers at some point (hopefully soon) so the
> bindings must be aligned with those if and when possible.

Hmm so what are the open questions and do you have in mind for
the panel bindings?

Naturally we still need to support the current bindings too.

Regards,

Tony
Tomi Valkeinen March 24, 2017, 3:20 p.m. UTC | #4
On 24/03/17 17:12, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [170324 08:01]:
>> On 24/03/17 16:29, Tony Lindgren wrote:
>>> * Sebastian Reichel <sre@kernel.org> [170304 16:45]:
>>>> Add basic panel support for the Nokia N950. It must be tweaked a
>>>> little bit later, since the panel was built into the device
>>>> upside-down. Also the first 5 and the last 5 pixels are covered
>>>> by plastic.
>>>
>>> This one seems safe to apply separately to shrink the pending
>>> patches a bit. Please confirm if that's the case and I'll apply
>>> this one.
>>
>> No, I think there are too many open questions to apply this one. And we
>> need to move to common DRM drivers at some point (hopefully soon) so the
>> bindings must be aligned with those if and when possible.
> 
> Hmm so what are the open questions and do you have in mind for
> the panel bindings?

Well, until we have driver that supports the panel without problems, we
can't be sure if we have everything in the binding. At least the TE was
missing or broken.

Normal videotimings don't really make sense for DSI command mode panels,
so I'm not overly enthusiastic in having them in the bindings. Possibly
that's the easy way to go, but I'm not sure yet.

There are the "TODO" parts in the bindings, that's a clear sign of open
questions.

I haven't looked at how the other DRM drivers handle DSI command mode
panels. That's something to study, before adding anything new to the
omap specific bindings.

> Naturally we still need to support the current bindings too.

Do the current bindings work? I guess they did work on omapfb... Do
these new bindings work with omapfb?

Generally speaking, I've been bitten badly enough with DT bindings that
weren't up to the task after all, and then changing the later was a
major pain (or working around it). So I'd rather not merge anything to
DT if there are any unclarities, and a driver not working which uses
those bindings is an unclarity. Especially if the only reason to merge
is to get a single patch out from a bigger patch series, without
actually enabling anything.

 Tomi
Tony Lindgren March 24, 2017, 3:44 p.m. UTC | #5
* Tomi Valkeinen <tomi.valkeinen@ti.com> [170324 08:22]:
> On 24/03/17 17:12, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [170324 08:01]:
> >> On 24/03/17 16:29, Tony Lindgren wrote:
> >>> * Sebastian Reichel <sre@kernel.org> [170304 16:45]:
> >>>> Add basic panel support for the Nokia N950. It must be tweaked a
> >>>> little bit later, since the panel was built into the device
> >>>> upside-down. Also the first 5 and the last 5 pixels are covered
> >>>> by plastic.
> >>>
> >>> This one seems safe to apply separately to shrink the pending
> >>> patches a bit. Please confirm if that's the case and I'll apply
> >>> this one.
> >>
> >> No, I think there are too many open questions to apply this one. And we
> >> need to move to common DRM drivers at some point (hopefully soon) so the
> >> bindings must be aligned with those if and when possible.
> > 
> > Hmm so what are the open questions and do you have in mind for
> > the panel bindings?
> 
> Well, until we have driver that supports the panel without problems, we
> can't be sure if we have everything in the binding. At least the TE was
> missing or broken.

Sure, I don't think that needs a binding though?

> Normal videotimings don't really make sense for DSI command mode panels,
> so I'm not overly enthusiastic in having them in the bindings. Possibly
> that's the easy way to go, but I'm not sure yet.

Are you talking about passing the clock-frequency = <0> where
dsi calculates it or also some other things too?

> There are the "TODO" parts in the bindings, that's a clear sign of open
> questions.

Yeah the default rotation part seems to be completely open :)
We should probably stick with just kernel cmdline for that for
now until there is some generic solution.

> I haven't looked at how the other DRM drivers handle DSI command mode
> panels. That's something to study, before adding anything new to the
> omap specific bindings.

OK. I suggest we just stick to standard existing bindings for now.

> > Naturally we still need to support the current bindings too.
> 
> Do the current bindings work? I guess they did work on omapfb... Do
> these new bindings work with omapfb?

Well yeah in general they work just fine for the basic resolution +
clock + control GPIOs. I think that binding is just fine. So we should
probably stick to that before adding more stuff.

For command mode panels, looking at patch 1 of this series we always
had the resolution hardcoded into the driver.. And talking about
patch 1, do you also have some issues with it other than that typo there
pointed out by Pavel?

> Generally speaking, I've been bitten badly enough with DT bindings that
> weren't up to the task after all, and then changing the later was a
> major pain (or working around it). So I'd rather not merge anything to
> DT if there are any unclarities, and a driver not working which uses
> those bindings is an unclarity. Especially if the only reason to merge
> is to get a single patch out from a bigger patch series, without
> actually enabling anything.

Sure. The solution there is to just stick to basics until with the
binding until things are clear. So in this case resolutions + clocks +
control GPIOs + regulators. Those all are existing standard bindings
that can easily be supported.

Regards,

Tony

Patch
diff mbox series

diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index 646601a3ebd8..1aa4251b39d7 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -51,6 +51,26 @@ 
 	};
 };
 
+&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";
@@ -185,3 +205,72 @@ 
 	st,max-limit-y = <32>;
 	st,max-limit-z = <32>;
 };
+
+&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 upside-down, 480x464 pixels */
+		/* top and bottom 5 lines are not visible */
+		/* physical dimensions: 48960µm x 88128µm */
+		panel-timing {
+			clock-frequency = <0>;          /* Calculated by dsi */
+
+			hback-porch = <2>;
+			hactive = <480>;
+			hfront-porch = <0>;
+			hsync-len = <2>;
+
+			vback-porch = <1>;
+			vactive = <864>;
+			vfront-porch = <0>;
+			vsync-len = <1>;
+
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+
+			/* TODO: rotate panel by 180° */
+			/* TODO: add 5 pixel y-offset and limit vactive to 854 */
+		};
+
+		port {
+			lcd0_in: endpoint {
+				remote-endpoint = <&dsi_out_ep>;
+			};
+		};
+	};
+};