regressions in linux-next?

regressions in linux-next?

[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/s2SJwrVat8
 4: am43xx-epos:  Boot PASS: http://slexy.org/raw/s2184jfKlq
 5: am43xx-gpevm:  Boot FAIL: http://slexy.org/raw/s21qIYDHqa
>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
>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
>known.
 7: BeagleBoard-XM:  Boot PASS: http://slexy.org/raw/s29I92x0p3
 8: beagleboard-vanilla:  Boot FAIL: http://slexy.org/raw/s2GqJbMp7C
>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
>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

-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Peter Ujfalusi]

On 04/22/2014 04:18 PM, Nishanth Menon wrote:
> 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
>> 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
>> 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.


>  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
>> known.
>  7: BeagleBoard-XM:  Boot PASS: http://slexy.org/raw/s29I92x0p3
>  8: beagleboard-vanilla:  Boot FAIL: http://slexy.org/raw/s2GqJbMp7C
>> 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
>> 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
> 


-- 
Péter
--
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

Re: regressions in linux-next?

[Nishanth Menon]

Logs with with DEBUG_LL and early printk below:
Thread: http://marc.info/?t=139817273800014&r=1&w=2

On 04/22/2014 08:18 AM, Nishanth Menon wrote:
> 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
>> 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
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.


-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Javier Martinez Canillas]

Hello Peter and Nishanth,

On Tue, Apr 22, 2014 at 3:29 PM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/22/2014 04:18 PM, Nishanth Menon wrote:
>> 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
>>> 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
>>> 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.
>

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

>
>>  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
>>> known.
>>  7: BeagleBoard-XM:  Boot PASS: http://slexy.org/raw/s29I92x0p3
>>  8: beagleboard-vanilla:  Boot FAIL: http://slexy.org/raw/s2GqJbMp7C
>>> 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
>>> 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
>>
>
>
> --
> Péter
> --
> 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
--
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

Re: regressions in linux-next?

[Ezequiel Garcia]

On Apr 22, Javier Martinez Canillas wrote:
> On Tue, Apr 22, 2014 at 3:29 PM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> > On 04/22/2014 04:18 PM, Nishanth Menon wrote:
> >> 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
> >>> 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
> >>> 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.
> >
> 
> 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,
-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: regressions in linux-next?

[Nishanth Menon]

On 04/22/2014 10:13 AM, Nishanth Menon wrote:
> Logs with with DEBUG_LL and early printk below:
> Thread: http://marc.info/?t=139817273800014&r=1&w=2
> 
> On 04/22/2014 08:18 AM, Nishanth Menon wrote:
>> 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
>>> 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
> 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.
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.

-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Linus Walleij]

On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:

> 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

Re: regressions in linux-next?

[Javier Martinez Canillas]

Hello Ezequiel,

On Tue, Apr 22, 2014 at 9:37 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> On Apr 22, Javier Martinez Canillas wrote:
>> On Tue, Apr 22, 2014 at 3:29 PM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> > On 04/22/2014 04:18 PM, Nishanth Menon wrote:
>> >> 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
>> >>> 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
>> >>> 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.
>> >
>>
>> 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.
>

Thanks a lot for testing the patches, then is not a problem with all
am335x since BBB is booting correctly.

> 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

> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: regressions in linux-next?

[Javier Martinez Canillas]

Hello Nishanth,

On Tue, Apr 22, 2014 at 11:57 PM, Nishanth Menon <nm@ti.com> wrote:
> On 04/22/2014 10:13 AM, Nishanth Menon wrote:
>> Logs with with DEBUG_LL and early printk below:
>> Thread: http://marc.info/?t=139817273800014&r=1&w=2
>>
>> On 04/22/2014 08:18 AM, Nishanth Menon wrote:
>>> 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
>>>> 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
>> 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.
> 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.

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.

>  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.
>
> --
> Regards,
> Nishanth Menon
> --

Thanks a lot and best regards,
Javier

[0]: http://www.spinics.net/lists/linux-omap/msg104702.html

Re: regressions in linux-next?

[Nishanth Menon]

On 04/22/2014 05:45 PM, Javier Martinez Canillas wrote:
[...]
>>> 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

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

> 

on AM335x-sk:
> 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.

> 
> [0]: http://www.spinics.net/lists/linux-omap/msg104702.html
> 


-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Javier Martinez Canillas]

Hello Linus,

On Wed, Apr 23, 2014 at 12:00 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>
>> 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.
>

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.

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

