Parallel RGB / LCDIF issue on i.MX 8X

[philippe_schenk]

Hello

We have an issue driving a parallel RGB display on an i.MX 8X SoC. We use our module the Colibri iMX8X to do our tests.
Unfortunately we currently do not have the possibility to try it out on the MEK due to connector incompatiblity. I was also not able to find the Seiko display that is found in device trees.

Q1: Where can I order the Seiko display compatible with i.MX 8X MEK?

Now to the technical questions:
I understand that there are two ways to drive a display on an i.MX 8X. One way making use of the LCDIF driver and one making use of the DPU. We used these device trees as a base to create ours for these two ways:

`imx8qxp-mek-dpu-lcdif.dts`
`imx8qxp-mek-lcdif.dts`

We have the issue, that we cannot use GPU accelerated graphics with a parallel RGB display due to two issues present at each mode of driving the LCD.

Issue with driving the display using the way of `imx8qxp-mek-lcdif.dts`
- As soon as glmark2 is executed or a Qt demo is using the GPU the display output looks like it gets out of sync. Please see the attached video what I mean.

Q2: Can you reproduce this behavior on your side with an i.MX 8X MEK?

Issue with driving the display using the way of `imx8qxp-mek-dpu-lcdif.dts`
- The pixelclock polarity seems to be hardcoded. I was not able to change this setting using display timings.
- I looked in the TRM if I can add support to that in the driver. I believe that this setting would need to be existing in the TCon block inside the DPU. However I was not able to find a bit where I could set this.

Q3: Can I change the pixelclock polarity using the DPU? If yes which setting do I need to set to which registers?

Many thanks in advance for your help
Philippe Schenker

[marcelziswiler]

Unfortunately, many a question in this thread has never really been answered and we would still be very much interested in answers. Thanks!

>> Q1: Where can I order the Seiko display compatible with i.MX 8X MEK?
>>
> For Q1: No answer yet, here, I'll try to get some contact information and will update it here.

We would still be interested in an answer here about the Seiko display you guys are using together with the MEK.

>>>> Q3: Can I change the pixelclock polarity using the DPU? If yes which setting do I need to set to which registers?
>>>>
>>> For Q3: The pixel clock polarity can probably be changed by the PIXINV_INV bit of the POLARITYCTRL register of DPU DisEngCfg unit.
DPU output goes thru Pixel Link. Pixel Link doc mentions HSYNC/VSYNC is active low, Date Enable is active high, but it seems that it doesn’t mention the pixel clock polarity. Please try the PIXINV_INV bit.
>>>
>> Re: Re: Q3: I still use Rev. 0 May 2020 Reference Manual, there I can only find IRQs related to DisEngCfg unit but no POLARITYCTRL. I however found a PolarityCtrl register in TCon that contains a PixInv bit within the DPU (Specifically I changed bit 3 in 0x5618B42C). Flipping this bit just inverts the colors as described.
>> I attached two pictures showing the difference, you can see the wrong pixelclk-polarity on the picture at the edges of the clouds.
>>
> Regarding the reply for Q3, I forwarded your reply and I'll post the feedback here.

> Q4: Does NXP plan to fix this issue on `imx_5.4.70_2.3.0`?

> Q5: Did you meant this bit or is there also a PixInv existing in DisEngCfg somewhere?

[marcelziswiler]

Dear NXP, we are still waiting on an answer here. Thanks!

[robert-modestch]

Hi,

Regarding "Q1: Where can I order the Seiko display compatible with i.MX 8X MEK?": I don't know what to answer here, since the Seiko display that we use are built inside NXP, by a specialized HW team. They just order the panels, directly from Seiko and build the board around it.

Regarding "Q5: Did you meant this bit or is there also a PixInv existing in DisEngCfg somewhere?": the customer is using the correct bit – bit3 of register at 0x5618B42C.

If there are any other questions that are still unclear, just let me know and I will try to clarify them.

Best regards,

Robert

[philippe_schenk]

Hi Robert,

Thanks for coming back. This bit does flip all colors not just the pixel-clock.

