v3.19-rc1 regression(?) on N900

DISCUSSION Nishanth Menon 5 participants 8 messages Dec 24, 2014 – Dec 30, 2014 Device tree bindings

lore

Share & tools

lore

Nishanth Menon

author

2014-12-24 22:57 UTC #0 lore raw

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

Signature · 2 lines

Regards,
Nishanth Menon

Pali Rohár

2014-12-25 08:32 UTC #1 lore raw

Quoted 30 lines · 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...

Quoted 4 lines

[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?

Signature · 9 lines

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>

Pavel Machek

2014-12-25 09:11 UTC #2 lore raw

Quoted 15 lines · Pali Roh?r

Quoted 14 lines · 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..

Quoted 8 lines

Quoted 8 lines
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.

Quoted 8 lines

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).

Quoted 6 lines

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

Signature · 2 lines

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

Aaro Koskinen

2014-12-25 22:21 UTC #3 lore raw

Hi,

Quoted 11 lines · Pavel Machek

Quoted 7 lines · Pali Roh?r
Quoted 6 lines · 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...

Quoted 1 line

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.

Tomi Valkeinen

2014-12-29 08:04 UTC #4 lore raw

Hi,

Quoted 10 lines · Aaro Koskinen

...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

Quoted 2 lines

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>

Aaro Koskinen

2014-12-29 18:02 UTC #5 lore raw

Hi,

Quoted 12 lines · Tomi Valkeinen

Quoted 10 lines · Aaro Koskinen

...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

Quoted 5 lines

Quoted 2 lines
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.

Pavel Machek

Tested-by

2014-12-30 17:39 UTC #6 lore raw

In reply to Tomi Valkeinen

Quoted 14 lines · Tomi Valkeinen

Hi,

Quoted 10 lines · Aaro Koskinen

...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

Quoted 5 lines

Quoted 2 lines
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 <[email protected]>

Quoted 33 lines

From fe3e8dde8eae80541a3f3b39c421428ebd02955f Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <[email protected]>
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 <[email protected]>
Reported-by Pavel Machek <[email protected]>
Signed-off-by Tomi Valkeinen <[email protected]>
---
 drivers/video/fbdev/omap2/dss/sdi.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/video/fbdev/omap2/dss/sdi.c +2 -0
index d51a983075bc..5c2ccab5a958 100644
@@ -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;
 

Signature · 2 lines

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

Pavel Machek

2014-12-25 10:48 UTC #7 lore raw

In reply to Pali Rohár

Quoted 44 lines · Pali Roh?r

Quoted 30 lines · 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...
Quoted 4 lines
[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).

Quoted 6 lines

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.

arch/arm/boot/dts/omap3-n900.dts +51 ~~-85~~

index 53f3ca0..7c17d084 100644
@@ -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 {

Signature · 2 lines

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