update from s-media regarding landscape flicker

joerg joerg.twinklephone at gmx.de
Tue Mar 25 12:44:18 CET 2008


Am Di  25. März 2008 schrieb Andy Green:
> - gpg control packet
> Somebody in the thread at some point said:
> 
> >> Does this help or did you try this already?
> >
> > I'll give these a go.  The patch for black snow also had implications
> > that might have reduced internal memory usage a bit.
> >
> > Not sure I would expect too much since apparently we run the memory
> 
> No it does not help.
> 
> The fix is applied OK because now we see
> 
> glamo3362 glamo3362.0: Glamo core now 49119232Hz CPU / 89980928Hz Memory)
> 
> and I confirm by register dump
> 
> 0040:  05db 52ae 0aba aeba 0003 0000 0000 0000
> 0600:  0c74 afaf 0108 0010 0000 0000 0000 0000
> 
> But it is evidently far enough underwater in terms of memory bandwidth
> for just the video refresh action that the extra 12% bandwidth did not
> even solve the artifact issue for +90 degree rotation in Glamo at 42Hz
> refresh that it gives us (ignoring the 72Hz we asked for).  Even if we
> got that working by this advice we are left with a 42Hz refresh that
> will likely flicker on that LCM.
> 
> I also confirm SD access remains really really slow in landscape mode
> another indication we still completely overwhelm the memory in landscape
> mode.
> 
> 
> It is still possible that the memory choking action is related to the
> second problem about forced 42Hz.  If you want to go around with S-Media
> again the question would be why is it that if we set up 72Hz portrait
> and then only set the rotation registers ALONE, we do not get 72Hz video
> out still but 42Hz which is unrelated to the settings we specified.
> 
> -Andy
> 

I really don't get it. When we have 24MHz pixelclock, this means there has to 
be a fetch cycle to ram to get 16bit of image data every 1/(24*10^6) sec. 
This holds valid, no matter whether in landscape or portrait mode, no? When 
RAM can cope with this in portrait, why not in landscape?
Of course the overall (picture) refresh timing (HSync) is a little (4/3 * 
vsync/real_data, sth around this figure) tweaked, but i don't see why 
**pixelclock** has to go down in landscape? Is this for the different address 
sequence scheme in RAM for each of the 2 modes, or does glamo some internal 
transformation by blitting, thus eating 2/3 of the bandwidth or what?

jOERG




More information about the openmoko-kernel mailing list