development kernel tree: Changes to 'andy'

git at git at
Wed Aug 27 00:30:12 CEST 2008

Rebased ref, commits from common ancestor:
commit dd323382faf5c169960659d5d78337f06b3ea222
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:24 2008 +0900

    This large patch removes motion sensor from Linux SPI bitbang driver.
    Previously, some access was done through Linux SPI protected
    by a mutex, and the ISR access was done by platform bitbang code due
    to inability of Linux SPI driver to work in the interrupt context.
    Now all access is done by bitbang callbacks in mach_gta02.c and are
    protected by single scheme of interrupt lockout for the duration --
    I line-by-line'd the driver to confirm that best I could, adding
    protection and taking more care on several /sys related paths.
    Because this is no longer a Linux SPI bus driver, the path for various
    /sys things have changed.  They can now be found down, eg,
    lis302dl.1 is the top sensor and .2 the bottom.  The names of the input
    susbsytem paths remain the same as before.
    Signed-off-by: Andy Green <andy at>

commit 19d5505920acd5fedabbc5cc1a0b550a0c09f3fa
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:24 2008 +0900

    Signed-off-by: Andy Green <andy at>

commit 9c3698334862d4e21482c8613dc4b1098c823836
Author: Neil Brown <neilb at>
Date:   Wed Aug 27 07:28:23 2008 +0900

    On Wednesday August 13, mickey at wrote:
    > Am Mittwoch 13 August 2008 09:13:43 schrieb Neil Brown:
    > > Hi I just spent some time trying to figure out why the EVIOCGRAB ioctl
    > > wasn't behaving was I expected and I finally stumbled on to this
    > > patch, which substantially changes the behaviour of EVIOCGRAB.
    > >
    > > Would it be possible to find out what the purpose of this patch is (it
    > > unfortunately contains no documentation)?
    > See
    Thanks for the pointer!  Interesting reading.
    So this is a 2 year old issue (almost to the day!) which does not
    appear to have been properly resolved yet.  Sad.
    An input device (e.g. touch pad, key board) can be attached to
    multiple handlers (/dev/mouseX, console, etc) one of which can be
    evdev which provides the /dev/input/event* files.
    evdev can support multiple clients on a single device, as multiple
    processes can open /dev/input/eventX.  The each get to see all the
    EVIOCGRAB is an ioctl on an evdev device which causes all events to go
    to that handler, and that client, exclusively.
    It is being used for two distinct purposes.
    1/ Stop events going to other handlers, so that e.g. absolute touchpad
       events don't get mapped to relative mouse events.  Keyboard events
       processed by X server don't get processed by console and control-C
       kills the X server.
    2/ Stop events going to any other client, so they can e.g. be mapped
       and fed back into a uinput device,
    So there are three levels of grab that are required:
     0/ no grab : all events go to all handlers and all clients
     1/ evdev grab: events only go to evdev, but can then go to any
           client of evdev
     2/ total grab:  events only go to the specific evdev client that
           requested the grab.
    0 is the default
    mainline allows you to select 2 but not 1.
    this patch allows you to select 1, but not 2.
    It seems that the "obvious" thing to do is to interpret the argument
    to EVIOCGRAB to select between these options.
    We cannot use 0, 1, 2 as above - despite the fact that it makes sense
    - because that would be a regression: working programs would break.
    Maybe it's best to use 0, 2, 1 and document it clearly.  The chance of
    anyone using 2 already has got to be very close to zero.
    We would then need to change the drivers in the X server to use '2'
    rather than '1', and (I think) everyone would be happy.
    Below is my proposed patch which provides the functionality of
    the patch in question without causing any regressions.
    It also fixes two minor buglets in the original.
    If anyone would like to comment, I'd appreciate it.  If I hear nothing
    bad I'll propose it to Dimitry Torokhov on some appropriate list.

commit ae61261eae989cc6f1e0da23ff3d2b4b33ab5aa2
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:23 2008 +0900

    Signed-off-by: Andy Green <andy at>

