i.MX8MQ DCSS color issue

[gary_bisson]

Hi,

Here are some details about a color issue seen on i.MX8MQ when using the DCSS. This issue can only be seen on displays using DCSS (HDMI & MIPI), but everything is ok when using MIPI with LCDIF.

The Setup

- i.MX8MQ NXP EVK platform

  -> also tested on Boundary Devices Nitrogen8M, same results

- Linux Yocto 4.9.88_2.0.0 GA pre-built image from NXP

  -> also tested latest 4.9.123 for i.MX 8MMini GA release hoping for DCSS improvement but the issue is still seen

  -> also tested on Android O8.1.0 for i.MX 8MQuad GA

- Display can be HDMI monitor or MIPI display, as long as it is using DCSS

The Issue

The colors are darker than expected, it is like an alpha layer is added on top the image to be displayed.

Comparing MIPI display colors switching between DCSS and LCDIF setup makes it obvious.

Another approach to compare the colors is to use GStreamer on Linux and switch between waylandsink (GPU composition, DCSS channel 1, global alpha set to 255) and kmssink (no GPU involve, DCSS channel 2 no alpha).

See attached pictures although they don't do the issue justice as it is even more obvious in real life.

How to reproduce

On Linux, as mentioned above, the easiest is to use GStreamer and compare the output when using kmssink vs. waylandsink.

Below are the commands used to generate the pictures attached.

gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080" ! kmssink
gst-launch-1.0 videotestsrc ! "video/x-raw,width=1920,height=1080" ! waylandsink
gst-launch-1.0 videotestsrc pattern=red ! "video/x-raw,width=1920,height=1080" ! kmssink
gst-launch-1.0 videotestsrc pattern=red ! "video/x-raw,width=1920,height=1080" ! waylandsink
gst-launch-1.0 videotestsrc pattern=green ! "video/x-raw,width=1920,height=1080" ! kmssink
gst-launch-1.0 videotestsrc pattern=green ! "video/x-raw,width=1920,height=1080" ! waylandsink‍‍‍‍‍‍

On Android however, since all the composition is done through the GPU, everything goes out on DCSS channel 1 and therefore it always looks dark. The only way to compare is to use MIPI output and switch between DCSS and LCDIF.

Debugging the issue

Since it seems to be alpha related, some debugging was done to understand the DCSS DTG setup from the Linux driver.

Reading the DTG Timing Controller Control Register (TC_CONTROL_STATUS, 0x32E20000), it seems that:

-  by default the driver uses global alpha setting set to 255 and the pixel format is DRM_FORMAT_XRGB8888:
0xff00518c

- changing the TC_DEFAULT_OVERLAY_ALPHA to a value lower than 255 makes the colors even darker (as alpha component is added, that is normal behavior):

0x8000518c = much darker colors

0x0000518c = black screen

(note that Android uses DRM_FORMAT_ABGR8888 pix format but still uses global alpha, tried using per-pixel alpha but it gave the same result)

The above values confirm that the channel 2 & 3 are disabled in a normal setup (just running Weston).

When using kmssink, the driver does the following:

TC_CONTROL_STATUS = 0xff00518c
1- enables channel 2 (DRM_FORMAT_NV12)
2- sets alpha for channel 1 (DRM_FORMAT_XRGB8888) to 0 (basically black plane)
3- disables channel 1
TC_CONTROL_STATUS = 0x0000518a

(stays like this until the pipeline is done or cancelled)
4- sets alpha for channel 1 (DRM_FORMAT_XRGB8888) to 255
5- enables channel 1
6- disables channel 2
TC_CONTROL_STATUS = 0xff00518c

So it seems that as soon as DCSS channel 1 is enabled the colors are darker, maybe another setting needs to be set in order to completely remove the alpha (or bypass the blender).

At this point, we need assistance from NXP DCSS experts as this issue is blocking for many customers.

Regards,

Gary

[sotero]

Hi,

I have the same problem. I think it's related with the values of the HDR10 DCSS module (drivers/gpu/imx/dcss/dcss-hdr10-tables.h) . Playing with these values I can get normal colors but then the alpha composition doesn't work fine.

Regards,

Santiago Otero

[gary_bisson]

Hi,

Yes we came to the same conclusion that the issue comes from the HDR10 tables.

Hopefully NXP will update the values so that colors aren't darken when this is enabled.

Regards,

Gary

[rogerio_silva]

Hi Gary,

I reproduced the problem and we're investigating now.

Best regards,

Rogerio

[gary_bisson]

Hi Rogerio,

Any update on this? Is the problem also happening with your latest 4.14 kernel?

linux-imx - i.MX Linux kernel 

Regards,

Gary

[rogerio_silva]

Hi Gary,

I didn't test with 4.14. Our SW team is still working on this issue. 

Best regards,

Rogerio

[rogerio_silva · Accepted solution]

Hi gary_bisson‌,

Could you please try the attached patch?

It applies on branch 4.14.

Best regards,

Rogerio

[gary_bisson]

Hi Rogerio,

Thanks, I confirm this fixes the brightness for some kernel branches. I tested on kernel imx_4.9.123_imx8mm_ga as I haven't ported Nitrogen8M to 4.14 yet. But the patch applies fine there too.

However, what about older kernel branches, such as the one for "Android O8.1.0 for i.MX 8MQuad GA" release?

We have customers shipping with that version with immediate need for a fix. Can you advice on patches to be backported for this table to work?

I tried applying this patch before the fix hoping it would be sufficient:

f1be2b26669c MLK-17703-1: drm: imx: dcss: update HDR10 tables

Doing so the fix applies fine on imx_4.9.88_2.0.0_ga and imx_4.9.51_imx8m_ga but then the colors are all messed up.

Regards,

Gary

[gary_bisson]

Hi,

Nevermind I got it to work on other branches too. Thanks a ton!

Regards,

Gary

[rogerio_silva]

Thanks Gary!

Best regards,

Rogerio

[karina_valencia]

From Gary.

DCSS is only available on 8M,

[karina_valencia]

rogeriopimentel‌, can you help to review this thread?

[rogerio_silva]

Yes, I'll check.