On Monday 30 April 2007 14:27, Siarhei Siamashka wrote:
> I also tried to use YUV420 on Nokia 770, but it did not work well.
> According to Epson, this format should be supported by hardware. Also there
> is a constant OMAPFB_COLOR_YUV420 defined in omapfb.h in Nokia 770 kernel
> sources. But actually using YUV420 was not very successful. Full screen
> update 800x480 in YUV420 seems to deadlock Nokia 770. Playback of centered
> 640x480 video in YUV420 format was a bit better, at least I could decipher
> what's on the screen. But anyway, it looked like an old broken TV :) Image
> was not fixed but floating up and down, there were mirrors, tearings, some
> color distortion, etc. After video playback finished, the screen remained
> in inconsistent state with a striped garbage displayed on it. Starting
> video playback with YUY2 output fixed it. But anyway, looks like YUV420 is
> not supported properly in the framebuffer driver from the latest OS2006
> kernel. That's bad, it could provide ~30% improvement in video output
> perfrmance for Nokia 770. Maybe upgrading framebuffer driver can fix this
> issue (and add tearsync support).
By doing a quick kernel framebuffer code review, looks like the problem may
reside in the following fragment from hwa742.c:
switch (color_mode) {
...
case OMAPFB_COLOR_YUV420:
bpp = 12;
conv = 0x09;
transl = 0x25;
break;
...
}
...
set_window_regs(x, y, x + w, y + h);
offset = (scr_width * y + x) * bpp / 8;
hwa742.int_ctrl->setup_plane(OMAPFB_PLANE_GFX,
OMAPFB_CHANNEL_OUT_LCD, offset, scr_width, 0, 0, w, h,
color_mode);
hwa742.extif->set_bits_per_cycle(16);
hwa742.int_ctrl->enable_plane(OMAPFB_PLANE_GFX, 1);
hwa742.extif->transfer_area(w, h, request_complete, req);
As far as understand it, this code notifies the graphics chip about what
screen area it is going to update and starts DMA transfer to fill it with
data. But a similar code from 'blizzard.c' also does width correction before
'transfer_area' by doing 'w = (w + 1) * 3 / 4;'. Looks like code from hwa742.c
attempts to transfer more data than the graphics chip expects for YUV420
format. This can explain vertical image drift observed in my previous
experiments (for 640x480 area starting at 0,80), also excess data may
deadlock the graphics chip (for the test with 800x480 area starting at 0,0).
Also the 'offset' may be calculated wrong, see [1] for some bits of
information about YUV420 framebuffer layout on N800. Starting location
should be probably always calculated assuming 16bpp framebuffer layout.
Now I wonder who can be considered upstream for this kernel framebuffer
driver? I guess reporting a bug at maemo bugzilla is pointless as there are
no official updates for Nokia 770 planned. I wonder why this driver is still
getting some updates in newer versions of linux omap kernel and what
hardware is used to verify that it works? Is it still tested on Nokia 770?
1. http://maemo.org/pipermail/maemo-developers/2007-May/010039.html
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
