IMX8MQ - Issue with rendering video on LCD using Vivante GPU

[hiteshviradiya]

Dear NXP community executive,

We have a product based on IMX8MQ. Where in we have 1280x800 LCD connected via MIPI-DSI interface with IMX8MQ. And we have HDMI output interface also present on our product. So we are driving our LCD via eLCDIF block and driving HDMI via DCSS.

We have a usecase of local preview which captures video over MIPI-CSI and display it on LCD with weston compositor using Vivante GPU.

In this usecase, functionality wise we are good but we are seeing horizontal artifacts while high motion in front of camera source connected to MIPI-CSI. We confirm that capture is perfectly fine by dumping YUV data and there are no artifacts in Captured YUV data.

Is there any problem in configuring Vivante GPU ??

Is there any limitation on eLCDIF block ??

Is there any limitation on

Please help

[hiteshviradiya]

Hi jamesbone‌ & other NXP experts,

Any updates on this?

--

Thanks,

Hitesh

[jamesbone]

Hello,

Is there any problem in configuring Vivante GPU ??

Is there any limitation on eLCDIF block ??

ANSWER. I do not think you have any issues or limitations, based on the resolutions that you are handling.  The limitation was imposed because when using DCSS at 4K@60, memory bandwidth was not enough to drive the LCDIF at 1080p. But, driving both at 1080p should be fine.

Maybe the frequency that it is handling the eLCDIF can be the issue of the tearing.

this patch may help.

[PATCH] arm64: dts: imx8mq: increase NOC clock to 800 MHz — ARM, OMAP, Xscale Linux Kernel 

[hiteshviradiya]

Hi jamesbone‌

Thanks for the prompt response !!

In my kernel, I don't have "arch/arm64/boot/dts/freescale/imx8mq.dtsi" file but I checked it further and found in drivers/clk/imx/clk-imx8mq.c with function "imx8mq_clocks_init" following code:

        /* increase NOC clock to achieve best DDR access performance */
        clk_set_rate(clks[IMX8MQ_CLK_NOC], clk_get_rate(clks[IMX8MQ_SYS1_PLL_800M]));

So I believe NOC clock is already set to 800MHz which is the same as what is mentioned in the patch you shared.

One more IMPORTANT observation is below: When I tried rendering captured YUV file using gstreamer on HDMI (which is connected via DCSS) with weston compositor running with fb1(HDMI), I see issue when using glimagesink and don't see issue with kmssink

Artifacts with glimagesink:

gst-launch-1.0 filesrc location=/root/AMcaptured.yuv ! videoparse width=720 height=480 framerate=60/1 format=5 ! glimagesink render-rectangle="<0,0,1280,800>"

Playing good with kmssink:
gst-launch-1.0 filesrc location=/root/AMcaptured.yuv ! videoparse width=720 height=480 framerate=60/1 format=5 ! kmssink render-rectangle="<0,0,1280,800>"

But I can't play kmssink with weston compositor running with fb0(LCD). I am not able to identify if I see artifacts on LCD with kmssink or not.

Sorry to ask but I am less aware of kmssink & glimagesink. So please advise on this if you have any suggestion/inputs.

--

Thanks,

Hitesh

[hiteshviradiya]

Hello NXP team,

Any updates on this issue?

--

Thanks,

Hitesh