FSO 2.6.28 usage report

[Wolfgang Spraul]

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
>