OMAP DRM when using YUV frames

[Andre Renaud]

Hi,

I'm using libDRM on the OMAP platform, and using the alpha channel of
the ARGB plane to merge in a YUV plane. I'm doing the drmModePageFlip
(for the ARGB) and the drmModeSetPlane (for the YUV) immediately after
I've done a done a drmHandleEvent (with page_flip_handler etc...),
which I thought meant that the page flips should happen immediately
after the vsync, and thus not cause any tearing. However I do get
tearing on the YUV plane.

On a similar vein, every now and then I see the following messages
printed to the console:
[161879.239227] omapdss DISPC error: GO bit not down for channel 1
this corresponds to a brief flicker on the screen where the YUV frame
is replaced with garbage. On the next screen update, the garbage
disappears, so it is only present for 1/60th of a second. However it
is quite noticeable.

Does anyone know how either of these two issues can be mitigated?

Regards,
Andre

[Rob Clark]

On Tue, Oct 9, 2012 at 5:12 PM, Andre Renaud <an...@bluewatersys.com> wrote:
> Hi,
>
> I'm using libDRM on the OMAP platform, and using the alpha channel of
> the ARGB plane to merge in a YUV plane. I'm doing the drmModePageFlip
> (for the ARGB) and the drmModeSetPlane (for the YUV) immediately after
> I've done a done a drmHandleEvent (with page_flip_handler etc...),
> which I thought meant that the page flips should happen immediately
> after the vsync, and thus not cause any tearing. However I do get
> tearing on the YUV plane.

I'd guess the tearing is on the producer side (ie. what is writing
into the buffer). The problem is that if you wait for the page-flip
event, then call drmModeSetPlane(), the scanout address for the
overlay is updated and GO bit set, but the previous frame is still on
screen until the *next* vblank.

The best thing you could do right now is call drmModeSetPlane()
immediately after or before drmModePageFlip(). And then wait for the
page-flip event to know when the overlay buffer can be given back to
the decoder. This is a bit racey, but as long as you aren't getting
close to the vblank before flipping the fb and overlay layer, then it
should roughly work.

The better solution is the atomic-pageflip stuff that I'm working on,
which will let you tell the kernel to update fb and zero or more
overlay layers in a single ioctl to guarantee that they are all
swapped on the same vblank:

https://github.com/robclark/kernel-omap4/commits/drm_nuclear

That is the good news.. the bad news is that it is all based on newer
"vanilla" upstream kernel.. I should have updated RFC patches on 3.6+
sometime this week, I'm shooting to get this merged for 3.8 merge
window since we are already into 3.7 merge window. But this is on
upstream kernel missing gfx and ivahd stuff.. so for short term that
doesn't help you too much unless you want to do a bunch of backporting
or fwd porting..)

> On a similar vein, every now and then I see the following messages
> printed to the console:
> [161879.239227] omapdss DISPC error: GO bit not down for channel 1
> this corresponds to a brief flicker on the screen where the YUV frame
> is replaced with garbage. On the next screen update, the garbage
> disappears, so it is only present for 1/60th of a second. However it
> is quite noticeable.

yeah, current 3.4 based stuff is missing something like:

https://github.com/robclark/kernel-omap4/blob/87a66648760a5f2db0073cb08a09856fb4204bca/drivers/staging/omapdrm/omap_crtc.c#L299

I noticed that issue when working on the atomic-pageflip stuff..
although unfortunately the fix is lumped in w/ all the rest of the
atomic-pageflip stuff which makes it not so easy to cherry-pick. I
think all you should need is the 'if (omap_crtc->irq.registered) goto
out' stuff. If you have trouble backporting that, let me know and
I'll give a try, but might be a few days before I have time.

BR,
-R

[Andre Renaud]

Hi Rob,

>> On a similar vein, every now and then I see the following messages
>> printed to the console:
>> [161879.239227] omapdss DISPC error: GO bit not down for channel 1
>> this corresponds to a brief flicker on the screen where the YUV frame
>> is replaced with garbage. On the next screen update, the garbage
>> disappears, so it is only present for 1/60th of a second. However it
>> is quite noticeable.
>
> yeah, current 3.4 based stuff is missing something like:
>
> https://github.com/robclark/kernel-omap4/blob/87a66648760a5f2db0073cb08a09856fb4204bca/drivers/staging/omapdrm/omap_crtc.c#L299
>
> I noticed that issue when working on the atomic-pageflip stuff..
> although unfortunately the fix is lumped in w/ all the rest of the
> atomic-pageflip stuff which makes it not so easy to cherry-pick. I
> think all you should need is the 'if (omap_crtc->irq.registered) goto
> out' stuff. If you have trouble backporting that, let me know and
> I'll give a try, but might be a few days before I have time.

Thanks for that - adding in that snippet seems to have resolved the issue.

Regards,
Andre

[Rob Clark]

You might want to try the modetest app in libdrm/test

http://cgit.freedesktop.org/mesa/drm/tree/tests/modetest

it is drmModeGetPlaneResources() that should return the # of overlays.

Anyways, if you could run modetest that should correctly dump all the
available resources.

BR,
-R

On Mon, Feb 25, 2013 at 5:53 AM, <leo.arme...@gmail.com> wrote:
> Can anyone clarify me some issues regarding with YUYV video rendering with
> DRM?
>
>
> I am testing omapDRM driver and dumping all info. The problem is that I am
> calling the function drmModeGetPlane and it is returning that I have no free
> planes (it returns 0 count) that can be connected to my CRTC. Why?
>
> Regards,

> --
> You received this message because you are subscribed to the Google Groups
> "pandaboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandaboard+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Rob Clark]

yes.. well, it depends a bit on bootargs/kernel config, but it can
partition GFX/VID1/VID2/VID3 between crtc's and planes.. I think by
default you should have two crtcs and two planes.

What kernel version are you using? Can you add drm.debug=7 to
bootargs and send me all the drm debug traces it dumps out at boot?

BR,
-R

On Mon, Feb 25, 2013 at 12:01 PM, <leo.arme...@gmail.com> wrote:
> sorry I meant VID1, VID2, VID3 of the DSS subsystem...
>
> Regards,
>
> Leo.
>
> El lunes, 25 de febrero de 2013 17:47:29 UTC+1, leo.arme...@gmail.com
> escribió:
>>
>> That is exactly what I was refering to. I run the test and dump all
>> available resources. The problem is that no plane resources are found and
>> that is something that I did not expect. In theory I should have GFX, YUV1,
>> YUV2 and YUV3 corresponding to old framebuffer with omapfb, isn't?
>>
>> Regards,