v3.19-rc1 regression(?) on N900

v3.19-rc1 regression(?) on N900

[Nishanth Menon]

based on automated testing with u-boot as a chained bootloader..

v3.18: boots fine:
https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plus_defconfig/n900.txt

v3.19-rc1: hung
https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap2plus_defconfig/n900.txt

in the interim, my farm had a bit of breakdown around the time of n900
breakdown..

as per my last functional linux-next logs:
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/n900.txt
-> hung.
https://github.com/nmenon/kernel-test-logs/blob/next-20141112/omap2plus_defconfig/n900.txt
-> working.

DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not yield
information either

Note: I am using the combined uImage+dtb image.[2]

I think this might just be my setup..(i use chained loader ->
NOLO->u-boot->serial download->kernel) but anyways.. Since Pali
thought others might be interested in sharing experience...

[1]   http://slexy.org/raw/s2osxhhwbR
[2]
https://github.com/nmenon/linux-2.6-playground/commit/177f5f71b3f21ea484ee4b09a2e0c015de522417

-- 
Regards,
Nishanth Menon

Re: v3.19-rc1 regression(?) on N900

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1858 bytes --]

On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> based on automated testing with u-boot as a chained
> bootloader..
> 
> v3.18: boots fine:
> https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> s_defconfig/n900.txt
> 
> v3.19-rc1: hung
> https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> 2plus_defconfig/n900.txt
> 
> in the interim, my farm had a bit of breakdown around the time
> of n900 breakdown..
> 
> as per my last functional linux-next logs:
> https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> omap2plus_defconfig/n900.txt -> hung.
> https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> omap2plus_defconfig/n900.txt -> working.
> 
> DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> yield information either
> 
> Note: I am using the combined uImage+dtb image.[2]
> 
> I think this might just be my setup..(i use chained loader ->
> NOLO->u-boot->serial download->kernel) but anyways.. Since
> Pali thought others might be interested in sharing
> experience...
> 
> [1]   http://slexy.org/raw/s2osxhhwbR
> [2]
> https://github.com/nmenon/linux-2.6-playground/commit/177f5f71
> b3f21ea484ee4b09a2e0c015de522417

CCing other people.

I see same problem in qemu with 3.19-rc1 kernel when doing DT 
boot. In qemu I'm using direct booting from OneNAND (X-Loader --> 
NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I 
do not see any other output from serial console. Also on qemu 
screen there is no new output (just NOKIA logo from bootloader).

I do not have this problem when doing legacy/board code boot with 
3.19-rc1 kernel, so this problem is related to DT.

Kernel 3.18-rc1 worked fine for both DT and legacy boot.

Can somebody look what broke DT booting?

-- 
Pali Rohár
pali.rohar@gmail.com

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

v3.19-rc1 regression(?) on N900

[Pali Rohár]

On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> based on automated testing with u-boot as a chained
> bootloader..
> 
> v3.18: boots fine:
> https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> s_defconfig/n900.txt
> 
> v3.19-rc1: hung
> https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> 2plus_defconfig/n900.txt
> 
> in the interim, my farm had a bit of breakdown around the time
> of n900 breakdown..
> 
> as per my last functional linux-next logs:
> https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> omap2plus_defconfig/n900.txt -> hung.
> https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> omap2plus_defconfig/n900.txt -> working.
> 
> DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> yield information either
> 
> Note: I am using the combined uImage+dtb image.[2]
> 
> I think this might just be my setup..(i use chained loader ->
> NOLO->u-boot->serial download->kernel) but anyways.. Since
> Pali thought others might be interested in sharing
> experience...
> 
> [1]   http://slexy.org/raw/s2osxhhwbR
> [2]
> https://github.com/nmenon/linux-2.6-playground/commit/177f5f71
> b3f21ea484ee4b09a2e0c015de522417

CCing other people.

I see same problem in qemu with 3.19-rc1 kernel when doing DT 
boot. In qemu I'm using direct booting from OneNAND (X-Loader --> 
NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I 
do not see any other output from serial console. Also on qemu 
screen there is no new output (just NOKIA logo from bootloader).

I do not have this problem when doing legacy/board code boot with 
3.19-rc1 kernel, so this problem is related to DT.

Kernel 3.18-rc1 worked fine for both DT and legacy boot.

Can somebody look what broke DT booting?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141225/8838583b/attachment.sig>

Re: v3.19-rc1 regression(?) on N900

[Pavel Machek]

