0

My embedded ARM device has a 800x480 16 bit Linux framebuffer LCD which needs to be double-buffered manually. At the moment I'm just using memcpy() to write the double buffer to the framebuffer which is awfully slow. A while(1){memcpy(lfb,dbuf)} loop maxes out the CPU at 100% and updates at approx 40 FPS.

The ARM device I'm using, and the Linux kernel does support DMA memory-memory copy, but I'm having trouble working out how I can access this in a userspace program.

It seems linux/dmaengine.h and dma_async_memcpy_buf_to_buf() is what I need to use, but it appears these are only available from within the kernel?

user703016
  • 37,307
  • 8
  • 87
  • 112
thecoder
  • 55
  • 8
  • Why not just update the buffer address for the screen-refresh? Copying is nonsense and DMA will likely not be the solution! Just calculate the transferrate you need - be it DMA or CPU. Btw: you cannot use DMA from user-space. If you think for 5sec, you should find out the reason why. – too honest for this site Sep 09 '15 at 10:47
  • It seems like you are copying data from a double buffer to frame buffer, rather than double buffering the frame buffer? – user3528438 Sep 09 '15 at 12:35
  • 1
    Olaf, thanks for the reply, but there is no need to be condescending. Obviously i have thought about it for more than 5sec, otherwise i wouldn't be asking here. The framebuffer device doesn't have the ability to double-buffer (using the FBIOPAN_DISPLAY IOCTL is not possible) so i have to allocate it on the heap. Unless there is another way? – thecoder Sep 09 '15 at 12:40

2 Answers2

0

The proper way of what you are doing is not to copy memory at all, but just use your embedded display controller feature to read next frame from another mem buffer.

Ensure you SoC has/doesn't have this feature. I'm 80% sure it has.

sqr163
  • 1,074
  • 13
  • 24
  • 1
    Its a Freescale iMX28 which uses the MXS framebuffer driver. Using FBIOPUT_VSCREENINFO to extend the virtual framebuffer to twice the LCD height returns true, but then re-reading FBIOGET_VSCREENINFO shows the virtual area as being back to the orignal LCD height. Using FBIOPAN_DISPLAY always returns an error. So it appears the Kernel MXS FB driver is buggy or incomplete. – thecoder Sep 09 '15 at 19:22
0

this information, from: http://pandorawiki.org/Kernel_interface

may be helpful>

framebuffer interface

Framebuffers can be accessed Linux fbdev interface:

fbdev = open("/dev/fb0", O_RDWR); buffer = mmap(0, 800*480*2, PROT_READ | PROT_WRITE, MAP_SHARED, fbdev, 0);

(this is basic example, no error checks)

the returned pointer can be used to draw on the screen.

Be sure to #include to get access to the FB device ioctl interface, and for access to ioctl itself. double buffering

This can be achieved using FBIOPAN_DISPLAY ioctl system call. For this you need to mmap framebuffer of double size

buffer1 = mmap(0, 800*480*2 * 2, PROT_WRITE, MAP_SHARED, fbdev, 0); buffer2 = (char *)mem + 800*480*2;

Then to display buffer2 you would call:

struct fb_var_screeninfo fbvar; ioctl(fbdev, FBIOGET_VSCREENINFO, &fbvar); fbvar.yoffset = 480; ioctl(fbdev, FBIOPAN_DISPLAY, &fbvar);

going back to buffer1 would be repeating above with fbvar.yoffset = 0. Tripple or quad buffering can be implemented using the same technique.

user3629249
  • 16,402
  • 1
  • 16
  • 17