> 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

Re: regressions in linux-next?

[Javier Martinez Canillas]

On Wed, Apr 23, 2014 at 12:52 AM, Nishanth Menon <nm@ti.com> wrote:
> On 04/22/2014 05:45 PM, Javier Martinez Canillas wrote:
> [...]
>>>> 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
>
>>>
>>>  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.
>
>>
>
> on AM335x-sk:
>> 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.
>

Great, thanks a lot for your help and sorry for the inconvenience!

>>
>> [0]: http://www.spinics.net/lists/linux-omap/msg104702.html
>>
>
>
> --
> Regards,
> Nishanth Menon

Best regards,
Javier

Re: regressions in linux-next?

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [140422 16:03]:
> Hello Linus,
> 
> On Wed, Apr 23, 2014 at 12:00 AM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
> > On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
> > <javier@dowhile0.org> wrote:
> >
> >> 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.
> >
> 
> 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.
 
> 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..
 
> Nishanth has access to this board and his helping now with the debugging.
> 
> > 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...
> 
> > 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

Re: regressions in linux-next?

[Nishanth Menon]

On 01:08-20140423, Javier Martinez Canillas wrote:
[...]
> > on AM335x-sk:
> >> 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.
> >
> 
> 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)
-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Javier Martinez Canillas]

Hello Nishanth and Tony,

On Wed, Apr 23, 2014 at 3:30 AM, Nishanth Menon <nm@ti.com> wrote:
> On 01:08-20140423, Javier Martinez Canillas wrote:
> [...]
>> > on AM335x-sk:
>> >> 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.
>> >
>>
>> 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.

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.

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

Linus, what do you think of the following patch?

>From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
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.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/gpio/gpiolib.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c12fe9d..b493781 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -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;
 }
-- 
1.9.1

Re: regressions in linux-next?

[Peter Ujfalusi]

On 04/23/2014 10:24 AM, Javier Martinez Canillas wrote:
> Hello Nishanth and Tony,
> 
> On Wed, Apr 23, 2014 at 3:30 AM, Nishanth Menon <nm@ti.com> wrote:
>> On 01:08-20140423, Javier Martinez Canillas wrote:
>> [...]
>>>> on AM335x-sk:
>>>>> 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.
>>>>
>>>
>>> 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.
> 
> 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.
> 
>>
>> 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..
> 
> Linus, what do you think of the following patch?
> 
> From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> 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.
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/gpio/gpiolib.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index c12fe9d..b493781 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -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;
>  }
> 

Thanks, this makes am335x-evmsk boot with linux-next.

Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

Re: regressions in linux-next?

[Linus Walleij]

On Wed, Apr 23, 2014 at 9:24 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:

> Linus, what do you think of the following patch?
>
> From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> 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
(...)

So no setting a default type in the mapping function...

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

Re: regressions in linux-next?

[Nishanth Menon]

On 04/23/2014 08:01 AM, Linus Walleij wrote:
> On Wed, Apr 23, 2014 at 9:24 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
> 
>> Linus, what do you think of the following patch?
>>
>> From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> 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
> (...)
> 
> So no setting a default type in the mapping function...
> 
>> - 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.

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?


-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Linus Walleij]

On Wed, Apr 23, 2014 at 3:29 PM, Nishanth Menon <nm@ti.com> wrote:
> On 04/23/2014 08:01 AM, Linus Walleij wrote:

>> 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.
>
> What if these drivers depend on IRQ_TYPE_NONE to do something for the
> GPIO pins?

Yeah :-(

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

> 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

Re: regressions in linux-next?

[Javier Martinez Canillas]

On Wed, Apr 23, 2014 at 4:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Apr 23, 2014 at 3:29 PM, Nishanth Menon <nm@ti.com> wrote:
>> On 04/23/2014 08:01 AM, Linus Walleij wrote:
>
>>> 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.
>>
>> What if these drivers depend on IRQ_TYPE_NONE to do something for the
>> GPIO pins?
>
> Yeah :-(
>
>> 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.
>
>> 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

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

>From 8720c6798f86b71d8b11c57ecb7bae86a4ee656b Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
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.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/gpio/gpio-omap.c    | 1 +
 drivers/gpio/gpiolib.c      | 3 ++-
 include/linux/gpio/driver.h | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8cc9e91..2e23858 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -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) {
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c12fe9d..f12aea3 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -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;
 }
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 573e4f3..168c93e 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -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)
-- 
1.9.1