On Thu 2014-12-25 09:32:40, Pali Rohár wrote:
> On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > based on automated testing with u-boot as a chained
> > bootloader..
> > 
> > v3.18: boots fine:
> > https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> > s_defconfig/n900.txt
> > 
> > v3.19-rc1: hung
> > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > 2plus_defconfig/n900.txt
> > 
> > in the interim, my farm had a bit of breakdown around the time
> > of n900 breakdown..
> > 
> > as per my last functional linux-next logs:
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> > omap2plus_defconfig/n900.txt -> hung.
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> > omap2plus_defconfig/n900.txt -> working.
> > 
> > DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> > yield information either

Early hang, independend on config. That's "dtb too big". Delete
something, and it should work again.

Plus you'll note video regression.

# > I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom,
# > video is gone.
#
# I reverted
#
# > 4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8
# in 3.19, and voila, video is back.

> CCing other people.
> 
> I see same problem in qemu with 3.19-rc1 kernel when doing DT 
> boot. In qemu I'm using direct booting from OneNAND (X-Loader --> 
> NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I 
> do not see any other output from serial console. Also on qemu 
> screen there is no new output (just NOKIA logo from bootloader).
> 
> I do not have this problem when doing legacy/board code boot with 
> 3.19-rc1 kernel, so this problem is related to DT.
> 
> Kernel 3.18-rc1 worked fine for both DT and legacy boot.
> 
> Can somebody look what broke DT booting?

It was too big dtb, at least for me.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v3.19-rc1 regression(?) on N900

[Pavel Machek]

On Thu 2014-12-25 09:32:40, Pali Rohár wrote:
> On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > based on automated testing with u-boot as a chained
> > bootloader..
> > 
> > v3.18: boots fine:
> > https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> > s_defconfig/n900.txt
> > 
> > v3.19-rc1: hung
> > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > 2plus_defconfig/n900.txt
> > 
> > in the interim, my farm had a bit of breakdown around the time
> > of n900 breakdown..
> > 
> > as per my last functional linux-next logs:
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> > omap2plus_defconfig/n900.txt -> hung.
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> > omap2plus_defconfig/n900.txt -> working.
> > 
> > DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> > yield information either

Early hang, independend on config. That's "dtb too big". Delete
something, and it should work again.

Plus you'll note video regression.

# > I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom,
# > video is gone.
#
# I reverted
#
# > 4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8
# in 3.19, and voila, video is back.

> CCing other people.
> 
> I see same problem in qemu with 3.19-rc1 kernel when doing DT 
> boot. In qemu I'm using direct booting from OneNAND (X-Loader --> 
> NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I 
> do not see any other output from serial console. Also on qemu 
> screen there is no new output (just NOKIA logo from bootloader).
> 
> I do not have this problem when doing legacy/board code boot with 
> 3.19-rc1 kernel, so this problem is related to DT.
> 
> Kernel 3.18-rc1 worked fine for both DT and legacy boot.
> 
> Can somebody look what broke DT booting?

It was too big dtb, at least for me.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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

v3.19-rc1 regression(?) on N900

[Pavel Machek]

On Thu 2014-12-25 09:32:40, Pali Roh?r wrote:
> On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > based on automated testing with u-boot as a chained
> > bootloader..
> > 
> > v3.18: boots fine:
> > https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> > s_defconfig/n900.txt
> > 
> > v3.19-rc1: hung
> > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > 2plus_defconfig/n900.txt
> > 
> > in the interim, my farm had a bit of breakdown around the time
> > of n900 breakdown..
> > 
> > as per my last functional linux-next logs:
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> > omap2plus_defconfig/n900.txt -> hung.
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> > omap2plus_defconfig/n900.txt -> working.
> > 
> > DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> > yield information either

Early hang, independend on config. That's "dtb too big". Delete
something, and it should work again.

Plus you'll note video regression.

# > I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom,
# > video is gone.
#
# I reverted
#
# > 4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8
# in 3.19, and voila, video is back.

> CCing other people.
> 
> I see same problem in qemu with 3.19-rc1 kernel when doing DT 
> boot. In qemu I'm using direct booting from OneNAND (X-Loader --> 
> NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I 
> do not see any other output from serial console. Also on qemu 
> screen there is no new output (just NOKIA logo from bootloader).
> 
> I do not have this problem when doing legacy/board code boot with 
> 3.19-rc1 kernel, so this problem is related to DT.
> 
> Kernel 3.18-rc1 worked fine for both DT and legacy boot.
> 
> Can somebody look what broke DT booting?

It was too big dtb, at least for me.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v3.19-rc1 regression(?) on N900

[Pavel Machek]

