-----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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: Dodji Seketeli <[EMAIL PROTECTED]>, matt_hsu <[EMAIL PROTECTED]>, Wolfgang Spraul <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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-----
