development kernel tree: Changes to 'andy'
git at git.openmoko.org
git at git.openmoko.org
Wed Aug 27 00:30:12 CEST 2008
Rebased ref, commits from common ancestor:
commit dd323382faf5c169960659d5d78337f06b3ea222
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:24 2008 +0900
fix-lid302dl-bitbang-all-the-way-baby.patch
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,
/sys/devices/platform/lis302dl.1/sample_rate
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 openmoko.com>
commit 19d5505920acd5fedabbc5cc1a0b550a0c09f3fa
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:24 2008 +0900
fix-eviocgrab-switch-type.patch
Signed-off-by: Andy Green <andy at openmoko.com>
commit 9c3698334862d4e21482c8613dc4b1098c823836
Author: Neil Brown <neilb at suse.de>
Date: Wed Aug 27 07:28:23 2008 +0900
fix-EVIOCGRAB-redone.patch
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 ae61261eae989cc6f1e0da23ff3d2b4b33ab5aa2
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:23 2008 +0900
revert-mokopatches-EVIOCGRAB-patch
Signed-off-by: Andy Green <andy at openmoko.com>
commit 5b9e0604ca4691782680e52cae6ffac32881a6b0
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:22 2008 +0900
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 653f1f27b2c09b8f3ee1869f35ff6a0a50bb01b0
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:22 2008 +0900
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 99ccd6baba61c2271cae70f1578832cf1191186b
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:22 2008 +0900
fix-reote-install-for-ext3-only-sd.patch
Signed-off-by: Andy Green <andy at openmoko.com>
commit 8f31eb0a35c16ecc2431c0b9f6878aea3acfbb71
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:21 2008 +0900
defconfig-nuke-cruft.patch
Signed-off-by: Andy Green <andy at openmoko.com>
commit a7a713ab25569dd589c7743d54a33be95b7aa3b0
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:21 2008 +0900
defconfig-kill-hxd8.patch
Signed-off-by: Andy Green <andy at openmoko.com>
commit e0f638132e25275ced5a2486593047262b438f55
Author: Mike Westerhof <mwester at dls.net>
Date: Wed Aug 27 07:28:21 2008 +0900
fix-touchscreen-driver-gta01-missing-includes.patch
Add missing initialization for the touchscreen driver for the
gta01 platform.
Signed-off-by: Mike Westerhof <mwester at dls.net>
commit 95312676221e07b8696d4195daa1444940439d74
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:20 2008 +0900
test-touchscreen-median.patch
Signed-off-by: Andy Green <andy at openmoko.com>
commit 5d9326798f95e71e06e3bdb6af17792922602842
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 07:28:20 2008 +0900
config-touchscreen-filters.patch
Signed-off-by: Andy Green <andy at openmoko.com>
commit d744c88c149269b95ec068c8615e492375415d6d
Author: Andy Green <andy at openmoko.com>
Date: Wed Aug 27 04:09:30 2008 +0900
fix-one-mmc-race.patch
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 openmoko.com>
More information about the commitlog
mailing list