commit 5b9e0604ca4691782680e52cae6ffac32881a6b0
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:22 2008 +0900

    This changes Glamo memory and now host bus PLL to 90MHz from
    80MHz, as recommended by S-Media.  Bandwidth should go up
    by 12.5% by this in raw terms anyway.
    Signed-off-by: Andy Green <andy at>

commit 653f1f27b2c09b8f3ee1869f35ff6a0a50bb01b0
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:22 2008 +0900

    Until now, we forced Glamo wait states to 3 on read and write
    actions -- on the GLAMO side of the fence.  This reduces them
    to "0", although nWAIT is still briefly operated I saw.  This
    should reduce all memory bus timing by 3 Glamo Host bus clocks,
    60ns at 50MHz.
    In addition, until now we used PLL1 (50MHz) for host bus clock.
    Now, we use PLL2 (80MHz) for host bus clock, so all transactions
    complete quicker on Glamo side, it's a raw 60% improvement.
    These changes do not appear to impact correct operation of Glamo
    SD Card or video after testing for a week.
    Signed-off-by: Andy Green <andy at>

commit 99ccd6baba61c2271cae70f1578832cf1191186b
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:22 2008 +0900

    Signed-off-by: Andy Green <andy at>

commit 8f31eb0a35c16ecc2431c0b9f6878aea3acfbb71
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:21 2008 +0900

    Signed-off-by: Andy Green <andy at>

commit a7a713ab25569dd589c7743d54a33be95b7aa3b0
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:21 2008 +0900

    Signed-off-by: Andy Green <andy at>

commit e0f638132e25275ced5a2486593047262b438f55
Author: Mike Westerhof <mwester at>
Date:   Wed Aug 27 07:28:21 2008 +0900

        Add missing initialization for the touchscreen driver for the
        gta01 platform.
        Signed-off-by: Mike Westerhof <mwester at>

commit 95312676221e07b8696d4195daa1444940439d74
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:20 2008 +0900

    Signed-off-by: Andy Green <andy at>

commit 5d9326798f95e71e06e3bdb6af17792922602842
Author: Andy Green <andy at>
Date:   Wed Aug 27 07:28:20 2008 +0900

    Signed-off-by: Andy Green <andy at>