On Thu 2014-12-25 09:32:40, Pali Rohár wrote:
> On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > based on automated testing with u-boot as a chained
> > bootloader..
> > 
> > v3.18: boots fine:
> > https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> > s_defconfig/n900.txt
> > 
> > v3.19-rc1: hung
> > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > 2plus_defconfig/n900.txt
> > 
> > in the interim, my farm had a bit of breakdown around the time
> > of n900 breakdown..
> > 
> > as per my last functional linux-next logs:
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> > omap2plus_defconfig/n900.txt -> hung.
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> > omap2plus_defconfig/n900.txt -> working.
> > 
> > DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> > yield information either
> > 
> > Note: I am using the combined uImage+dtb image.[2]
> > 
> > I think this might just be my setup..(i use chained loader ->
> > NOLO->u-boot->serial download->kernel) but anyways.. Since
> > Pali thought others might be interested in sharing
> > experience...
> > 
> > [1]   http://slexy.org/raw/s2osxhhwbR
> > [2]
> > https://github.com/nmenon/linux-2.6-playground/commit/177f5f71
> > b3f21ea484ee4b09a2e0c015de522417
> 
> CCing other people.
> 
> I see same problem in qemu with 3.19-rc1 kernel when doing DT 
> boot. In qemu I'm using direct booting from OneNAND (X-Loader --> 
> NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I 
> do not see any other output from serial console. Also on qemu 
> screen there is no new output (just NOKIA logo from bootloader).
> 
> I do not have this problem when doing legacy/board code boot with 
> 3.19-rc1 kernel, so this problem is related to DT.
> 
> Kernel 3.18-rc1 worked fine for both DT and legacy boot.
> 
> Can somebody look what broke DT booting?

