We are currently experiencing an issue where the display of our sign is shifted to the right. It seems to occur randomly, with a random number of pixels, for random durations. The shift has been between 4 to 16 pixels. It can be 30s or shorter and up to several hours. Eventually the sign recovers and begins displaying normally. During the issue the video being played back runs normally, it is just shifted off the display.
You can see in the above image that our display is shifted to the right by 9 pixels. Our application uses the DRM to allocate space for drawing on a panel 800x600. It should be drawing at the orgin, not shifted over. Our video signals are connected directly to our FPGA with which we drive LED tiles. We are running 24 bit color. We are currently using the kernel provided with SDK 8 release. This is kernel 3.14.26.
We are running with kernel args drm.debug=14 in hopes that running the elevated output would allow us to see something. So far we have not noted any kernel messages or outputs from the drm debug in the dmesg output during the time that we see the shifted output.
We were able to capture video timings while the display was not shifted
We are also able to capture the video timing while the display was shifted
The following is information describing the two captures:
Here are two bitmaps that capture the video timing signal. The video timings never changed which means it was stable; H front porch, h sync time, h back porch, and other timing was consistently the same between good and bad video offset. On the shifted display capture the first column video data is not in the right spot in respect to horizontal position. It occurs sometime. The good video signal has the data start at same time as the DE transition from low to high. The display offset capture has data start occurring several pixel clocks after DE transition from low to high which it could be 4 clocks or 8 clocks or 12 clocks or etc. Once it occurs may stay offset consistently for few a minutes to several hours and then recover back to the correct position. You can see on the good video capture the data is present right on the DE rising transition which has the red cursor line while the bad one has data several clocks after the red cursor
Signal detail on the bitmap waveform
- D0 – Pixel clock
- D1 – VSYNC
- D2 – HYSNC
- D3 – DE
- D4-D11 – 8 bit red data
Our panel settings are as follows:
panel {
status = "okay";
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
dma-burst-sz = <16>;
bpp = <32>;
fdd = <0x80>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order = <1>;
fifo-th = <0>;
};
display-timings {
native-mode = <&timing0>;
timing0: SVGA-800x600@60Hz {
clock-frequency = <40000000>;
hactive = <800>;
hfront-porch = <40>;
hsync-len = <128>;
hback-porch = <88>;
vactive = <600>;
vfront-porch = <1>;
vsync-len = <4>;
vback-porch = <23>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
timing1: SVGA-800x600@75Hz {
clock-frequency = <49500000>;
hactive = <800>;
hfront-porch = <16>;
hsync-len = <80>;
hback-porch = <160>;
vactive = <600>;
vfront-porch = <1>;
vsync-len = <3>;
vback-porch = <21>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
timing2: SXGA-800x600@85Hz {
clock-frequency = <56250000>;
hactive = <800>;
hfront-porch = <32>;
hsync-len = <64>;
hback-porch = <152>;
vactive = <600>;
vfront-porch = <1>;
vsync-len = <3>;
vback-porch = <27>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
}
Our pin muxxing is accomplished the following:
&am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
0xa0 0x28
0xa4 0x28
0xa8 0x28
0xac 0x28
0xb0 0x28
0xb4 0x28
0xb8 0x28
0xbc 0x28
0xc0 0x28
0xc4 0x28
0xc8 0x28
0xcc 0x28
0xd0 0x28
0xd4 0x28
0xd8 0x28
0xdc 0x28
0x3c 0x01
0x38 0x01
0x34 0x01
0x30 0x01
0x2c 0x01
0x28 0x01
0x24 0x01
0x20 0x01
0xe0 0x28
0xe4 0x08
0xe8 0x08
0xec 0x08
>;
};
The output of cat /proc/cmdline
console=ttyO0,115200n8 psplash=false rootflags=barrier=1,commit=1 consoleblank=0 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
The output of cat /proc/cpuinfo
processor : 0 model name : ARMv7 Processor rev 2 (v7l) Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : Generic AM33XX (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000
The output of fbset -i
mode "800x600"
geometry 800 600 800 1800 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,8/24
endmode
Frame buffer device information:
Name :
Address : 0x9e100000
Size : 5760000
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 1
YPanStep : 1
YWrapStep : 0
LineLength : 3200
Accelerator : No
The output of lsmod
Module Size Used by bufferclass_ti 5396 0 omaplfb 11914 0 musb_dsps 7287 0 musb_hdrc 54294 1 musb_dsps snd_soc_evm 5786 0 pvrsrvkm 178684 2 bufferclass_ti,omaplfb tilcdc 27776 2 omaplfb drm_kms_helper 40603 3 tilcdc snd_soc_davinci_mcasp 12494 2 at24 5006 0 snd_soc_tlv320aic3x 37026 1 lm75 4605 0 gpio_pca953x 9166 8 musb_am335x 1217 0
Powervr.ini settings
[default] WindowSystem=libpvrPVR2D_FRONTWSEGL.so #WindowSystem=libpvrPVR2D_FLIPWSEGL.so
Output of cat /proc/pvr/version
Version SGX_DDK_Linux_CustomerTI sgxddk 1.10@2359475 (release) /home/adaptive-sdc/Graphics_SDK_5_01_01_02/GFX_Linux_KM System Version String: SGX revision = 125
Output of cat /sys/class/graphics/fb0/rotate
0
Output of uname -a
Linux P1900-3-SSC 3.14.26-g07d13c6-dirty #24 Fri May 15 13:23:03 CDT 2015 armv7l GNU/Linux
Thank you in advance for any help you can provide.
Regards,
Matt Minga