root@colibri-imx8x-06760696:~# devmem2 0x5618b42c      
/dev/mem opened.
Memory mapped at address 0xffffaf9ce000.
Read at address  0x5618B42C (0xffffaf9ce42c): 0x00000004
root@colibri-imx8x-06760696:~# devmem2 0x5618b42c w 0xc
/dev/mem opened.
Memory mapped at address 0xffffb04a7000.
Read at address  0x5618B42C (0xffffb04a742c): 0x00000004
Write at address 0x5618B42C (0xffffb04a742c): 0x0000000C, readback 0x0000000C

Please advise us how we can change pixelclock polarity.

Best Regards,
Philippe

[robert-modestch]

Hi,

This is the answer I got from the DPU owner:

"I’ve asked a DPU designer about the possibility for DPU to change the pixel clock polarity.

The answer I’ve got from the designer is that it’s impossible for DPU to change the polarity.

DPU just delivers pixel data for each rising edge of the pixel clock.

Since pixel link cannot change the polarity either, so I don’t think the pixel clock polarity can be changed at all."

So, it seems that all the lines are inverted, but since the DPU picks the pixels on the rising edge, that bit will only invert the pixels.

May I ask why are you trying to invert the pixel clock polarity? Do you have a panel that works only on the falling edge of the pixel clock?

[philippe_schenk · Accepted solution]

Hello,

Thanks for your valuable and very appreciated answer. I will go ahead summarize the answers to the initial question and close this thread.

Q1: Where can I order the Seiko display compatible with i.MX 8X MEK?

I never really received a clear answer on this. But I believe it got obvious that the display used by NXP in device-tree plus the necessary adapter is not directly sold. An adapter has probably to be done by our self and the display can be ordered, if still available, somewhere else. In another thread I got a link to the datasheet of the used display:

https://datasheet.octopart.com/RA169-Seiko-datasheet-142521498.pdf

Q2: Can you reproduce this behavior on your side with an i.MX 8X MEK?

No, it could never be reproduced by NXP.

Q3: Can I change the pixelclock polarity using the DPU? If yes which setting do I need to set to which registers?

No, this got also confirmed by the DPU designer.

[robert-modestch]

Hi Philippe,

For Q1: No answer yet, here, I'll try to get some contact information and will update it here.

For Q2: I ran the glmark2 on my QXP-MEK board with the Seiko LCD and it works as expected. No corrupt image on it, the GL test runs smooth. Now, I would like to know exactly what release of our kernel are you using using? Some time ago, we had no support for vblank in the mxsfb lcdif driver which might cause these sync issues with the GPU. So, updating the kernel might fix this issue. One think to add here, is that I ran the glmark2 on wayland.

For Q3: The pixel clock polarity can probably be changed by the PIXINV_INV bit of the POLARITYCTRL register of DPU DisEngCfg unit.
DPU output goes thru Pixel Link. Pixel Link doc mentions HSYNC/VSYNC is active low, Date Enable is active high, but it seems that it doesn’t mention the pixel clock polarity. Please try the PIXINV_INV bit.

[philippe_schenk]

Hi Robert,

Thank you very much for your reply.

Re: Re: Q2: This is very interesting to hear, I assume you already use `lf-5.10.52-2.1.0`? We do unfortunately still use the kernel `imx_5.4.70_2.3.0`. The update to a newer NXP release is planned for next year only, we have to preferably find a solution on `imx_5.4.70_2.3.0`.

Q4: Does NXP plan to fix this issue on `imx_5.4.70_2.3.0`?

Re: Re: Q3: I still use Rev. 0 May 2020 Reference Manual, there I can only find IRQs related to DisEngCfg unit but no POLARITYCTRL. I however found a PolarityCtrl register in TCon that contains a PixInv bit within the DPU (Specifically I changed bit 3 in 0x5618B42C). Flipping this bit just inverts the colors as described.
I attached two pictures showing the difference, you can see the wrong pixelclk-polarity on the picture at the edges of the clouds.

Q5: Did you meant this bit or is there also a PixInv existing in DisEngCfg somewhere?

Best Regards,
Philippe

[robert-modestch]

Hi Philippe,

Actually, we had some porting issues between 5.4 and 5.10 and the vblank related issue I was talking about was related to 5.10.

Vblank is working in 5.4. I just flashed and sdcard with imx_5.4.70_2.3.0-rc3 and ran the glmark-es2-wayland test and seems to be running fine. I see no display tearing or any other sync issues. Maybe this could be a user-space problem that has been fixed into our release? What version of glmark2 are you running?

Regarding the reply for Q3, I forwarded your reply and I'll post the feedback here.

