development kernel tree: Changes to 'andy'

[git at git.openmoko.org]

Rebased ref, commits from common ancestor:
commit 67ea19390b2c162de297056848122dff155ea5f8
Author: Andy Green <andy at openmoko.com>
Date:   Wed Aug 13 12:17:14 2008 +0100

    fix-eviocgrab-switch-type.patch
    
    Signed-off-by: Andy Green <andy at openmoko.com>

commit d6c00a9dad8320fc422faf5d2e38b442ceccdca9
Author: Andy Green <agreen at pads.home.warmcat.com>
Date:   Wed Aug 13 12:15:54 2008 +0100

    On Wednesday August 13, mickey at openmoko.org 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 http://lkml.org/lkml/2006/8/12/64
    
    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
    events.
    
    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.
    
    Thanks,
    NeilBrown

commit bd73c4840670faf8718b0b0434bd4a541d335c9d
Author: Andy Green <andy at openmoko.com>
Date:   Wed Aug 13 12:14:58 2008 +0100

    revert-mokopatches-EVIOCGRAB-patch
    
    Signed-off-by: Andy Green <andy at openmoko.com>

commit b160b7afd8196b98801574705c2906c2a6cfe668
Author: Andy Green <andy at openmoko.com>
Date:   Wed Aug 13 12:04:12 2008 +0100

    fix-glamo-crank-memory-to-90MHz.patch
    
    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 openmoko.com>

commit b39594a3f1b2fc48625b57655412b8b8908bdfc3
Author: Andy Green <andy at openmoko.com>
Date:   Wed Aug 13 12:04:12 2008 +0100

    fix-glamo-turbo-host-interface.patch
    
    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 openmoko.com>

commit 9c247b3f54e9f49d50a7dc173665ff94ff9f6360
Author: Andy Green <andy at openmoko.com>
Date:   Wed Aug 13 12:04:12 2008 +0100

    fix-reote-install-for-ext3-only-sd.patch
    
    Signed-off-by: Andy Green <andy at openmoko.com>

commit cd12f22760bb8a5a0ef7248a359c2fafe4b7f3b2
Author: Andy Green <andy at openmoko.com>
Date:   Wed Aug 13 12:04:12 2008 +0100

    defconfig-nuke-cruft.patch
    
    Signed-off-by: Andy Green <andy at openmoko.com>

commit ec18c02e7bd4cbd756732324c14500a692b13789
Author: Andy Green <andy at openmoko.com>
Date:   Wed Aug 13 12:04:10 2008 +0100

    defconfig-kill-hxd8.patch
    
    Signed-off-by: Andy Green <andy at openmoko.com>