commit d744c88c149269b95ec068c8615e492375415d6d
Author: Andy Green <andy at>
Date:   Wed Aug 27 04:09:30 2008 +0900

    Some boots from Qi trigger a symptom from this interesting race -->
    [    2.730000] Unable to handle kernel NULL pointer dereference at virtual address 00000248
    [    2.730000] pgd = c0004000
    [    2.735000] [00000248] *pgd=00000000
    [    2.735000] Internal error: Oops: 5 [#1] PREEMPT
    [    2.735000] Modules linked in:
    [    2.735000] CPU: 0    Not tainted  (2.6.24-stable10_0c1587137aaf0ee3-mokodev #1071)
    [    2.735000] PC is at pcf50633_voltage_set+0x1c/0xfc
    [    2.735000] LR is at gta02_glamo_mmc_set_power+0xdc/0x128
    [    2.735000] pc : [<c01df570>]    lr : [<c0034324>]    psr: 60000013
    [    2.735000] sp : c7c57eb0  ip : c7c57ec8  fp : c7c57ec4
    [    2.735000] r10: c7cfca28  r9 : 00000000  r8 : c7c57f68
    [    2.735000] r7 : c7cfca68  r6 : c7cfcae0  r5 : 00000c80  r4 : 00000000
    [    2.735000] r3 : 00000000  r2 : 00000c80  r1 : 0000000a  r0 : 00000c80
    [    2.735000] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    [    2.735000] Control: c000717f  Table: 30004000  DAC: 00000017
    [    2.735000] Process kmmcd (pid: 102, stack limit = 0xc7c56268)
    [    2.735000] Stack: (0xc7c57eb0 to 0xc7c58000)
    [    2.735000] 7ea0:                                     c0608c58 00000c80 c7c57edc c7c57ec8
    [    2.735000] 7ec0: c0034324 c01df564 c7cfca28 c7cfc800 c7c57f1c c7c57ee0 c0194de0 c0034258
    [    2.735000] 7ee0: c7c57f34 c7c57ef0 c01e6230 c005de5c 60000013 c7cfca28 c7cfc800 60000013
    [    2.735000] 7f00: c7cfca68 c7c57f68 00000000 c01e6778 c7c57f34 c7c57f20 c01e5d68 c0194da8
    [    2.735000] 7f20: c7cfc800 c7cfca08 c7c57f5c c7c57f38 c01e6810 c01e5cbc c0059278 c7c57f48
    [    2.735000] 7f40: c02d2ba0 00000002 c7c44420 c7c56000 c7c57f9c c7c57f60 c00592e0 c01e6788
    [    2.735000] 7f60: 00000002 c0059278 c0608d74 c04321cc c036e16c 00000000 c7c57fb0 c7c44420
    [    2.735000] 7f80: c7c56000 00000000 00000000 00000000 c7c57fd4 c7c57fa0 c005a068 c00591ec
    [    2.735000] 7fa0: c02d0624 00000000 c7c4c0e0 c005dc2c c7c57fb0 c7c57fb0 00000000 c7c56000
    [    2.735000] 7fc0: c7c44420 c0059f84 c7c57ff4 c7c57fd8 c005db28 c0059f94 00000000 00000000
    [    2.735000] 7fe0: 00000000 00000000 00000000 c7c57ff8 c004b170 c005dad8 ffffffff ffffffff
    [    2.735000] Backtrace:
    [    2.735000] [<c01df554>] (pcf50633_voltage_set+0x0/0xfc) from [<c0034324>] (gta02_glamo_mmc_set_power+0xdc/0x128)
    [    2.735000]  r5:00000c80 r4:c0608c58
    [    2.735000] [<c0034248>] (gta02_glamo_mmc_set_power+0x0/0x128) from [<c0194de0>] (glamo_mci_set_ios+0x48/0x254)
    [    2.735000]  r5:c7cfc800 r4:c7cfca28
    [    2.735000] [<c0194d98>] (glamo_mci_set_ios+0x0/0x254) from [<c01e5d68>] (mmc_power_up+0xbc/0x100)
    [    2.735000] [<c01e5cac>] (mmc_power_up+0x0/0x100) from [<c01e6810>] (mmc_rescan+0x98/0x1a8)
    [    2.735000]  r5:c7cfca08 r4:c7cfc800
    [    2.735000] [<c01e6778>] (mmc_rescan+0x0/0x1a8) from [<c00592e0>] (run_workqueue+0x104/0x208)
    [    2.735000]  r6:c7c56000 r5:c7c44420 r4:00000002
    [    2.735000] [<c00591dc>] (run_workqueue+0x0/0x208) from [<c005a068>] (worker_thread+0xe4/0xf8)
    [    2.735000] [<c0059f84>] (worker_thread+0x0/0xf8) from [<c005db28>] (kthread+0x60/0x94)
    [    2.735000]  r6:c0059f84 r5:c7c44420 r4:c7c56000
    [    2.735000] [<c005dac8>] (kthread+0x0/0x94) from [<c004b170>] (do_exit+0x0/0x6f4)
    [    2.735000]  r6:00000000 r5:00000000 r4:00000000
    [    2.735000] Code: e351000a e1a04000 e1a00002 8a000032 (e5943248)
    [    2.745000] ---[ end trace 123ec1d286354824 ]---
    This problem was caused by insufficient timeout waiting for pcf50633 to resume
    and broken code to detect timeout exhaustion.
    Although I'd like to think it has something to do with mmc resume woes it should make a panic
    and subsequent emergency spew on UART2 if that had been the case.
    Took the opportunity to move the stuff to show completion of probe to later in the
    pcf50633 probe and tighten readiness test.
    Signed-off-by: Andy Green <andy at>

More information about the commitlog mailing list