Below, are the results of my glmark2:

root@imx8qxpc0mek:~# glmark2-es2-wayland
EGL: Warning: No default display support on wayland
=======================================================
glmark2 2017.07
=======================================================
OpenGL Information
GL_VENDOR: Vivante Corporation
GL_RENDERER: Vivante GC7000L
GL_VERSION: OpenGL ES 3.1 V6.4.3.p1.305572
=======================================================
[build] use-vbo=false: FPS: 307 FrameTime: 3.257 ms
[build] use-vbo=true: FPS: 565 FrameTime: 1.770 ms
[texture] texture-filter=nearest: FPS: 388 FrameTime: 2.577 ms
[texture] texture-filter=linear: FPS: 374 FrameTime: 2.674 ms
[texture] texture-filter=mipmap: FPS: 388 FrameTime: 2.577 ms
[shading] shading=gouraud: FPS: 460 FrameTime: 2.174 ms
[shading] shading=blinn-phong-inf: FPS: 472 FrameTime: 2.119 ms
[shading] shading=phong: FPS: 573 FrameTime: 1.745 ms
[shading] shading=cel: FPS: 580 FrameTime: 1.724 ms
[bump] bump-render=high-poly: FPS: 574 FrameTime: 1.742 ms
[bump] bump-render=normals: FPS: 528 FrameTime: 1.894 ms
[bump] bump-render=height: FPS: 564 FrameTime: 1.773 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 476 FrameTime: 2.101 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 186 FrameTime: 5.376 ms
[pulsar] light=false:quads=5:texture=false: FPS: 365 FrameTime: 2.740 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 194 FrameTime: 5.155 ms
[desktop] effect=shadow:windows=4: FPS: 250 FrameTime: 4.000 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 123 FrameTime: 8.130 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 108 FrameTime: 9.259 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 190 FrameTime: 5.263 ms
[ideas] speed=duration: FPS: 160 FrameTime: 6.250 ms
[jellyfish] <default>: FPS: 214 FrameTime: 4.673 ms
[terrain] <default>: FPS: 23 FrameTime: 43.478 ms
[shadow] <default>: FPS: 297 FrameTime: 3.367 ms
[refract] <default>: FPS: 58 FrameTime: 17.241 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 535 FrameTime: 1.869 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 346 FrameTime: 2.890 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 536 FrameTime: 1.866 ms
[function] fragment-complexity=low:fragment-steps=5:
^C FPS: 564 FrameTime: 1.773 ms
=======================================================
glmark2 Score: 358
=======================================================

Best regards,

Robert

[philippe_schenk]

Hi Robert,

We use "glmark2 - 20191226+0+72dabc5d72-r0". However I found some more interesting details.

The behavior happens more often on the DualX variant. On QXP we can reproduce it too, but it is only visible with weston-simple-egl (at least we see there gray horizontal bars blinking up/down on that spinning triangle).

I was able to reproduce the issue on our hardware using the kernel and rootfs from NXP 5.4.70-2.3.0 release the following way:
- Enabling G2D in weston.ini (use-g2d=1)
- Using imx8qxp-mek-lcdif.dtb (I just took the adma-lcdif stuff out of this dts to run on our hardware)
- executing weston-simple-egl (see the video how it looks on my side)

I think you should be able to reproduce the issue that way on your side using weston-simple-egl for the QXP and glmark2 or weston-simple-egl for DualX variants.

Best Regards,
Philippe

[robert-modestch]

Hi Plilippe,

Sorry for this late reply, but I was trying to reproduce this on my side as you suggested, using g2d library, and noticed that, on my board, weston just fails to load the g2d library when I boot with the lcdif.dtb file.

So, I asked the GPU team to step in.

Will reply as soon as we have some useful information to share.

Best regards,

Robert

[robert-modestch]

Hi @philippe_schenk,

When setting the use-g2d flag, this will require the g2d library to have a RENDERER enabled display controller. In our case, only the DPU has the RENDERER capabilities, while LCDIF can only do basic DISPLAY.

In a normal setup, the g2d library would see that there is no display controller that can do rendering and fall back the render operations to the GPU.

In my case, with the use-g2d flag and completely disable the DPU subsystem (since I was testing the lcdif.dtb) the glmark2 is still working. But remember, that the render operations are done in the GPU driver, not in the LCDIF driver.