Fwd: LCM flicker

[Wolfgang Spraul]

fyi

Begin forwarded message:

> From: Carsten Haitzler (The Rasterman) <raster at openmoko.org>
> Date: March 9, 2008 6:17:56 PM GMT+08:00
> To: Andy Green <andy at openmoko.com>
> Cc: Wolfgang Spraul <wolfgang at openmoko.com>, Sean Moss-Pultz <sean at openmoko.com 
> >, William Lai <will at openmoko.com>, "Tony Tu)" <tony at openmoko.com>,  
> matt_hsu <matt_hsu at openmoko.org>, Chia-I Wu <olv at openmoko.com>,  
> Werner Almesberger <werner at openmoko.org>
> Subject: Re: LCM flicker
>
> On Sun, 09 Mar 2008 09:38:30 +0000 Andy Green <andy at openmoko.com>  
> babbled:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Somebody in the thread at some point said:
>>> On Sun, 9 Mar 2008 16:15:10 +0800 Wolfgang Spraul <wolfgang at openmoko.com 
>>> >
>>> babbled:
>>>
>>>> raster -
>>>> again, landscape is off right now, we can disable landscape  
>>>> altogether
>>>> for now. If you think this can later be fixed in software by  
>>>> using the
>>>> 2d engine to do in-lace, EVEN BETTER!
>>>
>>> that's what i said. if u want landscape - u get flicker. too bad.  
>>> we can
>>> disable it in software. i did not advocate that we sink time into  
>>> fixing it
>>> now. we CAN fix it later. we have an opt-out clause.
>>>
>>>> But right now let's focus on the portrait flickering.
>>>> Your observations are great! Real news...
>>>
>>> well that's just what i noticed. it could also be our 50hz  
>>> refresh. thats
>>> what xrandr says we are doing, and 25hz in landscape mode. that is  
>>> the
>>> killer. the lcm is probably expecting 60hz minimum.
>>
>> Hi Carsten --
>>
>> Interesting about the different colour channels acting  
>> differently.  If
>> it is easy for you, maybe you could also try alternate red/blue  
>> lines on
>> a stride of 2 or 4 for example to see if there is a pathological
>> pattern.  When we had this bug with the PLL divider register getting
>> trashed on the Glamo and we saw really slow refresh (like ~1Hz), I
>> noticed there seemed to be some kind of interlace action going on  
>> where
>> the redraw was happening.  It didn't look like true progressive scan.
>>
>> If you do the math on the PCLK vs actual overscan effective pixels,  
>> it
>> comes out to 60Hz is what we deliver in portrait right now.   
>> There's no
>> way 60Hz noninterlaced refresh should give flicker by itself.
>
> hhmmm. then xrandr is lying to me, it claims 50hz. aqnd it claims  
> 25hz for
> landscape mode (which explains the much worse flicker).
>
>> Either the refresh action we perform "beats" against another  
>> oscialltor
>> inside the LCM ("booster" or this "internal" osciallator), or there  
>> is
>> some kind of PWM trickery used to get the intensity levels that we  
>> beat
>> against somehow.
>
> i haven't found a pathological pattern yet - but it seems a smooth  
> gradient - in
> ANY direction seems to bring it out. that doesn't help me figure out  
> what kind
> of pathological pattern is causing it. for that matter a solid  
> orange color
> region flickers too - all by itself. no gradient needed.
>
> rgb: 255 145 0 does a wonder flickering job. this is totally bizarre  
> unles u
> look at there being some temporal interference pattern on the r & b  
> signals
> that doesn't affect g, and the interference pattern is inverted  
> between r & b.
>
>> - -Andy
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>>
>> iD8DBQFH07AWOjLpvpq7dMoRAiUlAJ9KoQLqsX8hW+IPHwwzU0DfGTRwZgCfRV1Y
>> SarAlpZB/cZdMbTe4HfvSzQ=
>> =ecwK
>> -----END PGP SIGNATURE-----
>
>
> -- 
> Carsten Haitzler (The Rasterman) <raster at openmoko.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080309/960f03ab/attachment.htm