Hi Michael, 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 On Tuesday, March 8, 2016 at 6:33:00 PM UTC+1, Radek Dostál wrote: > > Hi Michael, > > we had very similar issue, which we encountered when updating to gstreamer > 1.6. Using git bisect we were able to find a root cause and prepare simple > test program, which reliably reproduces the issue: > > #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], 0, size); > } > > free(memblock); > > return 0; > } > > starting this program will cause crazy flickering, ... > > We were able to reproduce the issue with > > 1) debian originally provided on beaglebone using memtest utility for > carlos. Kernel version was: > > Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version > 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 > > 2) latest version of debian from beaglebone website Kernel version was: > > Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc version > 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 > > so it seems to be existing for ages. > > Did you in the mean time managed to find a solution for your problem? > > Thanks, > Radek > > On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg wrote: >> >> Hi there, >> >> >> i was able to get my 10.1 custom Display to work with the RGB Pins on the >> beaglebone black. >> >> I am using the latest Debian Jessie image from beagleboard.org and the >> X11 Desktop has the right colors and the right size. >> >> So i assume that the Timings from my display are correct. >> >> >> panel { >> >> status = "okay"; >> >> compatible = "ti,tilcdc,panel"; >> >> pinctrl-names = "default"; >> >> pinctrl-0 = <&bb_lcd_lcd_pins>; >> >> panel-info { >> >> ac-bias = <255>; >> >> ac-bias-intrpt = <0>; >> >> dma-burst-sz = <16>; >> >> bpp = <32>; >> >> fdd = <0x80>; >> >> tft-alt-mode = <0>; >> >> stn-565-mode = <0>; >> >> mono-8bit-mode = <0>; >> >> sync-edge = <0>; >> >> sync-ctrl = <1>; >> >> raster-order = <0>; >> >> fifo-th = <0>; >> >> }; >> >> display-timings { >> >> native-mode = <&timing0>; >> >> timing0: 1280x800 { >> >> clock-frequency = >> <70000000>; >> >> hactive = <1280>; >> >> vactive = <800>; >> >> hfront-porch = <80>; >> >> hback-porch = <60>; >> >> hsync-len = <20>; >> >> vback-porch = <12>; >> >> vfront-porch = <8>; >> >> vsync-len = <3>; >> >> hsync-active = <0>; >> >> vsync-active = <0>; >> >> }; >> >> }; >> >> }; >> >> >> But when i play a video or when i have many frames on the display i get >> some screen flickers. >> >> >> On the log via UART i see the following: >> >> >> 1- When booting up: of_graph_get_next_endpoint(): no port node found in >> /ocp/lcdc@4830e000 >> >> 2- When video or many frames are displayed: >> >> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO underflow >> >> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost >> >> >> Any idea? >> >> >> Is the DDR flash rate to slow? Or the DMA buffer not big enougth? >> >> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
