Hi!
I currently have a board with the TMS320C6A8168 processor. It has a display connected to DVO2 which uses the RGB parallell video out. This board have a strange phenomena where heavy RAM access (such as a lot of calls to memset()) causes the display to glitch and flicker. This seems very strange to me and have caused a lot of confusion. I hope that this is some kind of error in the RAM configuration, or something else that is relativly easy to reconfigure. Does anybody have a clue as to what can cause this problem, or how I can go about troubleshooting this problem.
My setup is as follows:
The processor uses only one RAM bank (bank0) of 512MB. This is configured for non-interleaved access.
from u-boot board file based on u-boot/board/ti/ti8168/evm.c.
478 /* Program the DMM to for non-interleaved configuration */ 479 __raw_writel(0x0, DMM_LISA_MAP__0); 480 __raw_writel(0x0, DMM_LISA_MAP__1);/* ... */ 482 __raw_writel(0x80500100, DMM_LISA_MAP__2); 483 __raw_writel(0xA0500100, DMM_LISA_MAP__3);To communicate with the display a framebuffer is used, and we give the following parameters to the linux kernel (2.6.37-psp04.00.01.13.patch2).
Kernel parameters:console=ttyO2,115200n8 rootwait root=/dev/nfs nfsroot=192.168.0.42:/srv/nfs/rootfs rw mem=176M notifyk.vpssm3_sva=0xBF900000 vram=50M ti8168xfb.vram=1:16M earlyprintk ip=dhcp noinitrd
And the modules are loaded using the following commands
echo 'loading syslink'insmod /ti/syslink.koecho 'loading firmware'/usr/local/bin/firmware_loader 2 /ti/dm816x_hdvpss.xem3 startecho 'loading VPSS'modprobe vpss sbufaddr=0xBFB00000 mode=dvo2:mobill i2c_mode=1echo 'loading ti81xxvo'modprobe ti81xxvo video1_numbuffers=2 video1_bufsize=4147200 video2_numbuffers=2 video2_bufsize=4147200echo 'loading ov3640'modprobe ov3640echo 'loading ti81xxvin'modprobe ti81xxvinecho 'loading ti81xxfb'modprobe ti81xxfb vram=1:16MAs I've said I am a bit lost at this problem, so any input is really appreciated.
/Emil
The display subsystem(vpss) is a real time master trying to access the DDR. While another master(in your case the ARM, since memset is also causing it), is also trying to access it. Ideally the real-time master should have higher priority, and should not lead to any glitches. But since you are using only one bank of DDR memory this cannot be ruled out.
Trying to balance loads by using the other DDR banks may help.
Thanks for the fast response :-)
I tried to set highest priority to the display process (-20) och lowest to the test process (the process that performs memset()) using nice and renice, but the problem persists. I agree, the problem seems to be priority related. There is only one bank on the board, so we can not load balance using another bank.
Is i possible to give the VPSS higher priority than the ARM?
IF the reason for the glitch is like I stated earlier, giving higher priority to display process using nice will not help. The HDVPSS is a hardware, and hence will not be influenced by any software process priortiy. There are some memory interfaces inside the device that will determine which hardware will have priority to the DDR. Since I am not an expert on this particular device I cannot help you with these settings.
What is the operation that you are doing using the ARM. Which is the memory area that you are trying to access. If you are trying to access the display buffers, then these are usually not data-cached on ARM and hence will lead to heavy DDR load. The same kind of accesses on a cached buffer(got using malloc) will lead to much better DDR accesses.
What is the size of your framebuffer(display resolution) ?
These are the stats we get from the application which sets up the DVO as a framebuffer.
Resolution = 480x800Virtual Resolution = 480x800bites per pixel = 24vinfo.red.length= 8, vinfo.green.length= 8, vinfo.blue.length= 8vinfo.transp.length = 0vinfo.transp.offset = 0vinfo.red.length = 8vinfo.red.offset = 16vinfo.green.length = 8vinfo.green.offset = 8vinfo.blue.length = 8vinfo.blue.offset = 0Line length = 1440Physical Address = 88dd2000Buffer Length = 16777216Resolution = 480x800bites per pixel = 24
And the frame buffer is set up using the following code:
file_fb1 = open(device_name/*"/dev/fb0"*/, O_RDWR); if (file_fb1 == -1) { pabort( "failed to open display device\n"); } printf("%s temporary opened\n", device_name); usleep(10000); printf("Configuring linux for the display DVO2 (Physical port VOUT0)\n"); // Turn off display and graphics fp = fopen("/sys/devices/platform/vpss/graphics1/enabled", "w"); fprintf(fp, "0\n"); fclose(fp); usleep(10000); printf("Turn off display and graphics\n"); fp = fopen("/sys/devices/platform/vpss/display1/enabled", "w"); fprintf(fp, "0\n"); fclose(fp); usleep(10000); // Configure the framebuffer1 printf("Configure the framebuffer1\n"); fp = fopen("/sys/class/graphics/fb1/bits_per_pixel", "w"); fprintf(fp, "24\n"); fclose(fp); fp = fopen("/sys/class/graphics/fb1/virtual_size", "w"); fprintf(fp, "480,800\n"); fclose(fp); usleep(10000); // Configure the display1 according to our display printf("Configure the display1 according to our display\n"); fp = fopen("/sys/devices/platform/vpss/display1/clksrc", "w"); fprintf(fp, "dclk\n"); fclose(fp); fp = fopen("/sys/devices/platform/vpss/display1/mode", "w"); fprintf(fp, "mobill\n"); fclose(fp); fp = fopen("/sys/devices/platform/vpss/display1/output", "w"); fprintf(fp, "triplediscrete,rgb888,0/0/1/1\n"); fclose(fp); usleep(1000000); // Configure the graphics1 to be connected to display1 (DVO2 -> VOUT0 port). You must configure the display1 first for this to // Turn on display. Has to be done before /sys/devices/platform/vpss/graphics1/nodes can be changed printf("Turn on display. \n"); fp = fopen("/sys/devices/platform/vpss/display1/enabled", "w"); fprintf(fp, "1\n"); fclose(fp); usleep(10000); // Connect the fb1/graphics1 with display1 fp = fopen("/sys/devices/platform/vpss/graphics1/nodes", "w"); fprintf(fp, "1:dvo2\n"); fclose(fp); usleep(10000); // Turn on graphics fp = fopen("/sys/devices/platform/vpss/graphics1/enabled", "w"); fprintf(fp, "1\n"); fclose(fp); usleep(10000); close(file_fb1);