BUG Beaglebone HDMI output flickers

BUG Beaglebone HDMI output flickers

[Radek Dostál]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Dear All,

Beaglebone black display starts to flicker after updating our userspace 
to GStreamer 1.6 and decoding WMA. We analyzed the change in gstreamer 
and created simple program, which allow us to reproduce the issue 
reliably - see attached.

When attached program mem-test.c is executed with nice as user nobody, 
it is still causing heavy flickering of the BeagleBone HDMI output. You 
can see the example on this 30second video https://db.tt/ZQf4nq9A

Following messages are printed to the kernel log:
[  450.997625] tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO
underfow
[  451.023380] tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO
underfow
[  451.032606] tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO
underfow
[  451.056635] tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO
underfow
[  451.065265] tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO
underfow

What is very interesting only some sizes of memtest are causing flickering:

Sizes 0 to 24: no flickering.
Sizes 25 to 2072: heavy flickering:
Sizes 2073 to 2200: a little bit of flickering:

Any help would be greatly appreciated,
Radek Dostal



[-- Attachment #2: mem-test.c --]
[-- Type: text/x-csrc, Size: 383 bytes --]

#include <string.h>
#include <stdint.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
        int size;
        uint8_t *memblock;

        if (argc < 2)
                return -1;

        size = atoi(argv[1]);

        memblock = malloc(size);

        while (1)
        {
                memset(memblock, 0, size);
        }

        free(memblock);

        return 0;
}

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: BUG Beaglebone HDMI output flickers

[Radek Dostal]

Dear All,

As the post above will be probably often found by google, I will post 
here also a temporary solution colleague of mine found to the flickering 
problem.

devmem2 0x4c000054 w 0x00FFFFF10

It is probably not ideal - there should be a way how to prioritize just 
the LCD transfers (according to the TI wiki), but the values there do 
not work. This fix just ensures that any "too old" command gets executed 
sooner than it would otherwise, maybe that is a good thing anyway.

However, I believe I understand all the various issues we've seen 
(although I could still be wrong - but this at least makes sense):

static image shift
   - here, the DMA for transferring data to LCD fifo is blocked for a 
short period of time once, but then it continues normally. This produces 
the fifo-underflow interrupt once, the data for display are few pixels 
late, but then all works normally so the image is just shifted (although 
not too visible in the photo, the "extra" pixels at top-left corner are 
black, and not white if the image was just wrapped).

full flickering
   - in this case, the memory load is so severe that the DMA is blocked 
too often and can't supply steady stream of data; producing 
fifo-underflow interrupts all over. The image still starts from the 
top-left corner as usual, but then the rest of the "pixel stream" 
contains some extra 0s so the testimage produces diagonal patterns (with 
varying error, hence the flickering).

So these 2 are the same issue, just with different outcome.

The problem is the DDR command prioritization logic in our memory 
controller, the memset() loop manages to starve the DMA data stream. The 
"fix" just tweaks the REG_PR_OLD_COUNT value - now if there is a DDR 
command in the memory controller fifo for too long, it will get executed 
(out of the prioritized ordering).

(I can probably also explain why it +- works with >2k buffers; but there 
I'm not fully sure yet.)

All this is based on this info:
http://processors.wiki.ti.com/index.php/DA8xx_LCDC_Linux_FB_FAQs

Thanks,
Radek
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel