regressions in linux-next?
Subsystems (2)
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8
4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa
Quoted 1 line
known
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C
9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6
12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI
13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ
14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh
15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW
16: sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17: sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18: sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01
19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped
TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10
next-20140417-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVA
Quoted 1 line
farm issues. - But peter reports fail as well.
3: am3517-evm: Boot PASS: http://slexy.org/raw/s29h2lXGuw
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20Whu6Qjr
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21jBdk51T
6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2118uUlle
Quoted 1 line
known.
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29I92x0p3
8: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s2GqJbMp7C
Quoted 1 line
farm issues
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2fb7JvizO
10: beaglebone: Boot PASS: http://slexy.org/raw/s2uQNDnOlV 11: craneboard: Boot PASS: http://slexy.org/raw/s2pTk8AgdX 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2r2XdK8XF
13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s213f9wx5p
14: n900: Boot PASS: http://slexy.org/raw/s2SaNcFG85
15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2fR7PoakJ
16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2IMJ75sNc
17: sdp2430: Boot PASS: http://slexy.org/raw/s207NAmPbO 18: sdp3430: Boot PASS: http://slexy.org/raw/s20Yzlg3lU 19: sdp4430: Boot PASS: http://slexy.org/raw/s21eYIZxtI
20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2HIEtrDX9
TOTAL = 20 boards, Booted Boards = 17, No Boot boards = 3
next-20140416-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s20LxN1Qn4 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s202mfovsx 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2IAJlhTFg 4: am37x-evm: Boot PASS: http://slexy.org/raw/s213AOULx7
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s22NCBg38K
6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2IhClBS3N
Quoted 1 line
known
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2octtFj30
8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20t9axfIr
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21FvZM0Gz
10: beaglebone: Boot PASS: http://slexy.org/raw/s2119uANhW 11: craneboard: Boot PASS: http://slexy.org/raw/s2FoVFiYaC 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2FJjqu4MU
13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s29X2FBMhu
14: n900: Boot PASS: http://slexy.org/raw/s2AcjThjhw
15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2LF8KsxJw
16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2E2KTBSFY
17: sdp2430: Boot PASS: http://slexy.org/raw/s20HnXbU9M 18: sdp3430: Boot PASS: http://slexy.org/raw/s20OuKg9mw 19: sdp4430: Boot PASS: http://slexy.org/raw/s25V9CJgUB
20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21WFeZmTd
TOTAL = 20 boards, Booted Boards = 18, No Boot boards = 2
Signature · 2 lines
Regards, Nishanth Menon
Quoted 20 lines · Nishanth Menon
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat84: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqaQuoted 1 line
known
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x612: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI
13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ
14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh
15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW16: sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17: sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18: sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01
Quoted 7 lines
19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped
TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10next-20140417-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVAQuoted 1 line
farm issues. - But peter reports fail as well.
Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information.
I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert:d04b76626e94 gpio: omap: convert driver to use gpiolib irqchip
am335x-evmsk boots up fine.
With that commit in place PandaBoardES boots fine, but evmsk does not.
Quoted 46 lines
3: am3517-evm: Boot PASS: http://slexy.org/raw/s29h2lXGuw
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20Whu6Qjr
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21jBdk51T
6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2118uUlleQuoted 1 line
known.
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29I92x0p3
8: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s2GqJbMp7CQuoted 1 line
farm issues
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2fb7JvizO
10: beaglebone: Boot PASS: http://slexy.org/raw/s2uQNDnOlV 11: craneboard: Boot PASS: http://slexy.org/raw/s2pTk8AgdX 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2r2XdK8XF13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s213f9wx5p
14: n900: Boot PASS: http://slexy.org/raw/s2SaNcFG85
15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2fR7PoakJ
16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2IMJ75sNc17: sdp2430: Boot PASS: http://slexy.org/raw/s207NAmPbO 18: sdp3430: Boot PASS: http://slexy.org/raw/s20Yzlg3lU 19: sdp4430: Boot PASS: http://slexy.org/raw/s21eYIZxtI20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2HIEtrDX9
TOTAL = 20 boards, Booted Boards = 17, No Boot boards = 3next-20140416-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s20LxN1Qn4 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s202mfovsx 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2IAJlhTFg 4: am37x-evm: Boot PASS: http://slexy.org/raw/s213AOULx75: am43xx-epos: Boot PASS: http://slexy.org/raw/s22NCBg38K
6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2IhClBS3NQuoted 1 line
known
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2octtFj30
8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20t9axfIr
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21FvZM0Gz10: beaglebone: Boot PASS: http://slexy.org/raw/s2119uANhW 11: craneboard: Boot PASS: http://slexy.org/raw/s2FoVFiYaC 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2FJjqu4MU13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s29X2FBMhu
14: n900: Boot PASS: http://slexy.org/raw/s2AcjThjhw
15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2LF8KsxJw
16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2E2KTBSFY17: sdp2430: Boot PASS: http://slexy.org/raw/s20HnXbU9M 18: sdp3430: Boot PASS: http://slexy.org/raw/s20OuKg9mw 19: sdp4430: Boot PASS: http://slexy.org/raw/s25V9CJgUB20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21WFeZmTd
TOTAL = 20 boards, Booted Boards = 18, No Boot boards = 2
Signature · 5 lines
Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Peter and Nishanth,
Quoted 36 lines · Peter Ujfalusi
Quoted 20 lines · Nishanth Menon
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat84: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqaQuoted 1 line
known
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x612: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI
13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ
14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh
15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW16: sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17: sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18: sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01Quoted 7 lines
19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped
TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10next-20140417-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVAQuoted 1 line
farm issues. - But peter reports fail as well.
Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information.
I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert:d04b76626e94gpio: omap: convert driver to use gpiolib irqchip
Quoted 4 lines
am335x-evmsk boots up fine.
With that commit in place PandaBoardES boots fine, but evmsk does not.
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
Thanks a lot and best regards,
Javier
Quoted 49 lines
Quoted 41 lines
3: am3517-evm: Boot PASS: http://slexy.org/raw/s29h2lXGuw
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20Whu6Qjr
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21jBdk51T
6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2118uUlleQuoted 1 line
known.
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29I92x0p3
8: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s2GqJbMp7CQuoted 1 line
farm issues
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2fb7JvizO
10: beaglebone: Boot PASS: http://slexy.org/raw/s2uQNDnOlV 11: craneboard: Boot PASS: http://slexy.org/raw/s2pTk8AgdX 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2r2XdK8XF13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s213f9wx5p
14: n900: Boot PASS: http://slexy.org/raw/s2SaNcFG85
15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2fR7PoakJ
16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2IMJ75sNc17: sdp2430: Boot PASS: http://slexy.org/raw/s207NAmPbO 18: sdp3430: Boot PASS: http://slexy.org/raw/s20Yzlg3lU 19: sdp4430: Boot PASS: http://slexy.org/raw/s21eYIZxtI20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2HIEtrDX9
TOTAL = 20 boards, Booted Boards = 17, No Boot boards = 3next-20140416-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s20LxN1Qn4 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s202mfovsx 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2IAJlhTFg 4: am37x-evm: Boot PASS: http://slexy.org/raw/s213AOULx75: am43xx-epos: Boot PASS: http://slexy.org/raw/s22NCBg38K
6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2IhClBS3NQuoted 1 line
known
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2octtFj30
8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20t9axfIr
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21FvZM0Gz10: beaglebone: Boot PASS: http://slexy.org/raw/s2119uANhW 11: craneboard: Boot PASS: http://slexy.org/raw/s2FoVFiYaC 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2FJjqu4MU13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s29X2FBMhu
14: n900: Boot PASS: http://slexy.org/raw/s2AcjThjhw
15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2LF8KsxJw
16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2E2KTBSFYQuoted 6 lines
17: sdp2430: Boot PASS: http://slexy.org/raw/s20HnXbU9M 18: sdp3430: Boot PASS: http://slexy.org/raw/s20OuKg9mw 19: sdp4430: Boot PASS: http://slexy.org/raw/s25V9CJgUB20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21WFeZmTd
TOTAL = 20 boards, Booted Boards = 18, No Boot boards = 2
Quoted 6 lines
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 42 lines · Javier Martinez Canillas
Quoted 36 lines · Peter Ujfalusi
Quoted 20 lines · Nishanth Menon
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat84: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqaQuoted 1 line
known
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x612: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI
13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ
14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh
15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW16: sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17: sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18: sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01Quoted 7 lines
19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped
TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10next-20140417-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVAQuoted 1 line
farm issues. - But peter reports fail as well.
Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information.
I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert:d04b76626e94gpio: omap: convert driver to use gpiolib irqchipQuoted 4 lines
am335x-evmsk boots up fine.
With that commit in place PandaBoardES boots fine, but evmsk does not.
Quoted 8 lines
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
I've tested 20140422 -next on a Beaglebone black board with a custom gpio-keys cape and it seems to be working fine.
All the gpio are registered, but there are some suspicious messages:
# dmesg | grep gpio gpiochip_add: registered GPIOs 0 to 31 on device: gpio gpiochip_add: registered GPIOs 32 to 63 on device: gpio gpiochip_add: registered GPIOs 64 to 95 on device: gpio gpiochip_add: registered GPIOs 96 to 127 on device: gpio of_get_named_gpiod_flags: can't parse gpios property of node '/fixedregulator@0[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@44e09000[0]' of_get_named_gpiod_flags exited with status 0 of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@48060000[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]'
Regards,
Signature · 7 lines
Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Ezequiel,
Quoted 46 lines · Ezequiel Garcia
Quoted 45 lines · Javier Martinez Canillas
Quoted 36 lines · Peter Ujfalusi
Quoted 20 lines · Nishanth Menon
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat84: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqaQuoted 1 line
known
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x612: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI
13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ
14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh
15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW16: sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn 17: sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB 18: sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01Quoted 7 lines
19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped
TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10next-20140417-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVAQuoted 1 line
farm issues. - But peter reports fail as well.
Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information.
I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert:d04b76626e94gpio: omap: convert driver to use gpiolib irqchipQuoted 4 lines
am335x-evmsk boots up fine.
With that commit in place PandaBoardES boots fine, but evmsk does not.
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
Quoted 9 lines
Quoted 5 lines
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
I've tested 20140422 -next on a Beaglebone black board with a custom gpio-keys cape and it seems to be working fine.
Thanks a lot for testing the patches, then is not a problem with all am335x since BBB is booting correctly.
Quoted 14 lines
All the gpio are registered, but there are some suspicious messages:
# dmesg | grep gpio gpiochip_add: registered GPIOs 0 to 31 on device: gpio gpiochip_add: registered GPIOs 32 to 63 on device: gpio gpiochip_add: registered GPIOs 64 to 95 on device: gpio gpiochip_add: registered GPIOs 96 to 127 on device: gpio of_get_named_gpiod_flags: can't parse gpios property of node '/fixedregulator@0[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@44e09000[0]' of_get_named_gpiod_flags exited with status 0 of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@48060000[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]' of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@481d8000[0]'
Yes those messages are suspicious indeed but I don't think that are related with this patch-set since I've a similar log on my IGEPv2 when booting 3.15-rc2 (which does not include the gpiolib irqchip conversion):
dmesg | grep -i gpio
[ 0.505554] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [ 0.506927] OMAP GPIO hardware version 2.5 [ 0.508697] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [ 0.511352] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [ 0.514007] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [ 0.516571] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [ 0.519256] gpiochip_add: registered GPIOs 160 to 191 on device: gpio [ 0.653167] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vdd33[0]' [ 0.654907] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vddvario[0]' [ 0.656066] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vdd33a[0]' [ 0.657257] of_get_named_gpiod_flags exited with status -517 [ 0.665985] of_get_named_gpiod_flags exited with status 0 [ 1.213073] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@4806a000[0]' [ 1.218109] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@4806c000[0]' [ 1.221160] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@49020000[0]' [ 2.094512] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@49042000[0]' [ 2.552764] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4809c000[0]' [ 2.552795] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4809c000[0]' [ 2.569305] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 2.569335] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 2.647216] of_get_named_gpiod_flags exited with status 0 [ 2.659545] of_get_named_gpiod_flags exited with status -517 [ 2.669006] of_get_named_gpiod_flags exited with status 0 [ 2.908355] twl4030_gpio twl4030-gpio: gpio (irq 338) chaining IRQs 354..371 [ 2.917266] gpiochip_find_base: found new base at 492 [ 2.918487] gpiochip_add: registered GPIOs 492 to 511 on device: twl4030 [ 2.993957] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4809c000[0]' [ 2.993988] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4809c000[0]' [ 3.045196] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 3.045227] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 3.094604] of_get_named_gpiod_flags exited with status 0 [ 3.101531] of_get_named_gpiod_flags exited with status 0 [ 8.423065] of_get_named_gpiod_flags exited with status 0 [ 9.788970] of_get_named_gpiod_flags: can't parse gpios property of node '/sound[0]' [ 9.837951] of_get_named_gpiod_flags: can't parse gpios property of node '/sound[0]' [ 10.200561] of_get_named_gpiod_flags: can't parse gpios property of node '/sound[0]' [ 10.203399] of_get_named_gpiod_flags: can't parse gpios property of
node '/ocp/i2c@48070000/twl@48/audio/codec[0]'
Best regards,
Javier
Quoted 5 lines
Regards,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Yours,
Linus Walleij
Hello Linus,
Quoted 6 lines · Linus Walleij
Quoted 3 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
Quoted 8 lines
Quoted 4 lines
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
The board that is failing to boot with this patch-set is not an OMAP1 based board but the Sitara AM335x Starter Kit (arch/arm/boot/dts/am335x-evmsk.dts).
Now, other boards using the same SoC like the Beagle Bone Black are booting correctly and also am335x-evm which is very similar to am335x-evmsk.dts.
Nishanth has access to this board and his helping now with the debugging.
Quoted 4 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
Yeah, I'm doing my best to keep this driver up-to-date with the latest changes in gpiolib but it seems that is very hard to change the OMAP GPIO driver without breaking one of the gazillion TI platforms out there...
Quoted 6 lines
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Yours,
Linus Walleij
Thanks a lot and best regards,
Javier
Quoted 15 lines · Javier Martinez Canillas
Hello Linus,
Quoted 11 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
Quoted 7 lines
Quoted 3 lines
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
The board that is failing to boot with this patch-set is not an OMAP1 based board but the Sitara AM335x Starter Kit (
arch/arm/boot/dts/am335x-evmsk.dts).
This does not happen to have anything to do with the ti,no-reset-on-init hack for &gpio0 on the am335x-evmsk.dts that's needed to keep DDR powered? See the am43x thread for more info.
Quoted 3 lines
Now, other boards using the same SoC like the Beagle Bone Black are booting correctly and also am335x-evm which is very similar to
am335x-evmsk.dts.
Except for the gpio0 hack..
Quoted 7 lines
Nishanth has access to this board and his helping now with the debugging.
Quoted 4 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
Quoted 8 lines
Yeah, I'm doing my best to keep this driver up-to-date with the latest changes in gpiolib but it seems that is very hard to change the OMAP GPIO driver without breaking one of the gazillion TI platforms out there...
Quoted 3 lines
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
I got it to the point where some relatively recent u-boot was loading fine over JTAG but the first stage did not boot properly from NOR for some reason.
Regards,
Tony
Quoted 14 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
Quoted 7 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Quoted 24 lines · Kevin Hilman
Quoted 14 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
Quoted 7 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Quoted 7 lines
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Regards,
Nishanth Menon
Hello,
Quoted 34 lines · Nishanth Menon
Quoted 24 lines · Kevin Hilman
Quoted 14 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
Quoted 7 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Quoted 7 lines
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Quoted 6 lines
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Regards,
Nishanth Menon
I know that at least Aaro Koskinen (cc'ed here) still uses mainline on OMAP1 boards and he is always very helpful when is asked to test some changes on this platform.
Having said that I also wonder if at least we should split omap drivers to have separate support for DT-only (or in a path to be) and non-DT (and with no work towards migration) platforms. Since trying to support both DT and legacy booting is each time more hard.
Best regards,
Javier
Quoted 44 lines · Javier Martinez Canillas
Hello,
Quoted 34 lines · Nishanth Menon
Quoted 24 lines · Kevin Hilman
Quoted 14 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
Quoted 7 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Quoted 7 lines
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Quoted 6 lines
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Regards,
Nishanth Menon
Quoted 8 lines
I know that at least Aaro Koskinen (cc'ed here) still uses mainline on OMAP1 boards and he is always very helpful when is asked to test some changes on this platform.
Having said that I also wonder if at least we should split omap drivers to have separate support for DT-only (or in a path to be) and non-DT (and with no work towards migration) platforms. Since trying to support both DT and legacy booting is each time more hard.
It really should not matter what the configuration data for the drivers is. Both platform_data and DT data should be easily supported.
And we're moving towards using platform_get_irq() and other functions for drivers anyways as that's generic for all the drivers no matter what the driver data source is.
Regards,
Tony
Hello Tony,
Quoted 49 lines · Tony Lindgren
Quoted 48 lines · Javier Martinez Canillas
Hello,
Quoted 34 lines · Nishanth Menon
Quoted 24 lines · Kevin Hilman
Quoted 14 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
Quoted 7 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Quoted 7 lines
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Quoted 6 lines
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Regards,
Nishanth MenonI know that at least Aaro Koskinen (cc'ed here) still uses mainline on OMAP1 boards and he is always very helpful when is asked to test some changes on this platform.
Quoted 8 lines
Quoted 4 lines
Having said that I also wonder if at least we should split omap drivers to have separate support for DT-only (or in a path to be) and non-DT (and with no work towards migration) platforms. Since trying to support both DT and legacy booting is each time more hard.
It really should not matter what the configuration data for the drivers is. Both
platform_dataand DT data should be easily supported.
Yes, I think I expressed myself badly. I actually meant platforms that keep evolving vs platforms that nobody is active developing on them and is unlikely that will ever use the newer infrastructure/API/whatever that is added on the different subsystems.
In the GPIO OMAP driver example we have a lot of #ifdefery to separate OMAP1 and OMAP2+ code since OMAP1 does not support sparse IRQ (and probably never will) so it can't dynamically allocate IRQ numbers and I've seen similar things in other OMAP drivers.
But yes, the maintenance burden is not that much either, I was just thinking aloud if splitting these drivers would make sense or not.
Quoted 7 lines
And we're moving towards using
platform_get_irq()and other functions for drivers anyways as that's generic for all the drivers no matter what the driver data source is.Regards,
Tony
Best regards,
Javier
Quoted 9 lines · Javier Martinez Canillas
Quoted 2 lines · Tony Lindgren
It really should not matter what the configuration data for the drivers is. Both
platform_dataand DT data should be easily supported.Yes, I think I expressed myself badly. I actually meant platforms that keep evolving vs platforms that nobody is active developing on them and is unlikely that will ever use the newer infrastructure/API/whatever that is added on the different subsystems.
Quoted 7 lines
In the GPIO OMAP driver example we have a lot of #ifdefery to separate OMAP1 and OMAP2+ code since OMAP1 does not support sparse IRQ (and probably never will) so it can't dynamically allocate IRQ numbers and I've seen similar things in other OMAP drivers.
But yes, the maintenance burden is not that much either, I was just thinking aloud if splitting these drivers would make sense or not.
OK. Doing the omap1 sparse IRQ conversion has been on my todo list for quite a while. That should be quite easy to do. Sounds getting rid of the ifdeffery in the shared drivers is a good reason to do it.
The tricky part with omap1 from multiarch point of view is the clock framework conversion for multi arch support, at this rate it will be years before we get there :)
Regards,
Tony
Quoted 29 lines · Nishanth Menon
Quoted 28 lines · Kevin Hilman
Quoted 14 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
I've revised the patch again and I couldn't find the reason why certain boards are failing to boot.
I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it.
It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation.
Quoted 7 lines
I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward.
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Quoted 8 lines
Quoted 3 lines
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Why? There are people still using omap1 and it works just fine. And in general the maintenance work needed for omap1 is really minimal.
And in the GPIO case the issue was also discovered on new TI boards.
Regards,
Tony
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Nishanth Menon
Quoted 4 lines · Kevin Hilman
Quoted 2 lines · Linus Walleij
On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas <[email protected]> wrote:
[...]
Quoted 13 lines
Quoted 13 lines
Quoted 11 lines
Quoted 3 lines
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Quoted 9 lines
Quoted 3 lines
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Why? There are people still using omap1 and it works just fine. And in general the maintenance work needed for omap1 is really minimal.
And in the GPIO case the issue was also discovered on new TI boards.
I mean, yeah - hobby usage is nice.. but there is maintenance burden when it comes to ensuring generic drivers such as timers, gpio etc.. I am not saying we cannot maintain it, but if there are no strong reasons why to keep it alive, it kinda reduces the scope of modifications as kernel frameworks evolve to be generic. The OMAP1 generation of processors based boards are so hard to get and go running that developer access to these boards slow things down as well.
I understand that "strong reasons to keep it alive" is pretty subjective in nature.. but just throwing the thought out here.
Signature · 2 lines
Regards, Nishanth Menon
Quoted 31 lines · Nishanth Menon
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Nishanth Menon
Quoted 4 lines · Kevin Hilman
Quoted 2 lines · Linus Walleij
On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas <[email protected]> wrote:
[...]
Quoted 13 lines
Quoted 13 lines
Quoted 11 lines
Quoted 3 lines
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Quoted 9 lines
Quoted 3 lines
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Why? There are people still using omap1 and it works just fine. And in general the maintenance work needed for omap1 is really minimal.
And in the GPIO case the issue was also discovered on new TI boards.
Quoted 7 lines
I mean, yeah - hobby usage is nice.. but there is maintenance burden when it comes to ensuring generic drivers such as timers, gpio etc.. I am not saying we cannot maintain it, but if there are no strong reasons why to keep it alive, it kinda reduces the scope of modifications as kernel frameworks evolve to be generic. The OMAP1 generation of processors based boards are so hard to get and go running that developer access to these boards slow things down as well.
It's not a burden by any means like I said. And like I said, the drivers should work just fine no matter what the data source.
Having the platform_data around actually forces us to fix up the drivers so they work in the standard Linux way. So it's really the mixed state of drivers that are the issue here.
Quoted 2 lines
I understand that "strong reasons to keep it alive" is pretty subjective in nature.. but just throwing the thought out here.
Strong reasons as in people are using it. There just isn't any stronger reason available in Linux land.
Or what do you think is a "stronger reason" then? Merging random corporate snapshots of kernel code upstream from some hacked up kernel tree where the code has never even been even tested with the mainline kernel and is not usable for any available product? I don't think so :)
Regards,
Tony
Quoted 40 lines · Tony Lindgren
Quoted 31 lines · Nishanth Menon
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Nishanth Menon
Quoted 4 lines · Kevin Hilman
Quoted 2 lines · Linus Walleij
On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas <[email protected]> wrote:
[...]
Quoted 13 lines
Quoted 13 lines
Quoted 11 lines
Quoted 3 lines
We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Quoted 9 lines
Quoted 3 lines
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream? should it be time to deprecate it - say for 3.17 or so?
Why? There are people still using omap1 and it works just fine. And in general the maintenance work needed for omap1 is really minimal.
And in the GPIO case the issue was also discovered on new TI boards.
Quoted 7 lines
I mean, yeah - hobby usage is nice.. but there is maintenance burden when it comes to ensuring generic drivers such as timers, gpio etc.. I am not saying we cannot maintain it, but if there are no strong reasons why to keep it alive, it kinda reduces the scope of modifications as kernel frameworks evolve to be generic. The OMAP1 generation of processors based boards are so hard to get and go running that developer access to these boards slow things down as well.
Quoted 6 lines
It's not a burden by any means like I said. And like I said, the drivers should work just fine no matter what the data source.
Having the
platform_dataaround actually forces us to fix up the drivers so they work in the standard Linux way. So it's really the mixed state of drivers that are the issue here.
:) fair enough. I guess this question dies for the time being at least.
Quoted 8 lines
Quoted 3 lines
I understand that "strong reasons to keep it alive" is pretty subjective in nature.. but just throwing the thought out here.
Strong reasons as in people are using it. There just isn't any stronger reason available in Linux land.
Or what do you think is a "stronger reason" then? Merging random
The trigger was that even at TI, OMAP1s are hard to get to, in fact, I do not of one person in TI who seems to have a functioning OMAP1 platform - and context of my question came from that background and noticing others going through similar pain as well. Will continue to look around.
Quoted 4 lines
corporate snapshots of kernel code upstream from some hacked up kernel tree where the code has never even been even tested with the mainline kernel and is not usable for any available product? I don't think so :)
Thanks for the flame :D. "evil vendor" kernels have a purpose to serve and I guess we know why they exist - even though we might not agree with many of the reasonings or the way things are done there. I, for one, will refuse to get into a flame about it :D.
We are all believers in upstream code functioning with all available platforms we can get our hands on - if that was not our objective, we at TI would never have spend money and effort trying to get automated test environments for boards that corporate may not see much sense in it. It is part of our continued commitment to working together as a single Linux community - yep, we are not perfect or maybe even "good enough", but we always strive to improve.
Signature · 2 lines
Regards, Nishanth Menon
Hi,
Quoted 5 lines · Nishanth Menon
The trigger was that even at TI, OMAP1s are hard to get to, in fact, I do not of one person in TI who seems to have a functioning OMAP1 platform - and context of my question came from that background and noticing others going through similar pain as well. Will continue to look around.
There has been commercially available consumer products based on OMAP1 which can be still found places like ebay. E.g Nokia 770 runs mainline kernel out of the box. (Also Amstrad E3 works fine but you need to find an unused one because they locked the bootloader in a later firmware upgrade.) Never tested myself, but I think QEMU might even emulate some OMAP1 board.
A.
Quoted 2 lines · Nishanth Menon
Perhaps dumb question: but are there folks who really care about omap1 boot anymore in upstream?
Yes.
Quoted 1 line
should it be time to deprecate it - say for 3.17 or so?
No. It's a working platform and has users.
A.
Quoted 7 lines · Kevin Hilman
Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been able to get it booting again. I wonder if Spectrum Digital still has these available? Their websites[1] says "call for price."
Kevin
[1] http://www.spectrumdigital.com/product_info.php?products_id=39
Last time I called them, they do have a few available. They cost a few hundred USD though.
- Paul
Logs with with DEBUG_LL and early printk below:
Thread: http://marc.info/?t=139817273800014&r=1&w=2
Quoted 7 lines · Nishanth Menon
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat84: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqaQuoted 1 line
known
Quoted 8 lines
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C
9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6
looks like my fdt_high was 0xFFFFFFFF and fdt was at 0x80f80000 :( so got stomped all over...
Time for me to verify every platform again.
Signature · 2 lines
Regards, Nishanth Menon
Quoted 15 lines · Nishanth Menon
Logs with with
DEBUG_LLand early printk below:
Thread: http://marc.info/?t=139817273800014&r=1&w=2Quoted 10 lines · Nishanth Menon
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat84: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqaQuoted 1 line
known
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
Quoted 8 lines
Quoted 4 lines
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C
9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6looks like my
fdt_highwas0xFFFFFFFFand fdt was at0x80f80000:( so got stomped all over...Time for me to verify every platform again.
ok, boards updated with u-boot fixes etc..
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX
This one is in discussion in this thread.
2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu
3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG
4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw
we know of this one.
6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29BVtv6dR
7: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s21ThDvDWV
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s20XNhvNId
9: beaglebone: Boot PASS: http://slexy.org/raw/s2SqD9D9X8 10: craneboard: Boot PASS: http://slexy.org/raw/s20bcCjsJi 11: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20K7XSURP
12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2oDI6XGSV
13: n900: Boot PASS: http://slexy.org/raw/s2F9nMXZJr
14: pandaboard-es: Boot PASS: http://slexy.org/raw/s21M66ujw0
15: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2G7n7kez5
16: sdp2430: Boot PASS: http://slexy.org/raw/s21OIS6Z6H 17: sdp3430: Boot PASS: http://slexy.org/raw/s20pO2iusO 18: sdp4430: Boot PASS: http://slexy.org/raw/s20SVaZoDZ
19: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2H8TeWUxt
TOTAL = 19 boards, Booted Boards = 17, No Boot boards = 2
Apologies on the noise.
Signature · 2 lines
Regards, Nishanth Menon
Hello Nishanth,
Quoted 30 lines · Nishanth Menon
Quoted 15 lines · Nishanth Menon
Logs with with
DEBUG_LLand early printk below:
Thread: http://marc.info/?t=139817273800014&r=1&w=2Quoted 10 lines · Nishanth Menon
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat84: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqaQuoted 1 line
known
6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX
7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS
Quoted 8 lines
Quoted 4 lines
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C
9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6looks like my
fdt_highwas0xFFFFFFFFand fdt was at0x80f80000:( so got stomped all over...Time for me to verify every platform again.
ok, boards updated with u-boot fixes etc..
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX
This one is in discussion in this thread.
Quoted 5 lines
2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu
3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG
4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw
we know of this one.
The fix for this is [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5 [0] right?
So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you.
Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident.
Quoted 16 lines
6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29BVtv6dR
7: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s21ThDvDWV
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s20XNhvNId9: beaglebone: Boot PASS: http://slexy.org/raw/s2SqD9D9X8 10: craneboard: Boot PASS: http://slexy.org/raw/s20bcCjsJi 11: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20K7XSURP12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2oDI6XGSV
13: n900: Boot PASS: http://slexy.org/raw/s2F9nMXZJr
14: pandaboard-es: Boot PASS: http://slexy.org/raw/s21M66ujw0
15: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2G7n7kez516: sdp2430: Boot PASS: http://slexy.org/raw/s21OIS6Z6H 17: sdp3430: Boot PASS: http://slexy.org/raw/s20pO2iusO 18: sdp4430: Boot PASS: http://slexy.org/raw/s20SVaZoDZ19: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2H8TeWUxt
TOTAL = 19 boards, Booted Boards = 17, No Boot boards = 2
Quoted 6 lines
Apologies on the noise.
--
Regards,
Nishanth Menon
--
Thanks a lot and best regards,
Javier
On 04/22/2014 05:45 PM, Javier Martinez Canillas wrote:
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Time for me to verify every platform again.
ok, boards updated with u-boot fixes etc..
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX
This one is in discussion in this thread.
We just managed to get am335x-evm up and running as well.
am335x-evm: Boot PASS: http://slexy.org/raw/s2WSAKSG2S
I checked with DEBUG_LL a few mins back on AM335x-sk:
http://slexy.org/raw/s2P8L4FGBY
Quoted 9 lines
Quoted 6 lines
2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu
3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG
4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw
we know of this one.The fix for this is [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5 [0] right?
Yep, This is a different issue compared to the AM335x-sk discussion.
http://marc.info/?l=linux-omap&m=139819642824190&w=2
two patches for this one:
https://patchwork.kernel.org/patch/3871201/
https://patchwork.kernel.org/patch/4034201/
we are still debating about how to go about it.
Quoted 1 line
on AM335x-sk:
Quoted 6 lines
So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you.
Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident.
I could not find anything interesting yet. Peter did mention that reverting d04b76626e94 helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back.
Quoted 3 lines
Signature · 2 lines
Regards, Nishanth Menon
Quoted 43 lines · Nishanth Menon
On 04/22/2014 05:45 PM, Javier Martinez Canillas wrote:
[...]Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Time for me to verify every platform again.
ok, boards updated with u-boot fixes etc..
next-20140422-omap2plus_defconfig
1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2o4V7QFmX
This one is in discussion in this thread.We just managed to get am335x-evm up and running as well.
am335x-evm: Boot PASS: http://slexy.org/raw/s2WSAKSG2SI checked with
DEBUG_LLa few mins back on AM335x-sk:
http://slexy.org/raw/s2P8L4FGBYQuoted 9 lines
Quoted 6 lines
2: am3517-evm: Boot PASS: http://slexy.org/raw/s21U08MZIu
3: am37x-evm: Boot PASS: http://slexy.org/raw/s2TYm46GgG
4: am43xx-epos: Boot PASS: http://slexy.org/raw/s21wjoqqjl
5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2X8Rh0sSw
we know of this one.The fix for this is [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5 [0] right?
Yep, This is a different issue compared to the AM335x-sk discussion.
http://marc.info/?l=linux-omap&m=139819642824190&w=2
two patches for this one:
https://patchwork.kernel.org/patch/3871201/
https://patchwork.kernel.org/patch/4034201/we are still debating about how to go about it.
Quoted 1 line
on AM335x-sk:
Quoted 6 lines
So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you.
Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident.
Quoted 6 lines
I could not find anything interesting yet. Peter did mention that reverting
d04b76626e94helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back.
Great, thanks a lot for your help and sorry for the inconvenience!
Quoted 8 lines
Quoted 3 lines
--
Regards,
Nishanth Menon
Best regards,
Javier
On 01:08-20140423, Javier Martinez Canillas wrote:
[...]
Quoted 8 lines
Quoted 8 lines
on AM335x-sk:
Quoted 6 lines
So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you.
Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident.
Quoted 8 lines
Quoted 6 lines
I could not find anything interesting yet. Peter did mention that reverting
d04b76626e94helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back.Great, thanks a lot for your help and sorry for the inconvenience!
Yep - If I am correct, and as we all suspected, GPIO0_7 which controls the VTT regulator for DDR is getting configured as input, instead of output.
http://slexy.org/raw/s2gReMRZI6 (with diff:
http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was trying to truncate and isolate - had to switch to non-relaxed versions of writes to force sequencing with barriers to trace it down..)
Anyways, the key log is [0]:gpiochip_irq_map -> calls
irq_set_irq_type(irq, chip->irq_default_type);
which inturn triggers: gpio-omap.c's gpio_irq_type in this, logic:
if (!LINE_USED(bank->mod_usage, offset)) is invoked prior to setting the input type for the GPIO 0_7 (you can see the logic
walks through setting every GPIO to input!).
The original usage as far as I could discern was that this function was only called after probe got completed as the gpio requests were triggered.
There are probably many hacks possible, but a cleaner solution might involve gpio_irqchip knowing when to set the type and knowing which gpios not to mess with.
Example hack:
Since we call gpiochip_irqchip_add with IRQ_TYPE_NONE,
in gpio-omap's gpio_irq_type could do:
if (type == IRQ_TYPE_NONE) return 0;
boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other side effects I have'nt thought through..
[0]:
[ 25.504976] DONE gpio_irq_type: 533 bank 0xf9e07000, offset 7 [ 25.511052] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-next-20140422-00003-gd9fc91f-dirty #12 [ 25.520811] [<c0014cf0>] (unwind_backtrace) from [<c0011984>] (show_stack+0x10/0x14) [ 25.528870] [<c0011984>] (show_stack) from [<c05421b8>] (dump_stack+0x78/0x94) [ 25.536390] [<c05421b8>] (dump_stack) from [<c03016c8>] (gpio_irq_type+0x1b4/0x218) [ 25.544359] [<c03016c8>] (gpio_irq_type) from [<c008f0d4>] (__irq_set_trigger+0x5c/0xfc) [ 25.552774] [<c008f0d4>] (__irq_set_trigger) from [<c0090888>] (irq_set_irq_type+0x38/0x58) [ 25.561455] [<c0090888>] (irq_set_irq_type) from [<c02fbf4c>] (gpiochip_irq_map+0x60/0x68) [ 25.570047] [<c02fbf4c>] (gpiochip_irq_map) from [<c0092908>] (irq_domain_associate+0x70/0x1b8) [ 25.579087] [<c0092908>] (irq_domain_associate) from [<c0092abc>] (irq_create_mapping+0x6c/0xfc) [ 25.588216] [<c0092abc>] (irq_create_mapping) from [<c02fbe4c>] (gpiochip_irqchip_add+0xa8/0xf0) [ 25.597346] [<c02fbe4c>] (gpiochip_irqchip_add) from [<c0300bb8>] (omap_gpio_probe+0x2bc/0x8a4) [ 25.606386] [<c0300bb8>] (omap_gpio_probe) from [<c0354ee4>] (platform_drv_probe+0x18/0x48) [ 25.615068] [<c0354ee4>] (platform_drv_probe) from [<c03535d0>] (driver_probe_device+0x110/0x224) [ 25.624286] [<c03535d0>] (driver_probe_device) from [<c0351e64>] (bus_for_each_drv+0x5c/0x88) [ 25.633146] [<c0351e64>] (bus_for_each_drv) from [<c035348c>] (device_attach+0x74/0x8c) [ 25.641471] [<c035348c>] (device_attach) from [<c0352b68>] (bus_probe_device+0x88/0xb0) [ 25.649793] [<c0352b68>] (bus_probe_device) from [<c035114c>] (device_add+0x3a8/0x4dc) [ 25.658029] [<c035114c>] (device_add) from [<c045ccb8>] (of_platform_device_create_pdata+0x70/0x94) [ 25.667428] [<c045ccb8>] (of_platform_device_create_pdata) from [<c045cdb8>] (of_platform_bus_create+0xdc/0x184) [ 25.677990] [<c045cdb8>] (of_platform_bus_create) from [<c045ce1c>] (of_platform_bus_create+0x140/0x184) [ 25.687835] [<c045ce1c>] (of_platform_bus_create) from [<c045cec0>] (of_platform_populate+0x60/0x98) [ 25.697323] [<c045cec0>] (of_platform_populate) from [<c07ad190>] (pdata_quirks_init+0x34/0x44) [ 25.706364] [<c07ad190>] (pdata_quirks_init) from [<c07ace64>] (omap_generic_init+0x10/0x1c) [ 25.715136] [<c07ace64>] (omap_generic_init) from [<c079e50c>] (customize_machine+0x1c/0x40) [ 25.723906] [<c079e50c>] (customize_machine) from [<c0008a64>] (do_one_initcall+0x80/0x1c8) [ 25.732591] [<c0008a64>] (do_one_initcall) from [<c079bc94>] (kernel_init_freeable+0xfc/0x1cc) [ 25.741544] [<c079bc94>] (kernel_init_freeable) from [<c053cb1c>] (kernel_init+0x8/0xe4) [ 25.749958] [<c053cb1c>] (kernel_init) from [<c000e708>] (ret_from_fork+0x14/0x2c)
Signature · 2 lines
Regards, Nishanth Menon
Hello Nishanth and Tony,
Quoted 37 lines · Nishanth Menon
On 01:08-20140423, Javier Martinez Canillas wrote:
[...]Quoted 8 lines
Quoted 8 lines
on AM335x-sk:
Quoted 6 lines
So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you.
Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident.
Quoted 8 lines
Quoted 6 lines
I could not find anything interesting yet. Peter did mention that reverting
d04b76626e94helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back.Great, thanks a lot for your help and sorry for the inconvenience!
Yep - If I am correct, and as we all suspected,
GPIO0_7which controls the VTT regulator for DDR is getting configured as input, instead of output.
http://slexy.org/raw/s2gReMRZI6 (with diff:
http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was trying to truncate and isolate - had to switch to non-relaxed versions of writes to force sequencing with barriers to trace it down..)Anyways, the key log is [0]:
gpiochip_irq_map-> calls
irq_set_irq_type(irq, chip->irq_default_type);
which inturn triggers: gpio-omap.c'sgpio_irq_typein this, logic:
if (!LINE_USED(bank->mod_usage, offset)) is invoked prior to setting the input type for the GPIO 0_7 (you can see the logic
walks through setting every GPIO to input!).
Quoted 3 lines
The original usage as far as I could discern was that this function was only called after probe got completed as the gpio requests were triggered.
Thanks a lot for figuring out what was going on here. I think that is not correct for gpiochip_irq_map() to call this function. After all creating a mapping doesn't mean that the GPIO is actually used as an IRQ.
Quoted 5 lines
There are probably many hacks possible, but a cleaner solution might involve
gpio_irqchipknowing when to set the type and knowing which gpios not to mess with.
Quoted 7 lines
Example hack:
Since we callgpiochip_irqchip_addwithIRQ_TYPE_NONE,
in gpio-omap'sgpio_irq_typecould do:if (type == IRQ_TYPE_NONE) return 0;boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other side effects I have'nt thought through..
Linus, what do you think of the following patch?
Quoted 1 line
From
ede333e85e0320d32e8c2d123560808ed7e43eceMon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <[email protected]>
Date: Wed, 23 Apr 2014 09:13:54 +0200
Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map
function
Creating a mapping for a GPIO pin into the Linux virtual IRQ space does not necessarily mean that the GPIO is going to be used as an interrupt line, it only means that it could be used.
So, calling irq_set_irq_type() is not correct since that is already done either when a driver calls request_irq() or when the OF core calls of_irq_to_resource() because a device node defined a GPIO controller phandle as its "interrupt-parent".
In either case irq_set_irq_type() will be called and the GPIO controller driver will take any required action for an IRQ.
--- drivers/gpio/gpiolib.c | 1 - 1 file changed, 1 deletion(-)
drivers/gpio/gpiolib.c +0 -0
@@ -1402,7 +1402,6 @@ static int gpiochip_irq_map(struct irq_domain
*d, unsigned int irq,
#else
irq_set_noprobe(irq);
#endif
- irq_set_irq_type(irq, chip->irq_default_type);
return 0;
}
Signature · 1 line
1.9.1
Peter Ujfalusi
Tested-byQuoted 99 lines · Javier Martinez Canillas
Hello Nishanth and Tony,
Quoted 37 lines · Nishanth Menon
On 01:08-20140423, Javier Martinez Canillas wrote:
[...]Quoted 8 lines
Quoted 8 lines
on AM335x-sk:
Quoted 6 lines
So this makes only am335x-sk to fail with the gpiolib irpchip conversion as reported by Peter and you.
Do you know what special use of GPIO have this board to behave differently than the other boards? I've looked at the DTS but didn't find anything evident.
Quoted 8 lines
Quoted 6 lines
I could not find anything interesting yet. Peter did mention that reverting
d04b76626e94helped make the platform boot fine. I am trying to add a few prints and see which specific line does things go bad.. and if so why.. unfortunately, I am using the board remotely as well.. Will try to track this down in the next few hours and post back.Great, thanks a lot for your help and sorry for the inconvenience!
Yep - If I am correct, and as we all suspected,
GPIO0_7which controls the VTT regulator for DDR is getting configured as input, instead of output.
http://slexy.org/raw/s2gReMRZI6 (with diff:
http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was trying to truncate and isolate - had to switch to non-relaxed versions of writes to force sequencing with barriers to trace it down..)Anyways, the key log is [0]:
gpiochip_irq_map-> calls
irq_set_irq_type(irq, chip->irq_default_type);
which inturn triggers: gpio-omap.c'sgpio_irq_typein this, logic:
if (!LINE_USED(bank->mod_usage, offset)) is invoked prior to setting the input type for the GPIO 0_7 (you can see the logic
walks through setting every GPIO to input!).Quoted 3 lines
The original usage as far as I could discern was that this function was only called after probe got completed as the gpio requests were triggered.
Thanks a lot for figuring out what was going on here. I think that is not correct for
gpiochip_irq_map()to call this function. After all creating a mapping doesn't mean that the GPIO is actually used as an IRQ.Quoted 5 lines
There are probably many hacks possible, but a cleaner solution might involve
gpio_irqchipknowing when to set the type and knowing which gpios not to mess with.Quoted 7 lines
Example hack:
Since we callgpiochip_irqchip_addwithIRQ_TYPE_NONE,
in gpio-omap'sgpio_irq_typecould do:if (type == IRQ_TYPE_NONE) return 0;boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other side effects I have'nt thought through..
Linus, what do you think of the following patch?
From
ede333e85e0320d32e8c2d123560808ed7e43eceMon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <[email protected]>
Date: Wed, 23 Apr 2014 09:13:54 +0200
Subject: [PATCH 1/1] gpio: don't callirq_set_irq_type()on IRQ domain map
functionCreating a mapping for a GPIO pin into the Linux virtual IRQ space does not necessarily mean that the GPIO is going to be used as an interrupt line, it only means that it could be used.
So, calling
irq_set_irq_type()is not correct since that is already done either when a driver callsrequest_irq()or when the OF core callsof_irq_to_resource()because a device node defined a GPIO controller phandle as its "interrupt-parent".In either case
irq_set_irq_type()will be called and the GPIO controller driver will take any required action for an IRQ.Signed-off-by Javier Martinez Canillas <[email protected]>--- drivers/gpio/gpiolib.c | 1 - 1 file changed, 1 deletion(-)drivers/gpio/gpiolib.c +0
-1@@ -1402,7 +1402,6 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #elseirq_set_noprobe (irq );#endif -irq_set_irq_type (irq, chip->irq_default_type);return 0 ;
Quoted 2 lines
}
Thanks, this makes am335x-evmsk boot with linux-next.
Quoted 7 lines · Javier Martinez Canillas
Linus, what do you think of the following patch?
From
ede333e85e0320d32e8c2d123560808ed7e43eceMon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <[email protected]>
Date: Wed, 23 Apr 2014 09:13:54 +0200
Subject: [PATCH 1/1] gpio: don't callirq_set_irq_type()on IRQ domain map
function
(...)
So no setting a default type in the mapping function...
Quoted 1 line
-
irq_set_irq_type(irq, chip->irq_default_type);
But there are drivers exploiting this to set up the hardware to some default state :-(
What about this:
if (chip->irq_default_type != IRQ_TYPE_NONE)
irq_set_irq_type(irq, chip->irq_default_type);
This way you can pass IRQ_TYPE_NONE and nothing happens in the mapping.
Yours,
Linus Walleij
Quoted 19 lines · Linus Walleij
Quoted 7 lines · Javier Martinez Canillas
Linus, what do you think of the following patch?
From
ede333e85e0320d32e8c2d123560808ed7e43eceMon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <[email protected]>
Date: Wed, 23 Apr 2014 09:13:54 +0200
Subject: [PATCH 1/1] gpio: don't callirq_set_irq_type()on IRQ domain map
function(...)
So no setting a default type in the mapping function...
Quoted 1 line
-
irq_set_irq_type(irq, chip->irq_default_type);But there are drivers exploiting this to set up the hardware to some default state :-(
Quoted 7 lines
What about this:
if (
chip->irq_default_type!=IRQ_TYPE_NONE)irq_set_irq_type(irq, chip->irq_default_type);This way you can pass
IRQ_TYPE_NONEand nothing happens in the mapping.
What if these drivers depend on IRQ_TYPE_NONE to do something for the GPIO pins?
would you expect these drivers to pass IRQ_TYPE_DEFAULT? OR I wonder if we could pass some flag like -1 for platforms that dont care?
Signature · 2 lines
Regards, Nishanth Menon
Quoted 4 lines · Nishanth Menon
Quoted 2 lines · Linus Walleij
What about this:
Quoted 8 lines
Quoted 5 lines
if (
chip->irq_default_type!=IRQ_TYPE_NONE)irq_set_irq_type(irq, chip->irq_default_type);This way you can pass
IRQ_TYPE_NONEand nothing happens in the mapping.What if these drivers depend on
IRQ_TYPE_NONEto do something for the GPIO pins?
Yeah :-(
Quoted 1 line
would you expect these drivers to pass
IRQ_TYPE_DEFAULT?
Actually that sounds like a good idea. Maybe we can go over the few drivers that pass IRQ_TYPE_NONE and see what they actually want. There are not *too* many users of this call yet.
Quoted 2 lines
OR I wonder
if we could pass some flag like -1 for platforms that dont care?
The flags parameter to gpiochip_irqchip_add() is unsigned... Switching to IRQ_TYPE_DEFAULT for drivers that want this is likely the sane thing to do.
Yours,
Linus Walleij
Quoted 25 lines · Linus Walleij
Quoted 4 lines · Nishanth Menon
Quoted 2 lines · Linus Walleij
What about this:
Quoted 8 lines
Quoted 5 lines
if (
chip->irq_default_type!=IRQ_TYPE_NONE)irq_set_irq_type(irq, chip->irq_default_type);This way you can pass
IRQ_TYPE_NONEand nothing happens in the mapping.What if these drivers depend on
IRQ_TYPE_NONEto do something for the GPIO pins?Yeah :-(
Quoted 1 line
would you expect these drivers to pass
IRQ_TYPE_DEFAULT?Actually that sounds like a good idea. Maybe we can go over the few drivers that pass
IRQ_TYPE_NONEand see what they actually want. There are not *too* many users of this call yet.Quoted 2 lines
OR I wonder
if we could pass some flag like -1 for platforms that dont care?
Quoted 6 lines
The flags parameter to
gpiochip_irqchip_add()is unsigned... Switching toIRQ_TYPE_DEFAULTfor drivers that want this is likely the sane thing to do.Yours,
Linus Walleij
I prefer to have an explicit way to tell gpiolib whether it has to set a default IRQ type or not than relying on passing magic numbers like -1.
What do you think about the following patch? Although I agree that if we can use IRQ_TYPE_NONE as you propose then tht is a much better and efficient solution that this patch.
Best regards,
Javier
Quoted 1 line
From
8720c6798f86b71d8b11c57ecb7bae86a4ee656bMon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <[email protected]>
Date: Wed, 23 Apr 2014 16:45:05 +0200
Subject: [RFC] gpio: don't set IRQ default type unconditionally
Creating a mapping for a GPIO pin into the Linux virtual IRQ space does not necessarily mean that the GPIO is going to be used as an interrupt line, it only mean that it could be used.
But current gpiolib irqchip .map function handler calls to irq_set_irq_type() for each GPIO pin in the bank. Some drivers assume that this function is called either because a driver has explicitly requested an IRQ with request_irq() or that a DT device node has defined a GPIO controller phandle as its "interrupt-parent" and setups the chip accordingly.
Others drivers have different semantics and expects that a irq_set_irq_type() would setup the hardware to be some default state.
So is better to allow each driver to choose whether they want to set a default IRQ type on the mapping function or not.
--- drivers/gpio/gpio-omap.c | 1 + drivers/gpio/gpiolib.c | 3 ++- include/linux/gpio/driver.h | 1 + 3 files changed, 4 insertions(+), 1 deletion(-)
drivers/gpio/gpio-omap.c +1 -0
@@ -1101,6 +1101,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank) gpio += bank->width; } bank->chip.ngpio = bank->width; + bank->chip.set_irq_default = false; ret =gpiochip_add (&bank->chip);if (ret) {
drivers/gpio/gpiolib.c +0 -0
@@ -1402,7 +1402,8 @@ static int gpiochip_irq_map(struct irq_domain
*d, unsigned int irq,
#else
irq_set_noprobe(irq);
#endif
- irq_set_irq_type(irq, chip->irq_default_type);
+ if (chip->set_irq_default)
+ irq_set_irq_type(irq, chip->irq_default_type);
return 0;
}
include/linux/gpio/driver.h +1 -0
@@ -113,6 +113,7 @@ struct gpio_chip {unsigned int irq_base;irq_flow_handler_t irq_handler;unsigned int irq_default_type; +bool set_irq_default;#endif #if defined(CONFIG_OF_GPIO )
Signature · 1 line
1.9.1
Quoted 3 lines · Javier Martinez Canillas
What do you think about the following patch? Although I agree that if we can use
IRQ_TYPE_NONEas you propose then tht is a much better and efficient solution that this patch.
Let's try IRQ_TYPE_NONE first and if that fails we go back to this.
I've pushed the current patch to linux-next.
Yours,
Linus Walleij