FSO 2.6.28 usage report
Wolfgang Spraul
wolfgang at openmoko.com
Mon Jan 12 14:38:41 CET 2009
Stefan,
> Well, this of course means we loking forward for more GTA01 support
> in .28,
> battery driver comes to mind. :D
I have recently shipped a GTA01 to Balaji, maybe he can help?
Andy can judge best who is in a good position... Getting the .28
kernel to work well on GTA01 is a high priority here.
Wolfgang
On Jan 12, 2009, at 9:33 PM, Stefan Schmidt wrote:
> Hello.
>
> On Mon, 2009-01-12 at 13:10, Andy Green wrote:
>>
>> Somebody in the thread at some point said:
>>
>> | But we also have a list of things that we would like to see fixed
>> now
>> that it is
>> | working good enough as a base for releases.
>> |
>> | rxerr on GPS serial port:
>> | http://docs.openmoko.org/trac/ticket/2180
>> | No reaction so far.
>>
>> Yes I think this is genuine diagnostic about edge appearing on RX
>> during
>> GPS wake. I don't know what it means that it appears during
>> transfer,
>> but I would hazard a guess it can be true. A long time ago someone
>> reported in then Bugzilla that if they had the debug cable connected,
>> they found interruptions and garbage on their GPS NMEA stream.
>
> So you say that there might be hw problems with the uart on the soc?
> Or a driver
> bug?
>
>> | Kernel oops when recording audio:
>> | http://docs.openmoko.org/trac/ticket/2179
>> | Initial reaction but dead since then.
>>
>> I asked a couple of people to look at it but oh well.
>>
>> There's another one which is xrandr rotate, Nelson is looking at it.
>
> ok
>
>> | Threshold for accels. We finally like to ship the great accel
>> gesture
>> | application from our GSoC student, but it would only be really
>> useful
>> if we
>> | could set a threshold instead of parsing data all the time and
>> burn cpu.
>>
>> This is done by Simon Kagstrom some time ago, it's down in /sys.
>> Maybe
>> Simon can give some advice.
>
> Cool, that must have slipped through our radar. Simon, is the
> threshold working
> and if how can we use it?
>
>> | Small note. The more drivers defconfig produces an image that is to
>> big for the
>> | default uboot env. As we don't want to support 100s people changing
>> the uboot
>> | env we make the config more modular in OE.
>>
>> Ah not so fast. There are two configs in the kernel tree, one is the
>> moredrivers config that is for unconditional driver availability, but
>> the other is gta02-packaging-defconfig which has roughly the same
>> module
>> set as the stable shipping kernel. I prefer that we keep the
>> packaging
>> kernel in the kernel tree as far as possible rather than have a
>> private
>> one squirrelled away in one build system. Have a look at it and if
>> you
>> see things you don't like can we change them here.
>
> Whops, since when you have this other config? Never seen it before.
>
> We can for sure make a sync for the general configs we changed. What
> we will
> always do is to mangle the config to build kernel for GTA01 and
> GTA01 from the
> same config. Jan, as you made the kernel more modular can you have a
> look how we
> can sync with the packaging config? Would this fit your schedule?
>
>> | For GTA01 we still use 2.6.24 and will test from time to time how
>> far
>> the .28
>> | support is there.
>>
>> Great.
>
> Well, this of course means we loking forward for more GTA01 support
> in .28,
> battery driver comes to mind. :D
>
> regards
> Stefan Schmidt
>
More information about the openmoko-kernel
mailing list