stable-tracking test image

Petr Vanek vanous at
Tue Nov 18 11:52:46 CET 2008

On Tue, 18 Nov 2008 11:38:25 +0100
Petr Vanek <vanous at> (PV) wrote:

>On Tue, 18 Nov 2008 11:15:05 +0100
>Petr Vanek <vanous at> (PV) wrote:
>>On Tue, 18 Nov 2008 08:29:36 +0000
>>Andy Green <andy at> (AG) wrote:
>>>Hash: SHA1
>>>Somebody in the thread at some point said:
>>>| i am not sure if this is helpful but i have tried to disable X and
>>>run | just the terminal. Then after suspend (apm -s) and resume the
>>>screen | remained white (wsod) again (so Xwin was not loaded at all).
>>>It's about as helpful as we can hope for, thanks... suspend and
>>>resume with echo mem > /sys/power/state here (I will try apm -s) at
>>>least does not make WSOD ever since the glamo gpio change.  So we are
>>>fighting the same problem Harald found that some devices do it and
>>>some don't I think.
>>>There is still a race flying about, between jbt6k74 (LCM ASIC) resume
>>>and the async action of framebuffer unblank, which calls through to
>>>jbt6k74 stuff even when it might be suspended.  They should be
>>>serialized by mutex or whatever but it's possible the one can crap on
>>>the state of the other at the LCM ASIC in a way leading to WSOD and
>>>that's part of the mystery.
>>>Because we want Balaji's stuff in the new stable it will be branched
>>>off andy-tracking rather than stable-tracking when we nuke the last
>>>few bugs including this.  (Balaji's stuff is based off
>>>stable-tracking, andy-tracking is based off Balaji's stuff; but if we
>>>import Balaji's stuff direct to stable-tracking it will conflict when
>>>we see it come in from upstream.)  So I am uploading kernels from
>>>andy-tracking now here:
>>>one of the changes in Balaji's work is that the backlight device is
>>>now a child of the LCM ASIC driver, if this doesn't fix the race it
>>>could at least modify it.  So if this is anything to do with
>>>anything, it's possible andy-tracking stuff may act differently
>>so i have flashed
>>uImage-moredrivers-GTA02_andy-tracking_c08a4eb0f4266a72.bin and used
>>this Qi qi-s3c2442-andy_7cc3d38184ae30bd.udfu which surprisingly
>>loaded the kernel from NAND??? (flash card outside on the table:
>>root at om-gta02:~# uname -a
>>Linux om-gta02 2.6.28-GTA02_andy-tracking_c08a4eb0f4266a72-mokodev
>>#168 PREEMPT Mon Nov 17 17:04:29 GMT 2008 armv4tl unknown
>>wsod again, i tried echo mem > /sys/power/state and then did suspend
>>by the button... i think... :) 
>>but this kernel doesn't have
>>/sys/class/i2c-adapter/i2c-0/0-0073/glamo3362.0/regs to send any
>ufff, after reboot the display did not react at all, removing battery
>and reboot did not help, flashing todays daily release of u-boot and
>kernel fixed this. what a fright i got... i can still retry if needed
>and if i find some courage :) please let me know,

sorry for not being spesific: touch screen did not react to touches,
displaying was OK.


More information about the openmoko-kernel mailing list