v3.19-rc1 regression(?) on N900

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>

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

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

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.

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>

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.

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