Send commitlog mailing list submissions to
commitlog@lists.openmoko.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/commitlog
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of commitlog digest..."
Today's Topics:
1. development kernel tree: Changes to 'stable'
([EMAIL PROTECTED])
2. Openmoko's OpenEmbedded repository. This is used to build the
Openmoko distribution: Changes to 'org.openmoko.dev'
([EMAIL PROTECTED])
3. Openmoko's OpenEmbedded repository. This is used to build the
Openmoko distribution: Changes to 'org.openmoko.dev'
([EMAIL PROTECTED])
4. Holger's qtopia repo: Changes to 'master' ([EMAIL PROTECTED])
5. Openmoko's OpenEmbedded repository. This is used to build the
Openmoko distribution: Changes to 'org.openmoko.asu.dev'
([EMAIL PROTECTED])
6. Openmoko's OpenEmbedded repository. This is used to build the
Openmoko distribution: Changes to 'org.openmoko.asu.testing'
([EMAIL PROTECTED])
7. development kernel tree: Changes to 'andy' ([EMAIL PROTECTED])
--- Begin Message ---
arch/arm/mach-s3c2440/mach-gta02.c | 4 ++--
drivers/i2c/chips/pcf50633.c | 12 ++++++++----
2 files changed, 10 insertions(+), 6 deletions(-)
New commits:
commit d744c88c149269b95ec068c8615e492375415d6d
Author: Andy Green <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
--- End Message ---
--- Begin Message ---
classes/rootfs_ipk.bbclass | 2 +-
classes/rootfs_opk.bbclass | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 5e659abf436623d0e924d50b64e5a01660d3a636
Author: Graeme Gregory <[EMAIL PROTECTED]>
Date: Tue Aug 26 20:36:22 2008 +0100
[rootfs_?pk.bbclass] add -force-defaults to _ARGS to stop asking
questions when not running interactive.
--- End Message ---
--- Begin Message ---
conf/distro/include/preferred-om-2008-versions.inc | 2 +-
packages/bluez/bluez-utils-alsa_3.28.bb | 5 ---
packages/bluez/bluez-utils-alsa_3.33.bb | 25 ++++++++++++++
packages/bluez/bluez-utils3-alsa.inc | 28 ----------------
packages/bluez/bluez-utils3-main.inc | 35 --------------------
packages/bluez/bluez-utils3.inc | 20 ++++++++---
6 files changed, 41 insertions(+), 74 deletions(-)
New commits:
commit 6f6835b2fc105328ad6c7489272309834f0c05d2
Author: Graeme Gregory <[EMAIL PROTECTED]>
Date: Tue Aug 26 20:53:30 2008 +0100
[bluez-utils-alsa] uprev and sync with OE
--- End Message ---
--- Begin Message ---
.../phonevendors/ficgta01/vendor_ficgta01.cpp | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
New commits:
commit 13101ab6ddaec380871ae8021a92140af526c4df
Author: Holger Freyther <[EMAIL PROTECTED]>
Date: Tue Aug 26 22:23:13 2008 +0200
[ficgta01] Fix phonebook init regression from
9971aa8a69e31057b0f02af43b4c20333a77f13e
When not waiting for RDY, 1 anymore my phone started to show the old
issue with not querying the addressbook correctly. For some reason
somewhen
early in the init sequence a %CSTAT PHB, 1 comes by and we set
m_phoneBookIsReady to true.
To fix this issue and hopefully not regress in another way we keep
track of the status. So if phonebook goes from 0, 1 to 0 again we set
m_phoneBookIsReady is to false. This means we wait for the point when
both
SMS and PHB are ready.
--- End Message ---
--- Begin Message ---
conf/distro/include/sane-srcrevs.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
New commits:
commit 5f9fcbc6c66577d87fd915989fdf07b4791a71e4
Author: Holger Hans Peter Freyther <[EMAIL PROTECTED]>
Date: Tue Aug 26 22:40:02 2008 +0200
[srcrev] Upgrade Qtopia to get the SMS and phonebook on reset fix
- Tick changed the parsing of the Qtopia PDU, let us see if that
is making things better.
- I was seeing issues with my phonebook (not being listed)
after resets and such and this should be addressed now.
--- End Message ---
--- Begin Message ---
conf/distro/include/sane-srcrevs.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
New commits:
commit 70424588006d254f5c8c3157e4fbcc198fc8597d
Author: Holger Hans Peter Freyther <[EMAIL PROTECTED]>
Date: Tue Aug 26 22:40:02 2008 +0200
[srcrev] Upgrade Qtopia to get the SMS and phonebook on reset fix
- Tick changed the parsing of the Qtopia PDU, let us see if that
is making things better.
- I was seeing issues with my phonebook (not being listed)
after resets and such and this should be addressed now.
--- End Message ---
--- Begin Message ---
Rebased ref, commits from common ancestor:
commit dd323382faf5c169960659d5d78337f06b3ea222
Author: Andy Green <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
commit 19d5505920acd5fedabbc5cc1a0b550a0c09f3fa
Author: Andy Green <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:24 2008 +0900
fix-eviocgrab-switch-type.patch
Signed-off-by: Andy Green <[EMAIL PROTECTED]>
commit 9c3698334862d4e21482c8613dc4b1098c823836
Author: Neil Brown <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:23 2008 +0900
fix-EVIOCGRAB-redone.patch
On Wednesday August 13, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:23 2008 +0900
revert-mokopatches-EVIOCGRAB-patch
Signed-off-by: Andy Green <[EMAIL PROTECTED]>
commit 5b9e0604ca4691782680e52cae6ffac32881a6b0
Author: Andy Green <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
commit 653f1f27b2c09b8f3ee1869f35ff6a0a50bb01b0
Author: Andy Green <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
commit 99ccd6baba61c2271cae70f1578832cf1191186b
Author: Andy Green <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:22 2008 +0900
fix-reote-install-for-ext3-only-sd.patch
Signed-off-by: Andy Green <[EMAIL PROTECTED]>
commit 8f31eb0a35c16ecc2431c0b9f6878aea3acfbb71
Author: Andy Green <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:21 2008 +0900
defconfig-nuke-cruft.patch
Signed-off-by: Andy Green <[EMAIL PROTECTED]>
commit a7a713ab25569dd589c7743d54a33be95b7aa3b0
Author: Andy Green <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:21 2008 +0900
defconfig-kill-hxd8.patch
Signed-off-by: Andy Green <[EMAIL PROTECTED]>
commit e0f638132e25275ced5a2486593047262b438f55
Author: Mike Westerhof <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
commit 95312676221e07b8696d4195daa1444940439d74
Author: Andy Green <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:20 2008 +0900
test-touchscreen-median.patch
Signed-off-by: Andy Green <[EMAIL PROTECTED]>
commit 5d9326798f95e71e06e3bdb6af17792922602842
Author: Andy Green <[EMAIL PROTECTED]>
Date: Wed Aug 27 07:28:20 2008 +0900
config-touchscreen-filters.patch
Signed-off-by: Andy Green <[EMAIL PROTECTED]>
commit d744c88c149269b95ec068c8615e492375415d6d
Author: Andy Green <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
--- End Message ---
_______________________________________________
commitlog mailing list
commitlog@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/commitlog
