> > *Because it's not calling malloc() over and over...* >> > > Yeap, you're right it's calling memset() every loop. Not sure why I was > thinking it was calling malloc() every loop. But the point is, it does not > matter what is being called in the loop. any system / API call in the loop, > without some form of a sleep() will eat up a lot of CPU cycles. Again, as > much as the system will allow it to, which is usually in the mid to high > 90%'s . . . >
Yes it's definitely not nice to call memset() in such a tight loop, but the program is just for demonstration purposes. As mentioned at least one gstreamer 1.6 audio decoder plugins will call memset() consecutively fast enough to cause issues with the lcdc dma. And thus screen flicker. So, &variable <- beginning of an array, equivalent to variable[0], but what > is &variable[0] ? A multi dimensional array ? that's not what was defined > . . . to be 100% honest I'm not sure what it does, but the first thing that > comes to mind is "undefined behavior". > I won't go into details, but "&variable" is not the same as "variable[0]". (You might be able construct some special/silly case tho where the content of variable[0] is equivalent to &variable). And "&variable[0]" is equivalent to "variable". The latter might have been more readable in the context of the code, but both version are valid C. Basically you are getting the address of the first element of the memory block, which is the starting address of the memory block itself, which is what memset expects. > On Tue, Mar 8, 2016 at 5:39 PM, <[email protected] <javascript:>> wrote: > >> I'm surprised that code would compile at all without a compiler error. As >>> &variable[0] probably is not what you think it is. >>> >> I see no issue here. Can you elaborate? >> >> >>> Also, for the record, infinitely allocating an arbitrary amount of >>> dynamic memory, in a loop, without any kind of a pause is going to eat up >>> an incredible amount of CPU cycles. As in that code will very likely use as >>> close to 100% CPU as the system will allow it. Which again, is no wonder >>> you're "flickering" . . . >>> >> The code is not allocating anything in a loop. >> >> >>> You lucky your program does not randomly crash for using malloc() on the >>> same dynamic memory over, and over, without using free(), or instead using >>> realloc() . . . >>> >> Because it's not calling malloc() over and over... >> >> >> The issue here is that if you run memset() in a tight loop (which at >> least one gstreamer1.6 audio decoder plugins does), it seems to clog up the >> data bus enough for the DMA to fail. >> >> >> >>> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál <[email protected]> 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. >>>> >>> >>> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
