linux 4.2-rc1 broken Nokia N900

Quoted 24 lines · Sebastian Reichel

[+cc Michael Welling <[email protected]>, author of all omap-spi patches between 4.1 and 4.2-rc1]
Hi,
Quoted 19 lines · Tony Lindgren
Quoted 18 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Here are some relevant snippets form dmesg:
[   13.933959] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09802c
[   13.940490] pgd = cfb38000
[   13.946594] [fa09802c] *pgd=48011452(bad)
[   13.952758] Internal error: : 1028 [#1] PREEMPT ARM
[   13.958862] Modules linked in: tsc2005(+) omap_sham twl4030_wdt omap_wdt
[   13.965332] CPU: 0 PID: 183 Comm: modprobe Not tainted 4.2.0-rc1+ #363
[   13.971801] Hardware name: Nokia RX-51 board
[   13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000
[   13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c

Here is the disassembly of the omap2_mcspi_set_cs function from my compiler:
00000040 <omap2_mcspi_set_cs>:

      40:       e2803e25        add     r3, r0, #592    ; 0x250
      44:       e5902258        ldr     r2, [r0, #600]  ; 0x258
      48:       e1d330b2        ldrh    r3, [r3, #2]
      4c:       e3130004        tst     r3, #4
      50:       12211001        eorne   r1, r1, #1
      54:       e3520000        cmp     r2, #0
      58:       012fff1e        bxeq    lr
      5c:       e5923018        ldr     r3, [r2, #24]
      60:       e3510000        cmp     r1, #0
      64:       13c33601        bicne   r3, r3, #1048576        ; 0x100000
      68:       03833601        orreq   r3, r3, #1048576        ; 0x100000
      6c:       e5823018        str     r3, [r2, #24]
      70:       e5902258        ldr     r2, [r0, #600]  ; 0x258
      74:       e5922000        ldr     r2, [r2]
      78:       e582302c        str     r3, [r2, #44]   ; 0x2c
      7c:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      80:       e5933000        ldr     r3, [r3]
      84:       e593202c        ldr     r2, [r3, #44]   ; 0x2c
      88:       e12fff1e        bx      lr

The omap2_mcspi_set_cs function is being called before the controller_state is initialized in omap2_mcspi_setup.

That is why there is a conditional checking if controller_state is NULL.

Perhaps the controller_state is uninitialized but has garbage instead of NULL causing the data abort.

Though that does not make much sense because a similar check in the setup function did not cause a data abort in the past.

Not sure what is going wrong here.

Could you do a objdump with the compiler you are using?

Quoted 60 lines

Quoted 45 lines

Quoted 36 lines

[   13.991485] LR is at spi_set_cs+0x5c/0x60
[   13.997985] pc : [<c02bd3ac>]    lr : [<c02baecc>]    psr: 20000013
[   13.997985] sp : cb1f3dd0  ip : 00000001  fp : 00000004
[   14.011260] r10: cfce5be8  r9 : 00000fff  r8 : c0654f98
[   14.017913] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : 00000000
[   14.024505] r3 : 200103dc  r2 : fa098000  r1 : 00000001  r0 : cf09bc00
[   14.031036] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   14.037689] Control: 10c5387d  Table: 8fb38019  DAC: 00000015
[   14.044403] Process modprobe (pid: 183, stack limit = 0xcb1f2210)
[   14.051300] Stack: (0xcb1f3dd0 to 0xcb1f4000)
[   14.058105] 3dc0:                                     cf09bc00 c02bafa4 cf09bc00 cf09bc00
[   14.065277] 3de0: bf013444 bf01254c cf0e2230 cf0e2230 00000001 c0654f98 00000fff 00000fff
[   14.072570] 3e00: 00000008 00000002 00000118 00001f40 00000031 cf09bc00 ffffffed bf013444
[   14.080078] 3e20: 00000031 c0654f98 cb1f2000 00000000 00000000 c02bb5c0 cf09bc00 00000000
[   14.087738] 3e40: bf013454 c027a2f4 00000000 cf09bc00 bf013454 bf013454 00000000 c027a594
[   14.095367] 3e60: 00000000 cf09bc00 cf09bc34 c027a60c bf013454 cb1f3e80 c027a5ac c0278ec8
[   14.102935] 3e80: cf972c4c cf09d630 bf013454 bf013454 cbb55300 c06848d8 00000000 c0279c84
[   14.110473] 3ea0: bf01327c bf01327d 00000000 bf013454 cb889180 00000000 c0654f98 c027b0c8
[   14.117980] 3ec0: 00000000 bf015000 cb889180 c00095b0 0040003e cfe6a080 0040003f 00000000
[   14.125457] 3ee0: 00080000 cfcf9000 cb1f2000 60000013 0040003e cbf1bbc0 00000000 00000001
[   14.132843] 3f00: bf0134cc cb1f2000 bf0134c0 cb1f3f58 00000000 c04352d0 cf801f00 000000d0
[   14.140136] 3f20: bf0134c0 bf0134c0 0000416c cb889040 00000080 c000ebe4 cb1f2000 c0089f68
[   14.147308] 3f40: bf0134c0 cbf1bc00 001a9193 0000416c 001f8d20 c008ab30 d0b10000 0000416c
[   14.154571] 3f60: d0b1267c d0b1252b d0b13514 000016c0 00001ad0 00000000 00000000 00000000
[   14.161865] 3f80: 0000001f 00000020 00000017 00000014 00000012 00000000 00201208 00000000
[   14.169097] 3fa0: 00000000 c000ea60 00201208 00000000 001f8d20 0000416c 001a9193 00000000
[   14.176177] 3fc0: 00201208 00000000 00000000 00000080 00208c20 001a9193 bee09e98 00000000
[   14.183197] 3fe0: b6f742b4 bee09ae4 000153f0 000093e4 60000010 001f8d20 72757463 69665f65
[   14.190277] [<c02bd3ac>] (omap2_mcspi_set_cs) from [<c02baecc>] (spi_set_cs+0x5c/0x60)
[   14.197479] [<c02baecc>] (spi_set_cs) from [<c02bafa4>] (spi_setup+0xd4/0x10c)
[   14.204833] [<c02bafa4>] (spi_setup) from [<bf01254c>] (tsc2005_probe+0x104/0x484 [tsc2005])
[   14.212249] [<bf01254c>] (tsc2005_probe [tsc2005]) from [<c02bb5c0>] (spi_drv_probe+0x50/0x6c)
[   14.219818] [<c02bb5c0>] (spi_drv_probe) from [<c027a2f4>] (really_probe+0xd4/0x230)
[   14.227478] [<c027a2f4>] (really_probe) from [<c027a594>] (driver_probe_device+0x30/0x48)
[   14.235290] [<c027a594>] (driver_probe_device) from [<c027a60c>] (__driver_attach+0x60/0x84)
[   14.243286] [<c027a60c>] (__driver_attach) from [<c0278ec8>] (bus_for_each_dev+0x50/0x84)

Quoted 8 lines

[   14.251281] [<c0278ec8>] (bus_for_each_dev) from [<c0279c84>] (bus_add_driver+0xcc/0x1e0)
[   14.259246] [<c0279c84>] (bus_add_driver) from [<c027b0c8>] (driver_register+0x9c/0xe0)
[   14.267272] [<c027b0c8>] (driver_register) from [<c00095b0>] (do_one_initcall+0x100/0x1b0)
[   14.275421] [<c00095b0>] (do_one_initcall) from [<c0089f68>] (do_init_module+0x58/0x1bc)
[   14.283477] [<c0089f68>] (do_init_module) from [<c008ab30>] (SyS_init_module+0x54/0x64)
[   14.291412] [<c008ab30>] (SyS_init_module) from [<c000ea60>] (ret_fast_syscall+0x0/0x3c)
[   14.299407] Code: e5823018 e5902188 e5922000 e582302c (e592302c) 
[   14.307403] ---[ end trace d21553dcaefcb5ac ]---

Quoted 6 lines

That seems to be a regression with the SPI driver. Care to git bisect it? It's probably one of the following commits:
$ git log --pretty=oneline v4.1..v4.2-rc2 drivers/spi/spi-omap2-mcspi.c
Looks like just modprobe tsc2005 is enough to reproduce it.

mh omap2_mcspi_set_cs has been introduced in this range (ddcad7e9068) and from the commit message it seems to be a fix for the first commit (b28cb9414d) in this range.

Just looking at the commit log, I sugest starting with testing if ddcad7e9068 is affected and if b28cb9414d~1 is not affected.

-- Sebastian

Pali Rohár

author

2015-07-13 17:09 UTC #4 lore raw

Quoted 59 lines · On Monday 13 July 2015 19:03:44 Michael Welling wrote:

Quoted 26 lines · Sebastian Reichel
[+cc Michael Welling <[email protected]>, author of all omap-spi patches between 4.1 and 4.2-rc1]
Hi,
Quoted 20 lines · Tony Lindgren
Quoted 19 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Here are some relevant snippets form dmesg:
[   13.933959] Unhandled fault: external abort on non-linefetch
(0x1028) at 0xfa09802c [   13.940490] pgd = cfb38000
[   13.946594] [fa09802c] *pgd=48011452(bad)
[   13.952758] Internal error: : 1028 [#1] PREEMPT ARM
[   13.958862] Modules linked in: tsc2005(+) omap_sham
twl4030_wdt omap_wdt [   13.965332] CPU: 0 PID: 183 Comm:
modprobe Not tainted 4.2.0-rc1+ #363 [   13.971801] Hardware
name: Nokia RX-51 board
[   13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000
[   13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c
Here is the disassembly of the omap2_mcspi_set_cs function from my
compiler: 00000040 <omap2_mcspi_set_cs>:
      40:       e2803e25        add     r3, r0, #592    ; 0x250
      44:       e5902258        ldr     r2, [r0, #600]  ; 0x258
      48:       e1d330b2        ldrh    r3, [r3, #2]
      4c:       e3130004        tst     r3, #4
      50:       12211001        eorne   r1, r1, #1
      54:       e3520000        cmp     r2, #0
      58:       012fff1e        bxeq    lr
      5c:       e5923018        ldr     r3, [r2, #24]
      60:       e3510000        cmp     r1, #0
      64:       13c33601        bicne   r3, r3, #1048576        ;
0x100000 68:       03833601        orreq   r3, r3, #1048576        ;
0x100000 6c:       e5823018        str     r3, [r2, #24]
      70:       e5902258        ldr     r2, [r0, #600]  ; 0x258
      74:       e5922000        ldr     r2, [r2]
      78:       e582302c        str     r3, [r2, #44]   ; 0x2c
      7c:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      80:       e5933000        ldr     r3, [r3]
      84:       e593202c        ldr     r2, [r3, #44]   ; 0x2c
      88:       e12fff1e        bx      lr
The omap2_mcspi_set_cs function is being called before the controller_state is initialized in omap2_mcspi_setup.
That is why there is a conditional checking if controller_state is NULL.
Perhaps the controller_state is uninitialized but has garbage instead of NULL causing the data abort.

Quoted 7 lines

Though that does not make much sense because a similar check in the setup function did not cause a data abort in the past.
Not sure what is going wrong here.
Could you do a objdump with the compiler you are using?

Hello, here is my objdump of 4.2-rc2 version:

00000064 <omap2_mcspi_set_cs>:

      64:       e3003182        movw    r3, #386        ; 0x182
      68:       e19030b3        ldrh    r3, [r0, r3]
      6c:       e3130004        tst     r3, #4
      70:       0a000001        beq     7c <omap2_mcspi_set_cs+0x18>
      74:       e2711001        rsbs    r1, r1, #1
      78:       33a01000        movcc   r1, #0
      7c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      80:       e3520000        cmp     r2, #0
      84:       012fff1e        bxeq    lr
      88:       e5923018        ldr     r3, [r2, #24]
      8c:       e3510000        cmp     r1, #0
      90:       13c33601        bicne   r3, r3, #1048576        ; 0x100000
      94:       03833601        orreq   r3, r3, #1048576        ; 0x100000
      98:       e5823018        str     r3, [r2, #24]
      9c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      a0:       e5922000        ldr     r2, [r2]
      a4:       e582302c        str     r3, [r2, #44]   ; 0x2c
      a8:       e592302c        ldr     r3, [r2, #44]   ; 0x2c
      ac:       e12fff1e        bx      lr

Signature · 2 lines

Pali Rohár
[email protected]

Michael Welling

2015-07-13 17:56 UTC #5 lore raw

Quoted 82 lines · Pali Rohár

Quoted 59 lines · On Monday 13 July 2015 19:03:44 Michael Welling wrote:
Quoted 26 lines · Sebastian Reichel
[+cc Michael Welling <[email protected]>, author of all omap-spi patches between 4.1 and 4.2-rc1]
Hi,
Quoted 20 lines · Tony Lindgren
Quoted 19 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Here are some relevant snippets form dmesg:
[   13.933959] Unhandled fault: external abort on non-linefetch
(0x1028) at 0xfa09802c [   13.940490] pgd = cfb38000
[   13.946594] [fa09802c] *pgd=48011452(bad)
[   13.952758] Internal error: : 1028 [#1] PREEMPT ARM
[   13.958862] Modules linked in: tsc2005(+) omap_sham
twl4030_wdt omap_wdt [   13.965332] CPU: 0 PID: 183 Comm:
modprobe Not tainted 4.2.0-rc1+ #363 [   13.971801] Hardware
name: Nokia RX-51 board
[   13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000
[   13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c
Here is the disassembly of the omap2_mcspi_set_cs function from my
compiler: 00000040 <omap2_mcspi_set_cs>:
      40:       e2803e25        add     r3, r0, #592    ; 0x250
      44:       e5902258        ldr     r2, [r0, #600]  ; 0x258
      48:       e1d330b2        ldrh    r3, [r3, #2]
      4c:       e3130004        tst     r3, #4
      50:       12211001        eorne   r1, r1, #1
      54:       e3520000        cmp     r2, #0
      58:       012fff1e        bxeq    lr
      5c:       e5923018        ldr     r3, [r2, #24]
      60:       e3510000        cmp     r1, #0
      64:       13c33601        bicne   r3, r3, #1048576        ;
0x100000 68:       03833601        orreq   r3, r3, #1048576        ;
0x100000 6c:       e5823018        str     r3, [r2, #24]
      70:       e5902258        ldr     r2, [r0, #600]  ; 0x258
      74:       e5922000        ldr     r2, [r2]
      78:       e582302c        str     r3, [r2, #44]   ; 0x2c
      7c:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      80:       e5933000        ldr     r3, [r3]
      84:       e593202c        ldr     r2, [r3, #44]   ; 0x2c
      88:       e12fff1e        bx      lr
The omap2_mcspi_set_cs function is being called before the controller_state is initialized in omap2_mcspi_setup.
That is why there is a conditional checking if controller_state is NULL.
Perhaps the controller_state is uninitialized but has garbage instead of NULL causing the data abort.
Quoted 7 lines
Though that does not make much sense because a similar check in the setup function did not cause a data abort in the past.
Not sure what is going wrong here.
Could you do a objdump with the compiler you are using?
Hello, here is my objdump of 4.2-rc2 version:
00000064 <omap2_mcspi_set_cs>:
      64:       e3003182        movw    r3, #386        ; 0x182
      68:       e19030b3        ldrh    r3, [r0, r3]
      6c:       e3130004        tst     r3, #4
      70:       0a000001        beq     7c <omap2_mcspi_set_cs+0x18>
      74:       e2711001        rsbs    r1, r1, #1
      78:       33a01000        movcc   r1, #0
      7c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      80:       e3520000        cmp     r2, #0
      84:       012fff1e        bxeq    lr
      88:       e5923018        ldr     r3, [r2, #24]
      8c:       e3510000        cmp     r1, #0

Quoted 8 lines

      90:       13c33601        bicne   r3, r3, #1048576        ; 0x100000
      94:       03833601        orreq   r3, r3, #1048576        ; 0x100000
      98:       e5823018        str     r3, [r2, #24]
      9c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      a0:       e5922000        ldr     r2, [r2]
      a4:       e582302c        str     r3, [r2, #44]   ; 0x2c
      a8:       e592302c        ldr     r3, [r2, #44]   ; 0x2c
      ac:       e12fff1e        bx      lr

0x64+0x44 = 0xa8

That means that it got past the check for controller_state being NULL. So that means that controller_state is not NULL and not initialized properly causing the data abort.

It still does not explain how the driver used to work given it initializes the controller_state in the setup function after doing the same check.

Let me dig a little more. Wish I had a N900 to try this on.

Quoted 4 lines

Signature · 3 lines
-- 
Pali Rohár
[email protected]

Michael Welling

2015-07-13 20:28 UTC #6 lore raw

Quoted 14 lines · Pali Rohár

Hello, here is my objdump of 4.2-rc2 version:

00000064 <omap2_mcspi_set_cs>:

      64:       e3003182        movw    r3, #386        ; 0x182
      68:       e19030b3        ldrh    r3, [r0, r3]
      6c:       e3130004        tst     r3, #4
      70:       0a000001        beq     7c <omap2_mcspi_set_cs+0x18>
      74:       e2711001        rsbs    r1, r1, #1
      78:       33a01000        movcc   r1, #0
      7c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      80:       e3520000        cmp     r2, #0
      84:       012fff1e        bxeq    lr
      88:       e5923018        ldr     r3, [r2, #24]
      8c:       e3510000        cmp     r1, #0

Quoted 8 lines

      90:       13c33601        bicne   r3, r3, #1048576        ; 0x100000
      94:       03833601        orreq   r3, r3, #1048576        ; 0x100000
      98:       e5823018        str     r3, [r2, #24]
      9c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      a0:       e5922000        ldr     r2, [r2]
      a4:       e582302c        str     r3, [r2, #44]   ; 0x2c
      a8:       e592302c        ldr     r3, [r2, #44]   ; 0x2c
      ac:       e12fff1e        bx      lr

I have not been able to duplicate the failure on the hardware that I have. I dug out my old Beagleboard and added an SPI registration to the dts. This was the closest hardware that I had to the N900's processor.

What is the version of the gcc compiler you are using and where did you get it from?

For instance, I am using a 4.9.1 compiler that I built using Yocto.

Also are you using devicetree or the old board file board-rx51.c?

Pali Rohár

author

2015-07-13 20:34 UTC #7 lore raw

Quoted 26 lines · On Monday 13 July 2015 22:28:35 Michael Welling wrote:

Quoted 16 lines · Pali Rohár

Hello, here is my objdump of 4.2-rc2 version:

00000064 <omap2_mcspi_set_cs>:

      64:       e3003182        movw    r3, #386        ; 0x182
      68:       e19030b3        ldrh    r3, [r0, r3]
      6c:       e3130004        tst     r3, #4
      70:       0a000001        beq     7c
      <omap2_mcspi_set_cs+0x18> 74:       e2711001        rsbs   
      r1, r1, #1
      78:       33a01000        movcc   r1, #0
      7c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      80:       e3520000        cmp     r2, #0
      84:       012fff1e        bxeq    lr
      88:       e5923018        ldr     r3, [r2, #24]
      8c:       e3510000        cmp     r1, #0
      90:       13c33601        bicne   r3, r3, #1048576        ;

Quoted 8 lines

      0x100000 94:       03833601        orreq   r3, r3, #1048576 
            ; 0x100000 98:       e5823018        str     r3, [r2,
      #24]
      9c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      a0:       e5922000        ldr     r2, [r2]
      a4:       e582302c        str     r3, [r2, #44]   ; 0x2c
      a8:       e592302c        ldr     r3, [r2, #44]   ; 0x2c
      ac:       e12fff1e        bx      lr

Quoted 8 lines

I have not been able to duplicate the failure on the hardware that I have. I dug out my old Beagleboard and added an SPI registration to the dts. This was the closest hardware that I had to the N900's processor.
What is the version of the gcc compiler you are using and where did you get it from?

I'm using gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) from package gcc-4.6-arm-linux-gnueabi which is available on Ubuntu 12.04 LTS (version 4.6.3-1ubuntu5cross1.62).

Quoted 3 lines

For instance, I am using a 4.9.1 compiler that I built using Yocto.
Also are you using devicetree or the old board file board-rx51.c?

I'm using devicetree.

Signature · 2 lines

Pali Rohár
[email protected]

Michael Welling

2015-07-13 21:52 UTC #8 lore raw

Quoted 32 lines · Pali Rohár

Quoted 31 lines · On Monday 13 July 2015 22:28:35 Michael Welling wrote:

Quoted 16 lines · Pali Rohár

Hello, here is my objdump of 4.2-rc2 version:

00000064 <omap2_mcspi_set_cs>:

      64:       e3003182        movw    r3, #386        ; 0x182
      68:       e19030b3        ldrh    r3, [r0, r3]
      6c:       e3130004        tst     r3, #4
      70:       0a000001        beq     7c
      <omap2_mcspi_set_cs+0x18> 74:       e2711001        rsbs   
      r1, r1, #1
      78:       33a01000        movcc   r1, #0
      7c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      80:       e3520000        cmp     r2, #0
      84:       012fff1e        bxeq    lr
      88:       e5923018        ldr     r3, [r2, #24]
      8c:       e3510000        cmp     r1, #0
      90:       13c33601        bicne   r3, r3, #1048576        ;

Quoted 8 lines

      0x100000 94:       03833601        orreq   r3, r3, #1048576 
            ; 0x100000 98:       e5823018        str     r3, [r2,
      #24]
      9c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      a0:       e5922000        ldr     r2, [r2]
      a4:       e582302c        str     r3, [r2, #44]   ; 0x2c
      a8:       e592302c        ldr     r3, [r2, #44]   ; 0x2c
      ac:       e12fff1e        bx      lr

Quoted 7 lines

Quoted 3 lines
What is the version of the gcc compiler you are using and where did you get it from?
I'm using gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) from package gcc-4.6-arm-linux-gnueabi which is available on Ubuntu 12.04 LTS (version 4.6.3-1ubuntu5cross1.62).

I downloaded and compiled with this compiler and it still does not effect the functionality of the targets that I have.

What flags (if any) are you passing to the compiler?

Here is my objdump with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5):
00000074 <omap2_mcspi_set_cs>:

      74:       e59f304c        ldr     r3, [pc, #76]   ; c8 <omap2_mcspi_set_cs+0x54>
      78:       e19030b3        ldrh    r3, [r0, r3]
      7c:       e3130004        tst     r3, #4
      80:       0a000001        beq     8c <omap2_mcspi_set_cs+0x18>
      84:       e2711001        rsbs    r1, r1, #1
      88:       33a01000        movcc   r1, #0
      8c:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      90:       e3530000        cmp     r3, #0
      94:       012fff1e        bxeq    lr
      98:       e5932018        ldr     r2, [r3, #24]
      9c:       e3510000        cmp     r1, #0
      a0:       13c22601        bicne   r2, r2, #1048576        ; 0x100000
      a4:       03822601        orreq   r2, r2, #1048576        ; 0x100000
      a8:       e5832018        str     r2, [r3, #24]
      ac:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      b0:       e5933000        ldr     r3, [r3]
      b4:       e583202c        str     r2, [r3, #44]   ; 0x2c
      b8:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      bc:       e5933000        ldr     r3, [r3]
      c0:       e593202c        ldr     r2, [r3, #44]   ; 0x2c
      c4:       e12fff1e        bx      lr
      c8:       00000252        .word   0x00000252

Quoted 10 lines

Quoted 4 lines
For instance, I am using a 4.9.1 compiler that I built using Yocto.
Also are you using devicetree or the old board file board-rx51.c?
I'm using devicetree.
Signature · 2 lines
Pali Rohár
[email protected]

Pali Rohár

author

2015-07-13 22:02 UTC #9 lore raw

Quoted 40 lines · On Monday 13 July 2015 23:52:32 Michael Welling wrote:

Quoted 39 lines · Pali Rohár
Quoted 37 lines · On Monday 13 July 2015 22:28:35 Michael Welling wrote:
Quoted 20 lines · Pali Rohár
Hello, here is my objdump of 4.2-rc2 version:
00000064 <omap2_mcspi_set_cs>:
      64:       e3003182        movw    r3, #386        ; 0x182
      68:       e19030b3        ldrh    r3, [r0, r3]
      6c:       e3130004        tst     r3, #4
      70:       0a000001        beq     7c
      <omap2_mcspi_set_cs+0x18> 74:       e2711001        rsbs
      r1, r1, #1
      78:       33a01000        movcc   r1, #0
      7c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      80:       e3520000        cmp     r2, #0
      84:       012fff1e        bxeq    lr
      88:       e5923018        ldr     r3, [r2, #24]
      8c:       e3510000        cmp     r1, #0
      90:       13c33601        bicne   r3, r3, #1048576       
      ; 0x100000 94:       03833601        orreq   r3, r3,
      #1048576
      
            ; 0x100000 98:       e5823018        str     r3,
Quoted 8 lines
            [r2,
      
      #24]
      9c:       e5902188        ldr     r2, [r0, #392]  ; 0x188
      a0:       e5922000        ldr     r2, [r2]
      a4:       e582302c        str     r3, [r2, #44]   ; 0x2c
      a8:       e592302c        ldr     r3, [r2, #44]   ; 0x2c
      ac:       e12fff1e        bx      lr
I have not been able to duplicate the failure on the hardware that I have. I dug out my old Beagleboard and added an SPI registration to the dts. This was the closest hardware that I had to the N900's processor.
What is the version of the gcc compiler you are using and where did you get it from?

Quoted 9 lines

Quoted 3 lines
I'm using gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) from package gcc-4.6-arm-linux-gnueabi which is available on Ubuntu 12.04 LTS (version 4.6.3-1ubuntu5cross1.62).
I downloaded and compiled with this compiler and it still does not effect the functionality of the targets that I have.
What flags (if any) are you passing to the compiler?

I think nothing special. I just call:

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage

Quoted 32 lines

Here is my objdump with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5): 00000074 <omap2_mcspi_set_cs>:

      74:       e59f304c        ldr     r3, [pc, #76]   ; c8
<omap2_mcspi_set_cs+0x54> 78:       e19030b3        ldrh    r3, [r0,
r3]
      7c:       e3130004        tst     r3, #4
      80:       0a000001        beq     8c <omap2_mcspi_set_cs+0x18>
      84:       e2711001        rsbs    r1, r1, #1
      88:       33a01000        movcc   r1, #0
      8c:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      90:       e3530000        cmp     r3, #0
      94:       012fff1e        bxeq    lr
      98:       e5932018        ldr     r2, [r3, #24]
      9c:       e3510000        cmp     r1, #0
      a0:       13c22601        bicne   r2, r2, #1048576        ;
0x100000 a4:       03822601        orreq   r2, r2, #1048576        ;
0x100000 a8:       e5832018        str     r2, [r3, #24]
      ac:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      b0:       e5933000        ldr     r3, [r3]
      b4:       e583202c        str     r2, [r3, #44]   ; 0x2c
      b8:       e5903258        ldr     r3, [r0, #600]  ; 0x258
      bc:       e5933000        ldr     r3, [r3]
      c0:       e593202c        ldr     r2, [r3, #44]   ; 0x2c
      c4:       e12fff1e        bx      lr
      c8:       00000252        .word   0x00000252

Quoted 6 lines

Quoted 4 lines
For instance, I am using a 4.9.1 compiler that I built using Yocto.
Also are you using devicetree or the old board file board-rx51.c?
I'm using devicetree.

Signature · 2 lines

Pali Rohár
[email protected]

Michael Welling

2015-07-13 22:36 UTC #10 lore raw

Quoted 10 lines · Pali Rohár

I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage

Where are you getting rx51_defconfig from?

This does not appear to be in the kernel source any longer.

Can you try the above with omap2plus_defconfig?

Krzysztof Kozlowski

2015-07-14 00:18 UTC #42 lore raw

Quoted 67 lines · Sebastian Reichel

Hi,

Quoted 7 lines · Pali Rohár

now I'm testing 4.2-rc2 release and rtc is working:

[   27.426055] omap_i2c 48072000.i2c: controller timed out
[   28.723358] twl_rtc 48070000.i2c:twl@48:rtc: Power up reset detected.
[   30.127014] twl_rtc 48070000.i2c:twl@48:rtc: Enabling TWL-RTC
[   31.373626] twl_rtc 48070000.i2c:twl@48:rtc: rtc core: registered 48070000.i2c:twl@48 as rtc0

Quoted 5 lines

There is still some i2c time out line and some reset detected, but driver loads fine.
But problem with touchscreen tsc2005 and wifi wl1251 is still there :-( Drivers are compiled as external .ko modules.

Right, my kernel was with everything built-in.

Quoted 1 line

Plus I see new problem with bq2415_charger :-(

Mh did you see them in 4.1?

Quoted 10 lines

[   54.214965] isp1704_charger isp1704: registered with product id isp1707
[   54.828674] bq2415x-charger 2-006b: automode enabled
[   55.192596] ------------[ cut here ]------------
[   55.200561] WARNING: CPU: 0 PID: 528 at kernel/workqueue.c:1443 __queue_delayed_work+0x50/0x144()
...
[   55.489501] WARNING: CPU: 0 PID: 528 at kernel/workqueue.c:1445 __queue_delayed_work+0xb4/0x144()
...
[   55.820953] WARNING: CPU: 0 PID: 528 at kernel/workqueue.c:1376 __queue_work+0x2c0/0x404()
...
[   56.243347] bq2415x-charger 2-006b: driver registered

So the driver tries to send a notification before it's fully registered. The warnings are probably a side-effect of the power-supply API changes in 4.1.

Quoted 21 lines

[   77.142181] INFO: rcu_preempt detected stalls on CPUs/tasks: { P528} (detected by 0, t=2102 jiffies, g=1101, c=1100, q=3834)
[   77.163391] kworker/0:3     R running      0   528      2 0x00000000
[   77.173706] Workqueue: events power_supply_changed_work
[   77.183898] [<c042883c>] (__schedule) from [<c0428c94>] (preempt_schedule_irq+0x54/0x84)
[   77.194274] [<c0428c94>] (preempt_schedule_irq) from [<c042c23c>] (svc_preempt+0x8/0x18)
[   77.204711] [<c042c23c>] (svc_preempt) from [<c0047ce4>] (queue_delayed_work_on+0x40/0x44)
[   77.215179] [<c0047ce4>] (queue_delayed_work_on) from [<bf0a59e4>] (bq2415x_notifier_call+0x90/0x9c [bq2415x_charger])
[   77.235870] [<bf0a59e4>] (bq2415x_notifier_call [bq2415x_charger]) from [<c004de34>] (notifier_call_chain+0x38/0x68)
[   77.257019] [<c004de34>] (notifier_call_chain) from [<c004dff4>] (__atomic_notifier_call_chain+0x34/0x44)
[   77.278411] [<c004dff4>] (__atomic_notifier_call_chain) from [<c004e018>] (atomic_notifier_call_chain+0x14/0x18)
[   77.299804] [<c004e018>] (atomic_notifier_call_chain) from [<c0305a9c>] (power_supply_changed_work+0xac/0x130)
[   77.321197] [<c0305a9c>] (power_supply_changed_work) from [<c00484d8>] (process_one_work+0x278/0x45c)
[   77.342529] [<c00484d8>] (process_one_work) from [<c0048918>] (worker_thread+0x230/0x354)
[   77.353393] [<c0048918>] (worker_thread) from [<c004d0e0>] (kthread+0xcc/0xe0)
[   77.364074] [<c004d0e0>] (kthread) from [<c000eb08>] (ret_from_fork+0x14/0x2c)
[   77.374572] kworker/0:3     R running      0   528      2 0x00000000
[   77.384948] Workqueue: events power_supply_changed_work
[   77.395111] [<c042883c>] (__schedule) from [<c0428c94>] (preempt_schedule_irq+0x54/0x84)
[   77.405456] [<c0428c94>] (preempt_schedule_irq) from [<c042c23c>] (svc_preempt+0x8/0x18)
[   77.415863] [<c042c23c>] (svc_preempt) from [<c0047ce4>] (queue_delayed_work_on+0x40/0x44)
[   77.426269] [<c0047ce4>] (queue_delayed_work_on) from [<bf0a59e4>] (bq2415x_notifier_call+0x90/0x9c [bq2415x_charger])

Quoted 8 lines

[   77.447174] [<bf0a59e4>] (bq2415x_notifier_call [bq2415x_charger]) from [<c004de34>] (notifier_call_chain+0x38/0x68)
[   77.468322] [<c004de34>] (notifier_call_chain) from [<c004dff4>] (__atomic_notifier_call_chain+0x34/0x44)
[   77.489990] [<c004dff4>] (__atomic_notifier_call_chain) from [<c004e018>] (atomic_notifier_call_chain+0x14/0x18)
[   77.512115] [<c004e018>] (atomic_notifier_call_chain) from [<c0305a9c>] (power_supply_changed_work+0xac/0x130)
[   77.534637] [<c0305a9c>] (power_supply_changed_work) from [<c00484d8>] (process_one_work+0x278/0x45c)
[   77.557189] [<c00484d8>] (process_one_work) from [<c0048918>] (worker_thread+0x230/0x354)
[   77.568634] [<c0048918>] (worker_thread) from [<c004d0e0>] (kthread+0xcc/0xe0)
[   77.579925] [<c004d0e0>] (kthread) from [<c000eb08>] (ret_from_fork+0x14/0x2c)

Quoted 1 line

Not sure about these.

I've got an idea however I cannot test it (I don't have the hardware). I'll sent it with RFT.

Best regards,
Krzysztof

Pali Rohár

author

2015-07-14 07:14 UTC #11 lore raw

https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig

Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:

Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage

Quoted 6 lines

Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?

It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched

Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.

Signature · 2 lines

Pali Rohár
[email protected]

Tony Lindgren

2015-07-14 07:45 UTC #12 lore raw

Quoted 20 lines · Pali Rohár

Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:
Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Quoted 6 lines
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?

Quoted 7 lines

It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.

After doing git bisect on it, looks like the breaking commit is ddcad7e9068e ("spi: omap2-mcspi: Fix native cs with new set_cs").

That alone does not seem to revert, have not debugged further.

Regards,

Tony

Michael Welling

2015-07-14 16:33 UTC #13 lore raw

Quoted 20 lines · Pali Rohár

Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:
Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Quoted 6 lines
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?

Quoted 7 lines

It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.

True.

Could you try the following change to the set_cs function and see if it helps.

drivers/spi/spi-omap2-mcspi.c +9 -7

index 5867384..666038b 100644
@@ -245,16 +245,18 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+	struct omap2_mcspi_cs *cs = spi->controller_state;
 	u32 l;
 
-	/* The controller handles the inverted chip selects
-	 * using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
-	 * the inversion from the core spi_set_cs function.
-	 */
-	if (spi->mode & SPI_CS_HIGH)
-		enable = !enable;
+	if (cs) {
+
+		/* The controller handles the inverted chip selects
+		 * using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
+		 * the inversion from the core spi_set_cs function.
+		 */
+		if (spi->mode & SPI_CS_HIGH)
+			enable = !enable;
 
-	if (spi->controller_state) {
 		l = mcspi_cached_chconf0(spi);
 
 		if (enable)

Pavel Machek

2015-07-14 20:01 UTC #14 lore raw

Quoted 26 lines · Michael Welling

Quoted 25 lines · Pali Rohár
Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:
Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Quoted 6 lines
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?
It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig

Quoted 7 lines

Quoted 2 lines
Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.
True.
Could you try the following change to the set_cs function and see if it helps.

Ok, so:

4.2-rc1 worked for me, IIRC.

4.2-rc2 oopses a lot.

4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops.

Pavel

Quoted 19 lines

drivers/spi/spi-omap2-mcspi.c +3 -6

index 5867384..666038b 100644
@@ -245,16 +245,18 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+	struct omap2_mcspi_cs *cs = spi->controller_state;
 	u32 l;
 
-	/* The controller handles the inverted chip selects
-	 * using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
-	 * the inversion from the core spi_set_cs function.
-	 */
-	if (spi->mode & SPI_CS_HIGH)
-		enable = !enable;
+	if (cs) {
+

Signature · 2 lines

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

Michael Welling

2015-07-14 20:17 UTC #15 lore raw

Quoted 30 lines · Pavel Machek

Quoted 29 lines · Michael Welling
Quoted 27 lines · Pali Rohár
Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:
Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Quoted 6 lines
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?
It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.

Quoted 8 lines

Quoted 4 lines
True.
Could you try the following change to the set_cs function and see if it helps.
Ok, so:
4.2-rc1 worked for me, IIRC.

This does not make sense.

Nothing has changed in drivers/spi between these versions.

Are you sure that 4.2-rc1 worked for you?

Quoted 30 lines

4.2-rc2 oopses a lot.

4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops.

Pavel

Quoted 19 lines

drivers/spi/spi-omap2-mcspi.c +3 -6

index 5867384..666038b 100644
@@ -245,16 +245,18 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+	struct omap2_mcspi_cs *cs = spi->controller_state;
 	u32 l;
 
-	/* The controller handles the inverted chip selects
-	 * using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
-	 * the inversion from the core spi_set_cs function.
-	 */
-	if (spi->mode & SPI_CS_HIGH)
-		enable = !enable;
+	if (cs) {
+

Signature · 2 lines

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

Pavel Machek

2015-07-15 19:49 UTC #16 lore raw

Hi!

Quoted 8 lines

Quoted 3 lines
Ok, so:
4.2-rc1 worked for me, IIRC.
This does not make sense.
Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you?

Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place.

Quoted 4 lines

Quoted 4 lines
4.2-rc2 oopses a lot.
4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops.

But... I'm not sure I'm getting the same oops.
Pavel

Signature · 2 lines

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

Michael Welling

2015-07-15 20:10 UTC #17 lore raw

Quoted 6 lines · Pavel Machek

Hi!
Quoted 4 lines
Quoted 3 lines
Ok, so:
4.2-rc1 worked for me, IIRC.

Quoted 9 lines

Quoted 4 lines
This does not make sense.
Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you?
Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place.

Interesting. Something very strange is happening here. Send me the links if you push your tree/config to a public repo.

I would not hurt to have the same from Pali for comparison.

Quoted 6 lines

Quoted 4 lines
Quoted 4 lines
4.2-rc2 oopses a lot.
4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops.
But... I'm not sure I'm getting the same oops.

If the system is still booting, you could tell if the oopses were the same if your touchscreen and wifi do no work.

Quoted 4 lines

Pavel

Signature · 2 lines

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

Michael Welling

2015-07-20 20:46 UTC #22 lore raw

Quoted 20 lines · Pali Rohár

Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:
Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Quoted 6 lines
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?

Quoted 7 lines

It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.

Has any progress been made on this?

Seeing as I was dropped into the middle of this thread, I took a look at the discussion previous.

It appears that you are building the drivers as modules. Perhaps I can again attempt to duplicate the issue using modules. Though this should not make a difference.

Quoted 4 lines

Signature · 3 lines
-- 
Pali Rohár
[email protected]

Michael Welling

2015-07-20 20:48 UTC #21 lore raw

In reply to Pavel Machek

Quoted 15 lines · Pavel Machek

Hi!
Quoted 8 lines
Quoted 3 lines
Ok, so:
4.2-rc1 worked for me, IIRC.
This does not make sense.
Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you?
Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place.

Quoted 7 lines

Quoted 4 lines
Quoted 4 lines
4.2-rc2 oopses a lot.
4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops.
But... I'm not sure I'm getting the same oops.
Pavel

Any progress as to what is causing the oops for you starting at 4.2-rc2?

Quoted 3 lines

Signature · 2 lines

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

Pali Rohár

author

2015-07-20 20:58 UTC #23 lore raw

Quoted 24 lines · On Monday 20 July 2015 22:46:47 Michael Welling wrote:

Quoted 23 lines · Pali Rohár
Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:
Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Quoted 5 lines
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?
It is in my linux-n900 repository:
https://github.com/pali/linux-n900 Repository contains more n900 specific patches but SPI code is unpatched

Quoted 9 lines

Quoted 6 lines
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_
defconfig
Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.
Has any progress been made on this?

Hi, sorry but I did not have time last weekend for testing...

Quoted 6 lines

Seeing as I was dropped into the middle of this thread, I took a look at the discussion previous.
It appears that you are building the drivers as modules. Perhaps I can again attempt to duplicate the issue using modules. Though this should not make a difference.

Yes, you can try to build drivers as modules. Also you can try to use my rx51_defconfig. Maybe you find something more...

Signature · 2 lines

Pali Rohár
[email protected]

Pavel Machek

2015-07-21 07:31 UTC #18 lore raw

https://gitlab.com/tui/tui/tree/master/ofone

Quoted 12 lines · Michael Welling

Quoted 11 lines · Pavel Machek
Hi!
Quoted 8 lines
Quoted 3 lines
Ok, so:
4.2-rc1 worked for me, IIRC.
This does not make sense.
Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you?

Quoted 7 lines

Quoted 4 lines
Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place.
Interesting. Something very strange is happening here. Send me the links if you push your tree/config to a public repo.

Pushing now. It is on kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 mini-v4.2

f1376b91c1c765cf041235c14ac44c04d56fd2a9 is broken

cb8b6850aa49f72f226629796e349dd75d3f4f78 mostly works. (My notes say that GSM is broken, but they may be not enough patches applied.) I believe I even run the "tefone" testsuite, with only s2ram acting funny.

Quoted 11 lines

I would not hurt to have the same from Pali for comparison.
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
4.2-rc2 oopses a lot.
4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops.
But... I'm not sure I'm getting the same oops.
If the system is still booting, you could tell if the oopses were the same if your touchscreen and wifi do no work.

I'm pretty sure they worked. I'd notice broken touchscreen.

(Sorry, I'm a bit busy at the moment).

Best regards,
Pavel

Signature · 2 lines

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

Pavel Machek

2015-07-21 07:33 UTC #19 lore raw

Quoted 18 lines · Pavel Machek

Quoted 17 lines · Michael Welling
Quoted 15 lines · Pavel Machek
Hi!
Quoted 8 lines
Quoted 3 lines
Ok, so:
4.2-rc1 worked for me, IIRC.
This does not make sense.
Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you?
Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place.

Quoted 5 lines

Quoted 2 lines
Interesting. Something very strange is happening here. Send me the links if you push your tree/config to a public repo.
Pushing now. It is on kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 mini-v4.2

Actually, pali, if you have time. I pushed

kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 n900-v4.2

too, that one should work. (Modulo gsm and s2ram). If you could confirm that, that would be great.

Best regards,
Pavel

Signature · 2 lines

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

Pali Rohár

author

2015-07-21 08:04 UTC #20 lore raw

Quoted 27 lines · On Tuesday 21 July 2015 09:33:00 Pavel Machek wrote:

Quoted 18 lines · Pavel Machek
Quoted 17 lines · Michael Welling
Quoted 15 lines · Pavel Machek
Hi!
Quoted 8 lines
Quoted 3 lines
Ok, so:
4.2-rc1 worked for me, IIRC.
This does not make sense.
Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you?
Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place.
Quoted 5 lines
Quoted 2 lines
Interesting. Something very strange is happening here. Send me the links if you push your tree/config to a public repo.
Pushing now. It is on kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 mini-v4.2
Actually, pali, if you have time. I pushed

Quoted 8 lines

kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 n900-v4.2
too, that one should work. (Modulo gsm and s2ram). If you could confirm that, that would be great.
Best regards,
Pavel

Ok, I will try it at the weekend... Anyway, can you rebase patches on top of some linus tree? Because via that git.kernel.org web it is impossible to list commits or read diff/patches which you applied.

Signature · 2 lines

Pali Rohár
[email protected]

Pavel Machek

2015-07-21 09:34 UTC #24 lore raw

Quoted 29 lines · Michael Welling

Quoted 20 lines · Pali Rohár
Quoted 12 lines · On Monday 13 July 2015 17:36:07 Michael Welling wrote:
Quoted 10 lines · Pali Rohár
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Quoted 6 lines
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?
Quoted 7 lines
It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration.

Quoted 8 lines

Has any progress been made on this?
Seeing as I was dropped into the middle of this thread, I took a look at the discussion previous.
It appears that you are building the drivers as modules. Perhaps I can again attempt to duplicate the issue using modules. Though this should not make a difference.

Actually.. for the record I'm _not_ using modules. So either I hit something different, or problem happens regardless of modules.
Pavel

Signature · 2 lines

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

Michael Welling

2015-07-21 21:28 UTC #25 lore raw

Quoted 3 lines · Pavel Machek

Actually.. for the record I'm _not_ using modules. So either I hit something different, or problem happens regardless of modules.
Pavel

I was able to reproduce the error by using my Beagleboard.

I added a registration for the tsc2005 and built the driver as a module.

[    4.318878] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09802c
[    4.326934] pgd = cf114000
[    4.329742] [fa09802c] *pgd=48011452(bad)
[    4.333953] Internal error: : 1028 [#1] PREEMPT ARM
[    4.339050] Modules linked in: tsc2005(+) twl4030_wdt(+) rtc_twl(+) omap_ssi hsi
[    4.346832] CPU: 0 PID: 74 Comm: udevd Not tainted 4.2.0-rc3+ #2
[    4.353118] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
[    4.359680] task: cf0a8f00 ti: cf112000 task.ti: cf112000
[    4.365356] PC is at omap2_mcspi_set_cs+0x3c/0x44
[    4.370269] LR is at spi_setup+0xd4/0x10c
[    4.374450] pc : [<c0328b5c>]    lr : [<c0326a6c>]    psr: 200f0113
[    4.374450] sp : cf113d48  ip : 00000001  fp : 00000fff
[    4.386474] r10: cf31ffe4  r9 : 00000000  r8 : 00000008
[    4.391937] r7 : 00000fff  r6 : 00000000  r5 : 00000000  r4 : cfbdbe00
[    4.398773] r3 : 200103dc  r2 : fa098000  r1 : 00000001  r0 : cfbdbe00
[    4.405578] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[    4.413055] Control: 10c5387d  Table: 8f114019  DAC: 00000015
[    4.419067] Process udevd (pid: 74, stack limit = 0xcf112210)
[    4.425079] Stack: (0xcf113d48 to 0xcf114000)
[    4.429626] 3d40:                   cfbdbe00 cfbdbe00 cfce7ab8 bf017ac8 cfbdd5a0 c015dc08
[    4.438201] 3d60: cf352190 00000000 00000fff 00000004 00000008 00000002 00000118 00001f40
[    4.446746] 3d80: 00000001 bf0183cc cfbdbe00 00000000 bf0183dc 00000008 00000001 cf31ffe4
[    4.455322] 3da0: cf31ffc8 c0326458 c0326408 cfbdbe00 c073e81c c02e7ca0 cfbdbe00 cfbdbe34
[    4.463867] 3dc0: bf0183dc c06e8254 c06aefe0 c02e7e6c 00000000 bf0183dc c02e7e04 c02e6530
[    4.472442] 3de0: cf964c4c cfbd89b0 bf0183dc 00000000 cf322200 c02e74e8 bf01830f bf018310
[    4.480987] 3e00: 00000000 bf0183dc bf01a000 00000000 c06aefe0 c02e8904 00000000 cf353080
[    4.489562] 3e20: bf01a000 c0009640 cf978000 00000001 00000000 00000000 00000001 00000000
[    4.498107] 3e40: cf07c008 00150013 cf07c000 600f0113 c06db824 c06db824 cfedf9c0 0040003f
[    4.506683] 3e60: cfedf9c0 00150013 cfcf9000 00080000 cf801f00 000000d0 bf018440 bf018440
[    4.515228] 3e80: 00000001 cf353040 bf018488 cf31ffc0 00000001 c046c4b8 bf018440 c06ffb90
[    4.523803] 3ea0: cf113f58 00000001 bf018440 c00875b0 bf01844c 00007fff 00000000 c0084f8c
[    4.532348] 3ec0: c0084b28 bf018614 bf018640 00000000 00026d29 d09c503c b6f0aec0 c0084c60
[    4.540924] 3ee0: d09a8000 00026d29 000003e9 00000000 0b300002 00000000 00000000 00000000
[    4.549468] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.558044] 3f20: 00000000 00000000 00000000 00000000 00000138 00000000 b6f0aec0 00000005
[    4.566589] 3f40: 0000017b c000ebc4 cf112000 00000000 bef58e70 c0087bec d09a8000 00026d29
[    4.575134] 3f60: d09c4934 d09c4764 d09ce71c 00001640 000019e0 00000000 00000000 00000000
[    4.583709] 3f80: 0000002d 0000002e 00000017 00000014 00000012 00000000 00000000 0004a898
[    4.592254] 3fa0: 00000000 c000ea40 00000000 0004a898 00000005 b6f0aec0 00000000 00020000
[    4.600830] 3fc0: 00000000 0004a898 00000000 0000017b 00000000 0004a898 0004aa30 bef58e70
[    4.609374] 3fe0: bef58d98 bef58d88 b6f0399c b6e93ed0 60070010 00000005 00000000 00000000
[    4.617950] [<c0328b5c>] (omap2_mcspi_set_cs) from [<c0326a6c>] (spi_setup+0xd4/0x10c)
[    4.626281] [<c0326a6c>] (spi_setup) from [<bf017ac8>] (tsc2005_probe+0x108/0x5d4 [tsc2005])
[    4.635131] [<bf017ac8>] (tsc2005_probe [tsc2005]) from [<c0326458>] (spi_drv_probe+0x50/0x6c)
[    4.644165] [<c0326458>] (spi_drv_probe) from [<c02e7ca0>] (driver_probe_device+0xf4/0x258)
[    4.652893] [<c02e7ca0>] (driver_probe_device) from [<c02e7e6c>] (__driver_attach+0x68/0x8c)
[    4.661743] [<c02e7e6c>] (__driver_attach) from [<c02e6530>] (bus_for_each_dev+0x6c/0x90)
[    4.670318] [<c02e6530>] (bus_for_each_dev) from [<c02e74e8>] (bus_add_driver+0xcc/0x1e4)
[    4.678863] [<c02e74e8>] (bus_add_driver) from [<c02e8904>] (driver_register+0x9c/0xe0)
[    4.687255] [<c02e8904>] (driver_register) from [<c0009640>] (do_one_initcall+0x100/0x1b0)
[    4.695922] [<c0009640>] (do_one_initcall) from [<c046c4b8>] (do_init_module+0x58/0x1c0)
[    4.704406] [<c046c4b8>] (do_init_module) from [<c00875b0>] (load_module+0x16ac/0x1b64)
[    4.712799] [<c00875b0>] (load_module) from [<c0087bec>] (SyS_finit_module+0x60/0x68)
[    4.721008] [<c0087bec>] (SyS_finit_module) from [<c000ea40>] (ret_fast_syscall+0x0/0x3c)
[    4.729553] Code: e5823018 e5902188 e5922000 e582302c (e592302c) 
[    4.735961] ---[ end trace 375298308353557f ]---

Now to figure out why this is happening.

Quoted 3 lines

Signature · 2 lines

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

Michael Welling

2015-07-22 00:17 UTC #26 lore raw

In reply to Pavel Machek

On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:

This code has my head spinning.

I found that the errors do not occur when the driver is built into the kernel.

I also found that with the patch below the errors go away.

Not sure if it is acceptible but see if it fixes things on your side.

drivers/spi/spi.c +2 -2

index cf8b91b..3164d13 100644
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
 	if (!spi->max_speed_hz)
 		spi->max_speed_hz = spi->master->max_speed_hz;
 
-	spi_set_cs(spi, false);
-
 	if (spi->master->setup)
 		status = spi->master->setup(spi);
 
+	spi_set_cs(spi, false);
+
 	dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n",
 			(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
 			(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",

Sebastian Reichel

2015-07-22 02:03 UTC #27 lore raw

Hi,

Quoted 19 lines · Michael Welling

On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into the kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your side.
drivers/spi/spi.c +0 -0
index cf8b91b..3164d13 100644
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
 	if (!spi->max_speed_hz)
 		spi->max_speed_hz = spi->master->max_speed_hz;
 

drivers/spi/spi.c int spi_setup(struct spi_device *spi) · line 1811

Quoted 10 lines

drivers/spi/spi.c +2 -2

-	spi_set_cs(spi, false);
-
 	if (spi->master->setup)
 		status = spi->master->setup(spi);
 
+	spi_set_cs(spi, false);
+
 	dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n",
 			(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
 			(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",

mh. maybe a runtime PM issue?

* external abort on non-linefetch: address cannot be accessed, since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit faster (module must not be loaded from filesystem), so that the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to suspend after the runtime PM acquisition in setup()

So I suggest trying the following (compile tested only) patch:

-- Sebastian

drivers/spi/spi-omap2-mcspi.c +6 -0

index 5867384..f7d9ffd 100644
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+       struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
        u32 l;
 
        /* The controller handles the inverted chip selects

@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                enable = !enable;
 
        if (spi->controller_state) {
+               pm_runtime_get_sync(mcspi->dev);
+
                l = mcspi_cached_chconf0(spi);
 
                if (enable)

@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                        l |= OMAP2_MCSPI_CHCONF_FORCE;
 
                mcspi_write_chconf0(spi, l);
+
+               pm_runtime_mark_last_busy(mcspi->dev);
+               pm_runtime_put_autosuspend(mcspi->dev);
        }
 }

Michael Welling

2015-07-22 05:13 UTC #28 lore raw

Quoted 27 lines · Sebastian Reichel

Hi,
Quoted 24 lines · Michael Welling
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into the kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your side.
drivers/spi/spi.c +0 -2
index cf8b91b..3164d13 100644
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
 	if (!spi->max_speed_hz)
 		spi->max_speed_hz = spi->master->max_speed_hz;
 
-	spi_set_cs(spi, false);
-
 	if (spi->master->setup)
 		status = spi->master->setup(spi);
 

Quoted 7 lines

drivers/spi/spi.c int spi_setup(struct spi_device *spi) · line 1811
Quoted 5 lines
drivers/spi/spi.c +2 -0
+	spi_set_cs(spi, false);
+
 	dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n",
 			(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
 			(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
mh. maybe a runtime PM issue?

mh?

Quoted 13 lines

* external abort on non-linefetch: address cannot be accessed, since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit faster (module must not be loaded from filesystem), so that the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to suspend after the runtime PM acquisition in setup()

Quoted 2 lines

So I suggest trying the following (compile tested only) patch:

It seems you are right.

With this patch the SPI drivers no longer cause data aborts.

I will wait for feedback from Pavel and Pali but it looks like we have a winner.

Quoted 15 lines

-- Sebastian

drivers/spi/spi-omap2-mcspi.c +1 -0

index 5867384..f7d9ffd 100644
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+       struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
        u32 l;
 
        /* The controller handles the inverted chip selects

drivers/spi/spi-omap2-mcspi.c static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable) · line 260

Quoted 5 lines

drivers/spi/spi-omap2-mcspi.c +2 -0

@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                enable = !enable;
 
        if (spi->controller_state) {
+               pm_runtime_get_sync(mcspi->dev);
+

Should the return code should be checked here as with the other instances of pm_runtime_get_sync?

Quoted 13 lines

drivers/spi/spi-omap2-mcspi.c +3 -0

                l = mcspi_cached_chconf0(spi);
 
                if (enable)

@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                        l |= OMAP2_MCSPI_CHCONF_FORCE;
 
                mcspi_write_chconf0(spi, l);
+
+               pm_runtime_mark_last_busy(mcspi->dev);
+               pm_runtime_put_autosuspend(mcspi->dev);
        }
 }

Pali Rohár

author

2015-07-22 07:27 UTC #29 lore raw

Quoted 54 lines · On Wednesday 22 July 2015 00:13:34 Michael Welling wrote:

Quoted 27 lines · Sebastian Reichel
Hi,
Quoted 24 lines · Michael Welling
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into the kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your side.
drivers/spi/spi.c +0 -2
index cf8b91b..3164d13 100644
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
 	if (!spi->max_speed_hz)
 		spi->max_speed_hz = spi->master->max_speed_hz;
 
-	spi_set_cs(spi, false);
-
 	if (spi->master->setup)
 		status = spi->master->setup(spi);
 
Quoted 7 lines
drivers/spi/spi.c int spi_setup(struct spi_device *spi) · line 1811
Quoted 5 lines
drivers/spi/spi.c +2 -0
+	spi_set_cs(spi, false);
+
 	dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n",
 			(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
 			(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
mh. maybe a runtime PM issue?
mh?
Quoted 13 lines
* external abort on non-linefetch: address cannot be accessed, since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit faster (module must not be loaded from filesystem), so that the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to suspend after the runtime PM acquisition in setup()
Quoted 2 lines
So I suggest trying the following (compile tested only) patch:

Quoted 7 lines

It seems you are right.
With this patch the SPI drivers no longer cause data aborts.
I will wait for feedback from Pavel and Pali but it looks like we have a winner.

I'm busy right now for testing something on my N900...

Quoted 17 lines

-- Sebastian

drivers/spi/spi-omap2-mcspi.c +1 -0

index 5867384..f7d9ffd 100644
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+       struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
        u32 l;
 
        /* The controller handles the inverted chip selects

@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                enable = !enable;

Quoted 7 lines

drivers/spi/spi-omap2-mcspi.c static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable) · line 260
Quoted 3 lines
drivers/spi/spi-omap2-mcspi.c +2 -0
        if (spi->controller_state) {
+               pm_runtime_get_sync(mcspi->dev);
+
Should the return code should be checked here as with the other instances of pm_runtime_get_sync?

Yes, you *must* check return value of pm_runtime_get_sync! Otherwise we can get another oops/kernel panic. See similar commits:

f7b2b5dd6a62a47e871627c71ed01aa3482154d9
604c31039dae4653f33003d08c91ef58b70b5e63

Anyway, what do you think about adding gcc macro for pm_runtime_get_sync function which report compiler warning when return value is not checked?

Quoted 15 lines

Quoted 13 lines

drivers/spi/spi-omap2-mcspi.c +3 -0

                l = mcspi_cached_chconf0(spi);
 
                if (enable)

@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                        l |= OMAP2_MCSPI_CHCONF_FORCE;
 
                mcspi_write_chconf0(spi, l);
+
+               pm_runtime_mark_last_busy(mcspi->dev);
+               pm_runtime_put_autosuspend(mcspi->dev);
        }
 }

Signature · 2 lines

Pali Rohár
[email protected]

Pavel Machek

Tested-by

2015-07-22 13:30 UTC #32 lore raw

Quoted 47 lines · Sebastian Reichel

Hi,
Quoted 19 lines · Michael Welling
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into the kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your side.
drivers/spi/spi.c +0 -0
index cf8b91b..3164d13 100644
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
 	if (!spi->max_speed_hz)
 		spi->max_speed_hz = spi->master->max_speed_hz;
 
drivers/spi/spi.c int spi_setup(struct spi_device *spi) · line 1811
Quoted 10 lines
drivers/spi/spi.c +2 -2
-	spi_set_cs(spi, false);
-
 	if (spi->master->setup)
 		status = spi->master->setup(spi);
 
+	spi_set_cs(spi, false);
+
 	dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n",
 			(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
 			(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
mh. maybe a runtime PM issue?
* external abort on non-linefetch: address cannot be accessed, since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit faster (module must not be loaded from filesystem), so that the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to suspend after the runtime PM acquisition in setup()

Quoted 1 line

So I suggest trying the following (compile tested only) patch:

Solves problem for me. I had to apply it by patch -l.

Tested-by Pavel Machek <[email protected]>

Pavel

Quoted 33 lines

-- Sebastian

drivers/spi/spi-omap2-mcspi.c +6 -0

index 5867384..f7d9ffd 100644
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+       struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
        u32 l;
 
        /* The controller handles the inverted chip selects

@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                enable = !enable;
 
        if (spi->controller_state) {
+               pm_runtime_get_sync(mcspi->dev);
+
                l = mcspi_cached_chconf0(spi);
 
                if (enable)

@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                        l |= OMAP2_MCSPI_CHCONF_FORCE;
 
                mcspi_write_chconf0(spi, l);
+
+               pm_runtime_mark_last_busy(mcspi->dev);
+               pm_runtime_put_autosuspend(mcspi->dev);
        }
 }

Signature · 2 lines

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

Sebastian Reichel

2015-07-22 13:33 UTC #30 lore raw

Hi,

Quoted 15 lines · Pali Rohár

Quoted 15 lines

drivers/spi/spi-omap2-mcspi.c +1 -0

index 5867384..f7d9ffd 100644
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+       struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
        u32 l;
 
        /* The controller handles the inverted chip selects

@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                enable = !enable;

Quoted 6 lines

Quoted 6 lines
drivers/spi/spi-omap2-mcspi.c static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable) · line 260
Quoted 3 lines
drivers/spi/spi-omap2-mcspi.c +2 -0
        if (spi->controller_state) {
+               pm_runtime_get_sync(mcspi->dev);
+
Should the return code should be checked here as with the other instances of pm_runtime_get_sync?

Yes. If it fails, the line fetch error would be triggered again.

Probably the set_cs callback should also be changed, so that it can return an error code. This is not something for 4.2-rc, though.

Quoted 2 lines

Anyway, what do you think about adding gcc macro for pm_runtime_get_sync function which report compiler warning when return value is not checked?

Adding __must_check to pm_runtime_get_sync() should be discussed separately with the relevant people in Cc. A quick grep in drivers/ reveals a huge amount of code not handling pm_runtime_get_sync's return code.

-- Sebastian

Pali Rohár

author

2015-07-22 14:27 UTC #31 lore raw

Quoted 33 lines · On Wednesday 22 July 2015 15:33:18 Sebastian Reichel wrote:

Hi,
Quoted 15 lines · Pali Rohár
Quoted 15 lines
Quoted 15 lines
drivers/spi/spi-omap2-mcspi.c +1 -0
index 5867384..f7d9ffd 100644
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct spi_device *spi, int enable)
 
 static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
 {
+       struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
        u32 l;
 
        /* The controller handles the inverted chip selects
@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
                enable = !enable;
 
Quoted 6 lines
Quoted 6 lines
drivers/spi/spi-omap2-mcspi.c static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable) · line 260
Quoted 3 lines
drivers/spi/spi-omap2-mcspi.c +2 -0
        if (spi->controller_state) {
+               pm_runtime_get_sync(mcspi->dev);
+
Should the return code should be checked here as with the other instances of pm_runtime_get_sync?
Yes. If it fails, the line fetch error would be triggered again.
Probably the set_cs callback should also be changed, so that it can return an error code. This is not something for 4.2-rc, though.
Quoted 2 lines
Anyway, what do you think about adding gcc macro for pm_runtime_get_sync function which report compiler warning when return value is not checked?

Quoted 6 lines

Adding __must_check to pm_runtime_get_sync() should be discussed separately with the relevant people in Cc. A quick grep in drivers/ reveals a huge amount of code not handling pm_runtime_get_sync's return code.
-- Sebastian

Two times, missing check for pm_runtime_get_sync() cased kernel crash on Nokia N900. See that crypto commits. I think all drivers which do not check should be fixed. Otherwise we can see another mysterious problems.

Sebastian, can you CC relevant people? Or maybe start new thread?

Signature · 2 lines

Pali Rohár
[email protected]

Dave Young

2015-07-24 08:18 UTC #43 lore raw

http://talk.maemo.org/showpost.php?p=1459970&postcount=142

Quoted 7 lines · Pali Rohár

Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...

Pali, could you tell how do you test mainline kernel on n900?

I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.

I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?

Thanks
Dave

Ivaylo Dimitrov

2015-07-24 08:30 UTC #44 lore raw

Quoted 11 lines · Dave Young

Pali, could you tell how do you test mainline kernel on n900?
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?
Thanks
Dave

This is the last (almost) upstream kernel I tried, unfortunately recently I am very short on spare time, so cannot confirm for 4.x kernels, but in theory those should work as well.

The kernel tree was on gitorious, but it is down now(I have a local copy). However, all of the needed patches should be on https://github.com/pali/linux-n900.

Ivo

Pali Rohár

author

2015-07-24 08:40 UTC #47 lore raw

Quoted 11 lines · On Friday 24 July 2015 16:18:09 Dave Young wrote:

Quoted 7 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Pali, could you tell how do you test mainline kernel on n900?

Quoted 8 lines

I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?
Thanks
Dave

Hi! Starting Maemo with mainline kernel is not possible. But you can patch Maemo (userspace) and apply some kernel patches and you could boot Maemo system with Hildon UI.

You need:

Patched kernel:
https://github.com/pali/linux-n900

CSSU-devel:
https://wiki.maemo.org/CSSU
http://talk.maemo.org/showthread.php?t=84292

Open source battery management:
http://talk.maemo.org/showthread.php?t=93183

Fixup for Dialer application (rtcom-call-ui):
Fixing HAL path /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input

Fixup for SGX video driver:
Fixing script /etc/event.d/sgx

If you do not know how to fix HAL & SGX script I can send you later needed information. But I do not know them right now.

Signature · 2 lines

Pali Rohár
[email protected]

Pavel Machek

2015-07-24 08:51 UTC #51 lore raw

https://github.com/dderby/debian900

Quoted 9 lines · Dave Young

Quoted 7 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...

Quoted 7 lines

Pali, could you tell how do you test mainline kernel on n900?
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?

I'm successfully running MATE desktop from Debian. Even modem works with ofono and custom scripts.

https://wiki.debian.org/n900-wheezy-armhf
https://wiki.debian.org/MaemoAndSqueeze

(..and tui project on gitlab).
Pavel

Signature · 2 lines

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

Dave Young

2015-07-24 10:28 UTC #45 lore raw

In reply to Ivaylo Dimitrov

Quoted 18 lines · Ivaylo Dimitrov

Quoted 11 lines · Dave Young
Pali, could you tell how do you test mainline kernel on n900?
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?
Thanks
Dave
http://talk.maemo.org/showpost.php?p=1459970&postcount=142

Quoted 7 lines

This is the last (almost) upstream kernel I tried, unfortunately recently I am very short on spare time, so cannot confirm for 4.x kernels, but in theory those should work as well.
The kernel tree was on gitorious, but it is down now(I have a local copy). However, all of the needed patches should be on
https://github.com/pali/linux-n900.

Ivaylo, thanks for your info. I know pali's kernel tree, but the problem is I do not know much about the userspace fixes.

According to another reply from Pali, I should fix HAL and sgx start script.

Thanks
Dave

Dave Young

2015-07-24 10:33 UTC #48 lore raw

Hi, Pali

Quoted 18 lines · Pali Rohár

Quoted 17 lines · On Friday 24 July 2015 16:18:09 Dave Young wrote:
Quoted 7 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Pali, could you tell how do you test mainline kernel on n900?
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?

Quoted 8 lines

Quoted 2 lines
Thanks
Dave
Hi! Starting Maemo with mainline kernel is not possible. But you can patch Maemo (userspace) and apply some kernel patches and you could boot Maemo system with Hildon UI.

So I think mainline miss some patches in your linux-n900, I guess they are for SGX graphic driver?

Quoted 13 lines

You need:
Patched kernel:
https://github.com/pali/linux-n900
CSSU-devel:
https://wiki.maemo.org/CSSU
http://talk.maemo.org/showthread.php?t=84292
Open source battery management:
http://talk.maemo.org/showthread.php?t=93183

Quoted 8 lines

Fixup for Dialer application (rtcom-call-ui):
Fixing HAL path /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input
Fixup for SGX video driver:
Fixing script /etc/event.d/sgx
If you do not know how to fix HAL & SGX script I can send you later needed information. But I do not know them right now.

Yes, appreciated for that, just at anytime later you find it.
I have no much time either, so I believe first I need a lot of spare time to read the threads you mentioned.

Thanks
Dave

Dave Young

2015-07-24 10:39 UTC #52 lore raw

In reply to Pavel Machek

Quoted 21 lines · Pavel Machek

Quoted 9 lines · Dave Young
Quoted 7 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Quoted 7 lines
Pali, could you tell how do you test mainline kernel on n900?
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?
I'm successfully running MATE desktop from Debian. Even modem works with ofono and custom scripts.

Quoted 6 lines

https://github.com/dderby/debian900
https://wiki.debian.org/n900-wheezy-armhf
https://wiki.debian.org/MaemoAndSqueeze
(..and tui project on gitlab).

Pavel, it is very helpful, actually I do not care much about modem. Will take a look at how Debian works as well. Maybe I should send private email to ask these and future questions, it is off topic now...

Thanks
Dave

Pali Rohár

author

2015-07-24 10:52 UTC #49 lore raw

Quoted 26 lines · On Friday 24 July 2015 18:33:51 Dave Young wrote:

Hi, Pali
Quoted 23 lines · Pali Rohár
Quoted 19 lines · On Friday 24 July 2015 16:18:09 Dave Young wrote:
Quoted 7 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Pali, could you tell how do you test mainline kernel on n900?
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?
Thanks
Dave

Quoted 7 lines

Quoted 3 lines
Hi! Starting Maemo with mainline kernel is not possible. But you can patch Maemo (userspace) and apply some kernel patches and you could boot Maemo system with Hildon UI.
So I think mainline miss some patches in your linux-n900, I guess they are for SGX graphic driver?

Yes. Status of kernel driver is here: http://elinux.org/N900

Quoted 22 lines

Quoted 13 lines
You need:
Patched kernel:
https://github.com/pali/linux-n900
CSSU-devel:
https://wiki.maemo.org/CSSU
http://talk.maemo.org/showthread.php?t=84292
Open source battery management:
http://talk.maemo.org/showthread.php?t=93183
Quoted 8 lines
Fixup for Dialer application (rtcom-call-ui):
Fixing HAL path /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input
Fixup for SGX video driver:
Fixing script /etc/event.d/sgx
If you do not know how to fix HAL & SGX script I can send you later needed information. But I do not know them right now.

Quoted 6 lines

Yes, appreciated for that, just at anytime later you find it.
I have no much time either, so I believe first I need a lot of spare time to read the threads you mentioned.
Thanks
Dave

Just first post of those threads should be enough.

Signature · 2 lines

Pali Rohár
[email protected]

Pali Rohár

author

2015-07-24 10:53 UTC #46 lore raw

Quoted 27 lines · On Friday 24 July 2015 18:28:44 Dave Young wrote:

Quoted 18 lines · Ivaylo Dimitrov
Quoted 11 lines · Dave Young
Pali, could you tell how do you test mainline kernel on n900?
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?
Thanks
Dave
http://talk.maemo.org/showpost.php?p=1459970&postcount=142
Quoted 7 lines
This is the last (almost) upstream kernel I tried, unfortunately recently I am very short on spare time, so cannot confirm for 4.x kernels, but in theory those should work as well.
The kernel tree was on gitorious, but it is down now(I have a local copy). However, all of the needed patches should be on
https://github.com/pali/linux-n900.

Quoted 7 lines

Ivaylo, thanks for your info. I know pali's kernel tree, but the problem is I do not know much about the userspace fixes.
According to another reply from Pali, I should fix HAL and sgx start script.
Thanks
Dave

It is not enough, also you need to update Maemo to CSSU-devel version and install BME replacement stuff (open source battery management).

Signature · 2 lines

Pali Rohár
[email protected]

Pali Rohár

author

2015-07-24 15:50 UTC #50 lore raw

Quoted 33 lines · On Friday 24 July 2015 10:40:58 Pali Rohár wrote:

Quoted 10 lines · On Friday 24 July 2015 16:18:09 Dave Young wrote:
Quoted 6 lines · Pali Rohár
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Pali, could you tell how do you test mainline kernel on n900?
Quoted 8 lines
I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop.
I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel?
Thanks
Dave
Hi! Starting Maemo with mainline kernel is not possible. But you can patch Maemo (userspace) and apply some kernel patches and you could boot Maemo system with Hildon UI.
You need:
Patched kernel:
https://github.com/pali/linux-n900
CSSU-devel:
https://wiki.maemo.org/CSSU
http://talk.maemo.org/showthread.php?t=84292

Quoted 7 lines

Open source battery management:
http://talk.maemo.org/showthread.php?t=93183
Fixup for Dialer application (rtcom-call-ui):
Fixing HAL path /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input

Create new file /etc/event.d/userspace-fixes with content:

start on started hildon-desktop
service
console none
script

	if ! hal-device /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input 2> /dev/null; then
		hal-device --add /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input < /dev/null
		hal-set-property --udi /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input --key input.jack.type --
strlist-pre "a"
		hal-set-property --udi /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input --key input.jack.type --

strlist-rem "a"
fi
end script

Quoted 3 lines

Fixup for SGX video driver:
Fixing script /etc/event.d/sgx

Change if condition to:

if [ -n "$(grep RX-51 /proc/component_version)" ] && uname -r | grep -q '^2.'; then

Signature · 2 lines

Pali Rohár
[email protected]

Pali Rohár

author Tested-by

2015-07-25 08:55 UTC #33 lore raw