You should be able to apply this to get it back to boot.

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 53f3ca0..7c17d084 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -13,9 +13,16 @@
 #include <dt-bindings/input/input.h>
 
 / {
-	model = "Nokia N900";
+	model = "Nokia RX-51 board";
 	compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";
 
+	aliases {
+		i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+	};
+
 	cpus {
 		cpu@0 {
 			cpu0-supply = <&vcc>;
@@ -26,7 +33,7 @@
 		compatible = "gpio-leds";
 		heartbeat {
 			label = "debug::sleep";
-			gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;  /* gpio162 */
+			gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;  /* 162 */
 			linux,default-trigger = "default-on";
 			pinctrl-names = "default";
 			pinctrl-0 = <&debug_leds>;
@@ -140,14 +147,6 @@
 		>;
 	};
 
-	ethernet_pins: pinmux_ethernet_pins {
-		pinctrl-single,pins = <
-			OMAP3_CORE1_IOPAD(0x20b4, PIN_INPUT_PULLDOWN | MUX_MODE4)	/* gpmc_ncs3.gpio_54 */
-			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE4)		/* dss_data16.gpio_86 */
-			OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)		/* uart3_rts_sd.gpio_164 */
-		>;
-	};
-
 	gpmc_pins: pinmux_gpmc_pins {
 		pinctrl-single,pins = <
 
@@ -307,7 +306,7 @@
 	regulator-name = "V28";
 	regulator-min-microvolt = <2800000>;
 	regulator-max-microvolt = <2800000>;
-	regulator-always-on; /* due battery cover sensor */
+	regulator-always-on; /* due to battery cover sensor */
 };
 
 &vaux2 {
@@ -365,7 +364,6 @@
 	regulator-name = "VIO";
 	regulator-min-microvolt = <1800000>;
 	regulator-max-microvolt = <1800000>;
-
 };
 
 &vintana1 {
@@ -504,30 +502,6 @@
 		clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
 		enable-gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */
 
-		chan0 {
-			chan-name = "lp5523:kb1";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan1 {
-			chan-name = "lp5523:kb2";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan2 {
-			chan-name = "lp5523:kb3";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan3 {
-			chan-name = "lp5523:kb4";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
 		chan4 {
 			chan-name = "lp5523:b";
 			led-cur = /bits/ 8 <50>;
@@ -545,18 +519,6 @@
 			led-cur = /bits/ 8 <50>;
 			max-cur = /bits/ 8 <100>;
 		};
-
-		chan7 {
-			chan-name = "lp5523:kb5";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan8 {
-			chan-name = "lp5523:kb6";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
 	};
 
 	bq27200: bq27200@55 {
@@ -564,6 +526,7 @@
 		reg = <0x55>;
 	};
 
+	/* Stereo headphone amplifier */
 	tpa6130a2: tpa6130a2@60 {
 		compatible = "ti,tpa6130a2";
 		reg = <0x60>;
@@ -596,6 +559,22 @@
 
 		ti,usb-charger-detection = <&isp1704>;
 	};
+
+	adp1653: led-controller@30 {
+		compatible = "adi,adp1653";
+		reg = <0x30>;
+		gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+		flash {
+			flash-timeout-microsec = <500000>;
+			flash-max-microamp = <320000>;
+			max-microamp = <50000>;
+		};
+
+		indicator {
+			max-microamp = <17500>;
+		};
+	};
 };
 
 &i2c3 {
@@ -603,6 +582,18 @@
 	pinctrl-0 = <&i2c3_pins>;
 
 	clock-frequency = <400000>;
+
+	/* bus 3, same as ad5820, et8ek8 */
+	/* bus 2, adp1653, smiapp */
+	ad5820: ad5820@c {
+		compatible = "adi,ad5820";
+		reg = <0x0c>;
+	};
+
+	et8ek8: et8ek8@3e {
+		compatible = "et,et8ek8";
+		reg = <0x3e>;
+	};
 };
 
 &mmc1 {
@@ -699,43 +690,6 @@
 			reg = <0x004c0000 0x0fb40000>;
 		};
 	};
-
-	ethernet@gpmc {
-		compatible = "smsc,lan91c94";
-
-		status = "disabled";
-
-		interrupt-parent = <&gpio2>;
-		interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;	/* gpio54 */
-		reg = <1 0x300 0xf>;		/* 16 byte IO range at offset 0x300 */
-		bank-width = <2>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&ethernet_pins>;
-		power-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;	/* gpio86 */
-		reset-gpios = <&gpio6 4 GPIO_ACTIVE_HIGH>;	/* gpio164 */
-		gpmc,device-width = <2>;
-		gpmc,sync-clk-ps = <0>;
-		gpmc,cs-on-ns = <0>;
-		gpmc,cs-rd-off-ns = <48>;
-		gpmc,cs-wr-off-ns = <24>;
-		gpmc,adv-on-ns = <0>;
-		gpmc,adv-rd-off-ns = <0>;
-		gpmc,adv-wr-off-ns = <0>;
-		gpmc,we-on-ns = <12>;
-		gpmc,we-off-ns = <18>;
-		gpmc,oe-on-ns = <12>;
-		gpmc,oe-off-ns = <48>;
-		gpmc,page-burst-access-ns = <0>;
-		gpmc,access-ns = <42>;
-		gpmc,rd-cycle-ns = <180>;
-		gpmc,wr-cycle-ns = <180>;
-		gpmc,bus-turnaround-ns = <0>;
-		gpmc,cycle2cycle-delay-ns = <0>;
-		gpmc,wait-monitoring-ns = <0>;
-		gpmc,clk-activation-ns = <0>;
-		gpmc,wr-access-ns = <0>;
-		gpmc,wr-data-mux-bus-ns = <12>;
-	};
 };
 
 &mcspi1 {
@@ -823,9 +777,21 @@
 };
 
 &uart2 {
+        compatible = "brcm,uart,bcm2048";
 	interrupts-extended = <&intc 73 &omap3_pmx_core OMAP3_UART2_RX>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart2_pins>;
+
+	clocks = <&uart2_fck>, <&uart2_ick>;
+	clock-names = "fck", "ick";
+
+	device {
+		  compatible = "brcm,bcm2048";
+		  reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* 91 */
+		  host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* 101 */
+		  bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* 37 */
+		  bt-sysclk = <2>;
+	};
 };
 
 &uart3 {



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

v3.19-rc1 regression(?) on N900

[Pavel Machek]

On Thu 2014-12-25 09:32:40, Pali Roh?r wrote:
> On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > based on automated testing with u-boot as a chained
> > bootloader..
> > 
> > v3.18: boots fine:
> > https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> > s_defconfig/n900.txt
> > 
> > v3.19-rc1: hung
> > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > 2plus_defconfig/n900.txt
> > 
> > in the interim, my farm had a bit of breakdown around the time
> > of n900 breakdown..
> > 
> > as per my last functional linux-next logs:
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> > omap2plus_defconfig/n900.txt -> hung.
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> > omap2plus_defconfig/n900.txt -> working.
> > 
> > DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> > yield information either
> > 
> > Note: I am using the combined uImage+dtb image.[2]
> > 
> > I think this might just be my setup..(i use chained loader ->
> > NOLO->u-boot->serial download->kernel) but anyways.. Since
> > Pali thought others might be interested in sharing
> > experience...
> > 
> > [1]   http://slexy.org/raw/s2osxhhwbR
> > [2]
> > https://github.com/nmenon/linux-2.6-playground/commit/177f5f71
> > b3f21ea484ee4b09a2e0c015de522417
> 
> CCing other people.
> 
> I see same problem in qemu with 3.19-rc1 kernel when doing DT 
> boot. In qemu I'm using direct booting from OneNAND (X-Loader --> 
> NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I 
> do not see any other output from serial console. Also on qemu 
> screen there is no new output (just NOKIA logo from bootloader).
> 
> I do not have this problem when doing legacy/board code boot with 
> 3.19-rc1 kernel, so this problem is related to DT.
> 
> Kernel 3.18-rc1 worked fine for both DT and legacy boot.
> 
> Can somebody look what broke DT booting?

You should be able to apply this to get it back to boot.

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 53f3ca0..7c17d084 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -13,9 +13,16 @@
 #include <dt-bindings/input/input.h>
 
 / {
-	model = "Nokia N900";
+	model = "Nokia RX-51 board";
 	compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";
 
+	aliases {
+		i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+	};
+
 	cpus {
 		cpu at 0 {
 			cpu0-supply = <&vcc>;
@@ -26,7 +33,7 @@
 		compatible = "gpio-leds";
 		heartbeat {
 			label = "debug::sleep";
-			gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;  /* gpio162 */
+			gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;  /* 162 */
 			linux,default-trigger = "default-on";
 			pinctrl-names = "default";
 			pinctrl-0 = <&debug_leds>;
@@ -140,14 +147,6 @@
 		>;
 	};
 
-	ethernet_pins: pinmux_ethernet_pins {
-		pinctrl-single,pins = <
-			OMAP3_CORE1_IOPAD(0x20b4, PIN_INPUT_PULLDOWN | MUX_MODE4)	/* gpmc_ncs3.gpio_54 */
-			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE4)		/* dss_data16.gpio_86 */
-			OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)		/* uart3_rts_sd.gpio_164 */
-		>;
-	};
-
 	gpmc_pins: pinmux_gpmc_pins {
 		pinctrl-single,pins = <
 
@@ -307,7 +306,7 @@
 	regulator-name = "V28";
 	regulator-min-microvolt = <2800000>;
 	regulator-max-microvolt = <2800000>;
-	regulator-always-on; /* due battery cover sensor */
+	regulator-always-on; /* due to battery cover sensor */
 };
 
 &vaux2 {
@@ -365,7 +364,6 @@
 	regulator-name = "VIO";
 	regulator-min-microvolt = <1800000>;
 	regulator-max-microvolt = <1800000>;
-
 };
 
 &vintana1 {
@@ -504,30 +502,6 @@
 		clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
 		enable-gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */
 
-		chan0 {
-			chan-name = "lp5523:kb1";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan1 {
-			chan-name = "lp5523:kb2";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan2 {
-			chan-name = "lp5523:kb3";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan3 {
-			chan-name = "lp5523:kb4";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
 		chan4 {
 			chan-name = "lp5523:b";
 			led-cur = /bits/ 8 <50>;
@@ -545,18 +519,6 @@
 			led-cur = /bits/ 8 <50>;
 			max-cur = /bits/ 8 <100>;
 		};
-
-		chan7 {
-			chan-name = "lp5523:kb5";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
-
-		chan8 {
-			chan-name = "lp5523:kb6";
-			led-cur = /bits/ 8 <50>;
-			max-cur = /bits/ 8 <100>;
-		};
 	};
 
 	bq27200: bq27200 at 55 {
@@ -564,6 +526,7 @@
 		reg = <0x55>;
 	};
 
+	/* Stereo headphone amplifier */
 	tpa6130a2: tpa6130a2 at 60 {
 		compatible = "ti,tpa6130a2";
 		reg = <0x60>;
@@ -596,6 +559,22 @@
 
 		ti,usb-charger-detection = <&isp1704>;
 	};
+
+	adp1653: led-controller at 30 {
+		compatible = "adi,adp1653";
+		reg = <0x30>;
+		gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+		flash {
+			flash-timeout-microsec = <500000>;
+			flash-max-microamp = <320000>;
+			max-microamp = <50000>;
+		};
+
+		indicator {
+			max-microamp = <17500>;
+		};
+	};
 };
 
 &i2c3 {
@@ -603,6 +582,18 @@
 	pinctrl-0 = <&i2c3_pins>;
 
 	clock-frequency = <400000>;
+
+	/* bus 3, same as ad5820, et8ek8 */
+	/* bus 2, adp1653, smiapp */
+	ad5820: ad5820 at c {
+		compatible = "adi,ad5820";
+		reg = <0x0c>;
+	};
+
+	et8ek8: et8ek8 at 3e {
+		compatible = "et,et8ek8";
+		reg = <0x3e>;
+	};
 };
 
 &mmc1 {
@@ -699,43 +690,6 @@
 			reg = <0x004c0000 0x0fb40000>;
 		};
 	};
-
-	ethernet at gpmc {
-		compatible = "smsc,lan91c94";
-
-		status = "disabled";
-
-		interrupt-parent = <&gpio2>;
-		interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;	/* gpio54 */
-		reg = <1 0x300 0xf>;		/* 16 byte IO range at offset 0x300 */
-		bank-width = <2>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&ethernet_pins>;
-		power-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;	/* gpio86 */
-		reset-gpios = <&gpio6 4 GPIO_ACTIVE_HIGH>;	/* gpio164 */
-		gpmc,device-width = <2>;
-		gpmc,sync-clk-ps = <0>;
-		gpmc,cs-on-ns = <0>;
-		gpmc,cs-rd-off-ns = <48>;
-		gpmc,cs-wr-off-ns = <24>;
-		gpmc,adv-on-ns = <0>;
-		gpmc,adv-rd-off-ns = <0>;
-		gpmc,adv-wr-off-ns = <0>;
-		gpmc,we-on-ns = <12>;
-		gpmc,we-off-ns = <18>;
-		gpmc,oe-on-ns = <12>;
-		gpmc,oe-off-ns = <48>;
-		gpmc,page-burst-access-ns = <0>;
-		gpmc,access-ns = <42>;
-		gpmc,rd-cycle-ns = <180>;
-		gpmc,wr-cycle-ns = <180>;
-		gpmc,bus-turnaround-ns = <0>;
-		gpmc,cycle2cycle-delay-ns = <0>;
-		gpmc,wait-monitoring-ns = <0>;
-		gpmc,clk-activation-ns = <0>;
-		gpmc,wr-access-ns = <0>;
-		gpmc,wr-data-mux-bus-ns = <12>;
-	};
 };
 
 &mcspi1 {
@@ -823,9 +777,21 @@
 };
 
 &uart2 {
+        compatible = "brcm,uart,bcm2048";
 	interrupts-extended = <&intc 73 &omap3_pmx_core OMAP3_UART2_RX>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart2_pins>;
+
+	clocks = <&uart2_fck>, <&uart2_ick>;
+	clock-names = "fck", "ick";
+
+	device {
+		  compatible = "brcm,bcm2048";
+		  reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* 91 */
+		  host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* 101 */
+		  bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* 37 */
+		  bt-sysclk = <2>;
+	};
 };
 
 &uart3 {



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: v3.19-rc1 regression(?) on N900

[Aaro Koskinen]

Hi,

On Thu, Dec 25, 2014 at 10:11:21AM +0100, Pavel Machek wrote:
> On Thu 2014-12-25 09:32:40, Pali Rohár wrote:
> > On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > > based on automated testing with u-boot as a chained
> > > bootloader..
> > > 
> > > v3.19-rc1: hung
> > > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > > 2plus_defconfig/n900.txt
> 
> Early hang, independend on config. That's "dtb too big". Delete
> something, and it should work again.

For me, DT boot works fine with 3.19-rc1 as is...

> Plus you'll note video regression.

...however, I can confirm that framebuffer is broken:

[    8.230743] omapfb omapfb: no displays
[    8.255584] omapfb omapfb: failed to setup omapfb
[    8.260620] platform omapfb: Driver omapfb requests probe deferral
[    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
'/ocp/spi@48098000/acx565akm@2[0]' - status (0)
[    8.284271] acx565akm spi1.2: failed to find video source
[    8.290069] spi spi1.2: Driver acx565akm requests probe deferral

I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
by matching reg-id). When I revert that, also FB works with 3.19-rc1.

A.

v3.19-rc1 regression(?) on N900

[Aaro Koskinen]

Hi,

On Thu, Dec 25, 2014 at 10:11:21AM +0100, Pavel Machek wrote:
> On Thu 2014-12-25 09:32:40, Pali Roh?r wrote:
> > On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > > based on automated testing with u-boot as a chained
> > > bootloader..
> > > 
> > > v3.19-rc1: hung
> > > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > > 2plus_defconfig/n900.txt
> 
> Early hang, independend on config. That's "dtb too big". Delete
> something, and it should work again.

For me, DT boot works fine with 3.19-rc1 as is...

> Plus you'll note video regression.

...however, I can confirm that framebuffer is broken:

[    8.230743] omapfb omapfb: no displays
[    8.255584] omapfb omapfb: failed to setup omapfb
[    8.260620] platform omapfb: Driver omapfb requests probe deferral
[    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
'/ocp/spi at 48098000/acx565akm at 2[0]' - status (0)
[    8.284271] acx565akm spi1.2: failed to find video source
[    8.290069] spi spi1.2: Driver acx565akm requests probe deferral

I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
by matching reg-id). When I revert that, also FB works with 3.19-rc1.

A.

Re: v3.19-rc1 regression(?) on N900

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 808 bytes --]

Hi,

On 26/12/14 00:21, Aaro Koskinen wrote:

> ...however, I can confirm that framebuffer is broken:
> 
> [    8.230743] omapfb omapfb: no displays
> [    8.255584] omapfb omapfb: failed to setup omapfb
> [    8.260620] platform omapfb: Driver omapfb requests probe deferral
> [    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> '/ocp/spi@48098000/acx565akm@2[0]' - status (0)
> [    8.284271] acx565akm spi1.2: failed to find video source
> [    8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> 
> I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> by matching reg-id). When I revert that, also FB works with 3.19-rc1.

I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
please report if it works.

 Tomi


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-OMAPDSS-SDI-fix-output-port_num.patch --]
[-- Type: text/x-patch; name="0001-OMAPDSS-SDI-fix-output-port_num.patch", Size: 1391 bytes --]

From fe3e8dde8eae80541a3f3b39c421428ebd02955f Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon, 29 Dec 2014 09:57:11 +0200
Subject: [PATCH] OMAPDSS: SDI: fix output port_num

After the commit ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by
matching reg-id) we look for the SDI output using the port number.
However, the SDI driver doesn't set the port number, which causes the
SDI display to not initialize.

Fix this by setting the SDI port number to 1. We use a hardcoded value,
as SDI was used only on OMAP3 and it's always port number 1 there.

Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/sdi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/sdi.c b/drivers/video/fbdev/omap2/dss/sdi.c
index d51a983075bc..5c2ccab5a958 100644
--- a/drivers/video/fbdev/omap2/dss/sdi.c
+++ b/drivers/video/fbdev/omap2/dss/sdi.c
@@ -342,6 +342,8 @@ static void sdi_init_output(struct platform_device *pdev)
 	out->output_type = OMAP_DISPLAY_TYPE_SDI;
 	out->name = "sdi.0";
 	out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
+	/* We have SDI only on OMAP3, where it's on port 1 */
+	out->port_num = 1;
 	out->ops.sdi = &sdi_ops;
 	out->owner = THIS_MODULE;
 
-- 
2.2.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

v3.19-rc1 regression(?) on N900

[Tomi Valkeinen]

Hi,

On 26/12/14 00:21, Aaro Koskinen wrote:

> ...however, I can confirm that framebuffer is broken:
> 
> [    8.230743] omapfb omapfb: no displays
> [    8.255584] omapfb omapfb: failed to setup omapfb
> [    8.260620] platform omapfb: Driver omapfb requests probe deferral
> [    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> '/ocp/spi at 48098000/acx565akm at 2[0]' - status (0)
> [    8.284271] acx565akm spi1.2: failed to find video source
> [    8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> 
> I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> by matching reg-id). When I revert that, also FB works with 3.19-rc1.

I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
please report if it works.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-OMAPDSS-SDI-fix-output-port_num.patch
Type: text/x-patch
Size: 1355 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141229/5bc95826/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141229/5bc95826/attachment.sig>

Re: v3.19-rc1 regression(?) on N900

[Aaro Koskinen]

Hi,

On Mon, Dec 29, 2014 at 10:04:46AM +0200, Tomi Valkeinen wrote:
> On 26/12/14 00:21, Aaro Koskinen wrote:
> 
> > ...however, I can confirm that framebuffer is broken:
> > 
> > [    8.230743] omapfb omapfb: no displays
> > [    8.255584] omapfb omapfb: failed to setup omapfb
> > [    8.260620] platform omapfb: Driver omapfb requests probe deferral
> > [    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> > '/ocp/spi@48098000/acx565akm@2[0]' - status (0)
> > [    8.284271] acx565akm spi1.2: failed to find video source
> > [    8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> > 
> > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> > by matching reg-id). When I revert that, also FB works with 3.19-rc1.
> 
> I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
> please report if it works.

That works, thanks.

A.

v3.19-rc1 regression(?) on N900

[Aaro Koskinen]

Hi,

On Mon, Dec 29, 2014 at 10:04:46AM +0200, Tomi Valkeinen wrote:
> On 26/12/14 00:21, Aaro Koskinen wrote:
> 
> > ...however, I can confirm that framebuffer is broken:
> > 
> > [    8.230743] omapfb omapfb: no displays
> > [    8.255584] omapfb omapfb: failed to setup omapfb
> > [    8.260620] platform omapfb: Driver omapfb requests probe deferral
> > [    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> > '/ocp/spi at 48098000/acx565akm at 2[0]' - status (0)
> > [    8.284271] acx565akm spi1.2: failed to find video source
> > [    8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> > 
> > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> > by matching reg-id). When I revert that, also FB works with 3.19-rc1.
> 
> I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
> please report if it works.

That works, thanks.

A.

Re: v3.19-rc1 regression(?) on N900

[Pavel Machek]

On Mon 2014-12-29 10:04:46, Tomi Valkeinen wrote:
> Hi,
> 
> On 26/12/14 00:21, Aaro Koskinen wrote:
> 
> > ...however, I can confirm that framebuffer is broken:
> > 
> > [    8.230743] omapfb omapfb: no displays
> > [    8.255584] omapfb omapfb: failed to setup omapfb
> > [    8.260620] platform omapfb: Driver omapfb requests probe deferral
> > [    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> > '/ocp/spi@48098000/acx565akm@2[0]' - status (0)
> > [    8.284271] acx565akm spi1.2: failed to find video source
> > [    8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> > 
> > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> > by matching reg-id). When I revert that, also FB works with 3.19-rc1.
> 
> I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
> please report if it works.

This fixes the issue for me.

Tested-by: Pavel Machek <pavel@ucw.cz>


> From fe3e8dde8eae80541a3f3b39c421428ebd02955f Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Mon, 29 Dec 2014 09:57:11 +0200
> Subject: [PATCH] OMAPDSS: SDI: fix output port_num
> 
> After the commit ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by
> matching reg-id) we look for the SDI output using the port number.
> However, the SDI driver doesn't set the port number, which causes the
> SDI display to not initialize.
> 
> Fix this by setting the SDI port number to 1. We use a hardcoded value,
> as SDI was used only on OMAP3 and it's always port number 1 there.
> 
> Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Reported-by: Pavel Machek <pavel@ucw.cz>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  drivers/video/fbdev/omap2/dss/sdi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/video/fbdev/omap2/dss/sdi.c b/drivers/video/fbdev/omap2/dss/sdi.c
> index d51a983075bc..5c2ccab5a958 100644
> --- a/drivers/video/fbdev/omap2/dss/sdi.c
> +++ b/drivers/video/fbdev/omap2/dss/sdi.c
> @@ -342,6 +342,8 @@ static void sdi_init_output(struct platform_device *pdev)
>  	out->output_type = OMAP_DISPLAY_TYPE_SDI;
>  	out->name = "sdi.0";
>  	out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
> +	/* We have SDI only on OMAP3, where it's on port 1 */
> +	out->port_num = 1;
>  	out->ops.sdi = &sdi_ops;
>  	out->owner = THIS_MODULE;
>  




-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

v3.19-rc1 regression(?) on N900

[Pavel Machek]

On Mon 2014-12-29 10:04:46, Tomi Valkeinen wrote:
> Hi,
> 
> On 26/12/14 00:21, Aaro Koskinen wrote:
> 
> > ...however, I can confirm that framebuffer is broken:
> > 
> > [    8.230743] omapfb omapfb: no displays
> > [    8.255584] omapfb omapfb: failed to setup omapfb
> > [    8.260620] platform omapfb: Driver omapfb requests probe deferral
> > [    8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> > '/ocp/spi at 48098000/acx565akm at 2[0]' - status (0)
> > [    8.284271] acx565akm spi1.2: failed to find video source
> > [    8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> > 
> > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> > by matching reg-id). When I revert that, also FB works with 3.19-rc1.
> 
> I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
> please report if it works.

This fixes the issue for me.

Tested-by: Pavel Machek <pavel@ucw.cz>


> From fe3e8dde8eae80541a3f3b39c421428ebd02955f Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Mon, 29 Dec 2014 09:57:11 +0200
> Subject: [PATCH] OMAPDSS: SDI: fix output port_num
> 
> After the commit ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by
> matching reg-id) we look for the SDI output using the port number.
> However, the SDI driver doesn't set the port number, which causes the
> SDI display to not initialize.
> 
> Fix this by setting the SDI port number to 1. We use a hardcoded value,
> as SDI was used only on OMAP3 and it's always port number 1 there.
> 
> Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Reported-by: Pavel Machek <pavel@ucw.cz>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  drivers/video/fbdev/omap2/dss/sdi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/video/fbdev/omap2/dss/sdi.c b/drivers/video/fbdev/omap2/dss/sdi.c
> index d51a983075bc..5c2ccab5a958 100644
> --- a/drivers/video/fbdev/omap2/dss/sdi.c
> +++ b/drivers/video/fbdev/omap2/dss/sdi.c
> @@ -342,6 +342,8 @@ static void sdi_init_output(struct platform_device *pdev)
>  	out->output_type = OMAP_DISPLAY_TYPE_SDI;
>  	out->name = "sdi.0";
>  	out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
> +	/* We have SDI only on OMAP3, where it's on port 1 */
> +	out->port_num = 1;
>  	out->ops.sdi = &sdi_ops;
>  	out->owner = THIS_MODULE;
>  




-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html