[Fwd: Re: about landscape mode in GTA02]

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI

- -------- Original Message --------
Subject: Re: about landscape mode in GTA02
Date: Tue, 18 Mar 2008 16:15:30 +0000
From: Andy Green <andy at openmoko.com>
To: tony at openmoko.com
CC: Dodji Seketeli <dodji at openedhand.com>,  matt_hsu
<matt_hsu at openmoko.org>, Wolfgang Spraul <wolfgang at openmoko.com>
References: <47DF6ED9.7000404 at openmoko.com>
<47DF9944.7010605 at openmoko.com> <47DFAE24.5080909 at openmoko.com>
<47DFAFAB.6000903 at openmoko.com>

Somebody in the thread at some point said:
> Somebody in the thread at some point said:
>> Dear Andy:
>
>> So there is no short time for this issue, am I correct?
>
> Not clear yet, let's see how it goes today.

OK I discarded all the X-based stuff and started fresh from the working
72Hz portrait mode and the Glamo PDF to find out what I can change as if
I was doing it from scratch.

If I simply enable the bits to 90 degree rotate the pixels in the Glamo,
the glamo fails to produce correct video frames.  It fails in an
interesting but persistent way.  The first 30 - 40 "landscape horizontal
lines" -- they are not video horizontal lines, they are vertical columns
in the video -- are correct.

After these good "landscape horizontal lines", we start to see repeat
line buffer data (double height text) and see dynamic white noise.

HSYNC period is also broken in the output video, a few HSYNC per frame
take the correct 72Hz rate of 47.9kHz (these can be the VSYNC blanking
period ones I guess because they have no video data), but most have a
very excessive HSYNC blanking period and occur only at 27kHz rate.  (If
I select -90 degree rotation, the bulk occur at only 20kHz).

Now note we left EVERYTHING ELSE as it was.  I did not change the
requested timing in Glamo or LCM, and despite this is "landscape", it
should be output to the LCM as portrait using the same video timing,
just that the Glamo should have logically gotten the pixels from
different places to form the portrait lines from rotated data.  Instead
we get broken video timing.

Additionally:

 - When I write the Glamo SD interface when selecting this 24.5MHz PCLK
landscape mode, it is very very slow to umount, it means access to the
Glamo RAM for the CPU is very delayed

 - If I force-divide the PCLK to 16MHz, it is much more stable, although
there are some "landscape vertical" line artefacts at a lower rate than
before.  (When we force-divide to 12MHz, we get the flickery but
artefact-free landscape video that olv and Dodji provided already.)


Putting all this together it's pretty clear that:

 - rotated modes ignore the timings that operated fine in non-rotated
mode, and perform their own weird and wonderful slower video rates, 42Hz
/ 27kHz for +90 degree rotation instead of 72Hz / 47.9kHz.

 - separately, Glamo can't actually do 640 x 480 x 16bpp rotated video
at a good refresh rate anyway because the internal memory subsystem
can't cope

I changed various memory settings in the glamo after finding this out to
do with burst mode in the internal ram, and arbitration lengths, but it
didn't make any change for the better (we need burst mode to even do
portrait).

So the conclusion is the Glamo apparently isn't capable to deliver the
hardware rotation action at 72Hz and we need to either use what we have
with flicker, or so it in software.  I think I would probably accept the
flicker, since scrolling for example might be badly affected otherwise.

The only hope is that S-Media might tell us our memory subsystem is set
up badly, but I hazard a guess their response would actually be: "we
don't recommend our customers do rotated video at 640 x 480 x 16bpp 72Hz".

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH4CsOOjLpvpq7dMoRAvg8AJ9sRx/ZO7QpnTjcnK4PB9ujOHioCgCfQ5/y
JYYBeeUHwA93YSdwArD9aMw=
=b2AY
-----END PGP SIGNATURE-----