Re: regressions in linux-next?

[Linus Walleij]

On Wed, Apr 23, 2014 at 4:50 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:

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

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

Re: regressions in linux-next?

[Kevin Hilman]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>
>> 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 :-/

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

Re: regressions in linux-next?

[Nishanth Menon]

On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>
>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>
>>> 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 :-/
>
> 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

Re: regressions in linux-next?

[Javier Martinez Canillas]

Hello,

On Thu, Apr 24, 2014 at 5:25 PM, Nishanth Menon <nm@ti.com> wrote:
> On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> Linus Walleij <linus.walleij@linaro.org> writes:
>>
>>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
>>> <javier@dowhile0.org> wrote:
>>>
>>>> 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 :-/
>>
>> 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

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

Re: regressions in linux-next?

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [140424 08:25]:
> On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
> > Linus Walleij <linus.walleij@linaro.org> writes:
> >
> >> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
> >> <javier@dowhile0.org> wrote:
> >>
> >>> 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 :-/
> >
> > 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?

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

Re: regressions in linux-next?

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [140424 08:37]:
> Hello,
> 
> On Thu, Apr 24, 2014 at 5:25 PM, Nishanth Menon <nm@ti.com> wrote:
> > On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
> >> Linus Walleij <linus.walleij@linaro.org> writes:
> >>
> >>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
> >>> <javier@dowhile0.org> wrote:
> >>>
> >>>> 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 :-/
> >>
> >> 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
> 
> 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

Re: regressions in linux-next?

[Nishanth Menon]

On 04/24/2014 10:40 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [140424 08:25]:
>> On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>> Linus Walleij <linus.walleij@linaro.org> writes:
>>>
>>>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
>>>> <javier@dowhile0.org> wrote:
[...]
>>>> 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
>>
>>
>> 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.


-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [140424 08:47]:
> On 04/24/2014 10:40 AM, Tony Lindgren wrote:
> > * Nishanth Menon <nm@ti.com> [140424 08:25]:
> >> On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
> >>> Linus Walleij <linus.walleij@linaro.org> writes:
> >>>
> >>>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
> >>>> <javier@dowhile0.org> wrote:
> [...]
> >>>> 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
> >>
> >>
> >> 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.

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.

> 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

Re: regressions in linux-next?

[Javier Martinez Canillas]

Hello Tony,

On Thu, Apr 24, 2014 at 5:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Javier Martinez Canillas <javier@dowhile0.org> [140424 08:37]:
>> Hello,
>>
>> On Thu, Apr 24, 2014 at 5:25 PM, Nishanth Menon <nm@ti.com> wrote:
>> > On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> >> Linus Walleij <linus.walleij@linaro.org> writes:
>> >>
>> >>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
>> >>> <javier@dowhile0.org> wrote:
>> >>>
>> >>>> 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 :-/
>> >>
>> >> 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
>>
>> 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.
>

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.

> 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

Re: regressions in linux-next?

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [140424 09:33]:
> On Thu, Apr 24, 2014 at 5:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> > It really should not matter what the configuration data for the
> > drivers is. Both platform_data and 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.

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

Re: regressions in linux-next?

[Nishanth Menon]

On 04/24/2014 11:17 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [140424 08:47]:
>> On 04/24/2014 10:40 AM, Tony Lindgren wrote:
>>> * Nishanth Menon <nm@ti.com> [140424 08:25]:
>>>> On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>> Linus Walleij <linus.walleij@linaro.org> writes:
>>>>>
>>>>>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
>>>>>> <javier@dowhile0.org> wrote:
>> [...]
>>>>>> 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
>>>>
>>>>
>>>> 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.
> 
> 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.

:) fair enough. I guess this question dies for the time being at least.

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

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

-- 
Regards,
Nishanth Menon

Re: regressions in linux-next?

[Aaro Koskinen]

On Thu, Apr 24, 2014 at 10:25:29AM -0500, Nishanth Menon wrote:
> Perhaps dumb question: but are there folks who really care about omap1
> boot anymore in upstream?

Yes.

> should it be time to deprecate it - say for 3.17 or so?

No. It's a working platform and has users.

A.

Re: regressions in linux-next?

[Aaro Koskinen]

Hi,

On Thu, Apr 24, 2014 at 12:08:00PM -0500, Nishanth Menon wrote:
> 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.

Re: regressions in linux-next?

[Paul Walmsley]

On Thu, 24 Apr 2014, Kevin Hilman wrote:

> 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