* v3.19-rc1 regression(?) on N900 @ 2014-12-24 22:57 Nishanth Menon 2014-12-25 8:32 ` Pali Rohár 0 siblings, 1 reply; 16+ messages in thread From: Nishanth Menon @ 2014-12-24 22:57 UTC (permalink / raw) To: linux-omap; +Cc: Pali Rohár 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 2014-12-24 22:57 v3.19-rc1 regression(?) on N900 Nishanth Menon @ 2014-12-25 8:32 ` Pali Rohár 0 siblings, 0 replies; 16+ messages in thread From: Pali Rohár @ 2014-12-25 8:32 UTC (permalink / raw) To: Nishanth Menon Cc: linux-omap, pavel, sre, sre, aaro.koskinen, tony, ivo.g.dimitrov.75, linux-arm-kernel, kernel list [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* v3.19-rc1 regression(?) on N900 @ 2014-12-25 8:32 ` Pali Rohár 0 siblings, 0 replies; 16+ messages in thread From: Pali Rohár @ 2014-12-25 8:32 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 2014-12-25 8:32 ` Pali Rohár (?) @ 2014-12-25 9:11 ` Pavel Machek -1 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2014-12-25 9:11 UTC (permalink / raw) To: Pali Rohár Cc: Nishanth Menon, linux-omap, sre, sre, aaro.koskinen, tony, ivo.g.dimitrov.75, linux-arm-kernel, kernel list 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* v3.19-rc1 regression(?) on N900 @ 2014-12-25 9:11 ` Pavel Machek 0 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2014-12-25 9:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 @ 2014-12-25 9:11 ` Pavel Machek 0 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2014-12-25 9:11 UTC (permalink / raw) To: Pali Rohár Cc: Nishanth Menon, linux-omap, sre, sre, aaro.koskinen, tony, ivo.g.dimitrov.75, linux-arm-kernel, kernel list 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 2014-12-25 9:11 ` Pavel Machek @ 2014-12-25 22:21 ` Aaro Koskinen -1 siblings, 0 replies; 16+ messages in thread From: Aaro Koskinen @ 2014-12-25 22:21 UTC (permalink / raw) To: Pavel Machek, Tomi Valkeinen, Archit Taneja Cc: Pali Rohár, Nishanth Menon, linux-omap, sre, Tony Lindgren, sre, ivo.g.dimitrov.75, linux-arm-kernel, linux-kernel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* v3.19-rc1 regression(?) on N900 @ 2014-12-25 22:21 ` Aaro Koskinen 0 siblings, 0 replies; 16+ messages in thread From: Aaro Koskinen @ 2014-12-25 22:21 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 2014-12-25 22:21 ` Aaro Koskinen @ 2014-12-29 8:04 ` Tomi Valkeinen -1 siblings, 0 replies; 16+ messages in thread From: Tomi Valkeinen @ 2014-12-29 8:04 UTC (permalink / raw) To: Aaro Koskinen, Pavel Machek Cc: Pali Rohár, Nishanth Menon, linux-omap, sre, Tony Lindgren, sre, ivo.g.dimitrov.75, linux-arm-kernel, linux-kernel [-- 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 --] ^ permalink raw reply related [flat|nested] 16+ messages in thread
* v3.19-rc1 regression(?) on N900 @ 2014-12-29 8:04 ` Tomi Valkeinen 0 siblings, 0 replies; 16+ messages in thread From: Tomi Valkeinen @ 2014-12-29 8:04 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 2014-12-29 8:04 ` Tomi Valkeinen @ 2014-12-29 18:02 ` Aaro Koskinen -1 siblings, 0 replies; 16+ messages in thread From: Aaro Koskinen @ 2014-12-29 18:02 UTC (permalink / raw) To: Tomi Valkeinen Cc: Pavel Machek, Pali Rohár, Nishanth Menon, linux-omap, sre, Tony Lindgren, sre, ivo.g.dimitrov.75, linux-arm-kernel, linux-kernel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* v3.19-rc1 regression(?) on N900 @ 2014-12-29 18:02 ` Aaro Koskinen 0 siblings, 0 replies; 16+ messages in thread From: Aaro Koskinen @ 2014-12-29 18:02 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 2014-12-29 8:04 ` Tomi Valkeinen @ 2014-12-30 17:39 ` Pavel Machek -1 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2014-12-30 17:39 UTC (permalink / raw) To: Tomi Valkeinen Cc: Aaro Koskinen, Pali Rohár, Nishanth Menon, linux-omap, sre, Tony Lindgren, sre, ivo.g.dimitrov.75, linux-arm-kernel, linux-kernel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* v3.19-rc1 regression(?) on N900 @ 2014-12-30 17:39 ` Pavel Machek 0 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2014-12-30 17:39 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: v3.19-rc1 regression(?) on N900 2014-12-25 8:32 ` Pali Rohár @ 2014-12-25 10:48 ` Pavel Machek -1 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2014-12-25 10:48 UTC (permalink / raw) To: Pali Rohár Cc: Nishanth Menon, linux-omap, sre, sre, aaro.koskinen, tony, ivo.g.dimitrov.75, linux-arm-kernel, kernel list 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 = <ðernet_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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* v3.19-rc1 regression(?) on N900 @ 2014-12-25 10:48 ` Pavel Machek 0 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2014-12-25 10:48 UTC (permalink / raw) To: linux-arm-kernel 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 = <ðernet_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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-12-30 17:39 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-24 22:57 v3.19-rc1 regression(?) on N900 Nishanth Menon 2014-12-25 8:32 ` Pali Rohár 2014-12-25 8:32 ` Pali Rohár 2014-12-25 9:11 ` Pavel Machek 2014-12-25 9:11 ` Pavel Machek 2014-12-25 9:11 ` Pavel Machek 2014-12-25 22:21 ` Aaro Koskinen 2014-12-25 22:21 ` Aaro Koskinen 2014-12-29 8:04 ` Tomi Valkeinen 2014-12-29 8:04 ` Tomi Valkeinen 2014-12-29 18:02 ` Aaro Koskinen 2014-12-29 18:02 ` Aaro Koskinen 2014-12-30 17:39 ` Pavel Machek 2014-12-30 17:39 ` Pavel Machek 2014-12-25 10:48 ` Pavel Machek 2014-12-25 10:48 ` Pavel Machek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.