logo from uboot to kernel patch on imx6s; display flicker/red during boot

[r_veens]

Hello we have implemented the Bootlogo from uboot to kernel patch for our BSP and came across an issue on the i.mx6 Solo only (no issue on imx6 quad).

We have implemented the following patches on kernel 4.9.11-1.0.0:

L4.1.15_GA1.2.0_uboot_logo_keep_patch_2017-01-06.zip 

When we applied this the display stayed black during boot in Linux. For our 7" display, the display shows a test image (red, blue, green, some patterns..) because the display had a clock but no data.

We were able to get the logo to display during Linux boot by making some changes, discussed below.

However, an issue remains; the display is shorty black during boot of Linux, or red in the case in one of the 7" display.

The changes we made are the following:

1. set the bypass_reset property to 1 in the &ipu1 group in the dts.
2. set late_init option to 1 in the &mxcfb1 group in the dts.
3. Turn on the CONFIG_MX6_CLK_FOR_BOOTUI_TRANS, CONFIG_MX6_CLK_FOR_BOOTUI_TRANS_LVDS_IPU1_DI0 options.
4. call the mxcfb_set_par function at the end of the mxcfb_register function in the drivers/video/fbdev/mxc/mxc_ipuv3_fb.c driver. This is done like so:

   fbi->var.activate = (fbi->var.activate & ~FB_ACTIVATE_MASK) | FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
   mxcfb_set_par(fbi);

Please see the attached video for an impression (issue: display turns red for a short while, even though we call mxcfb_set_par).

We made some measurements on the scope and discovered a few things.

Here we put on the scope a gpio (blue), the display clock (purple), a data signal (yellow) and the display ready (green). We used a white splash screen (only 0xFF color). These signals are not lvds but after an lvds->rgb conversion chip. However this should not matter.
The gpio goes down in uboot, and up after mxcfb_set_par is called in the driver (discussed before).

We note that the display ready signal is not there, from somewhere during the boot of Linux until the call to mxcfb_set_par (no green block signal):

When we zoom in on the part just at mxcfb_set_par (gpio up) we see that the clock is interrupted for a bit. After some testing we found that this is due to mxcfb_set_par. (if we do not add mxfb_set_par this does not happen, but display is always black or in test mode)

We already spent quite a while debugging this problem. Any possible solution or information on what it could be would be greatly appreciated.

What we expect that happens is that some driver still resets some part of the video (ipu, ldb or framebuffer). This would explain why the display clock signal (green line) is down only in Linux, while it was up in UBoot.

Why is the mxcfb_set_par function required on the imx6 solo to make this patch work, and not on the imx6 quad?

Which drivers and what code is responsible for resetting the video hardware? Where to begin to investigate this?

[r_veens]

Thank you for the tip Qiang Li - Mpu Se, it turned out to be a very good method to debug.

I found out that the problem is the "init_ipu_clk" function in drivers/clk/imx/clk-imx6q.c.

When i disabled the call to this function, the problem is solved.

In the code errata ERR010579 is mentioned, but i cannot find this in 

https://www.nxp.com/docs/en/errata/IMX6SDLCE.pdf

Am i perhaps looking in the wrong document? 

I am trying to figure out if i can safely remove this code, and if the issue applies to me.

The IPU already has been initialized i presume, in u-boot.

P.S. The following commit seems to add the init_ipu_clk function:

commit 6069b329bfa8c31be54f38ea9b99449165644884
Author: Bai Ping <ping.bai@nxp.com>
Date: Tue Dec 13 13:20:01 2016 +0800

MLK-13507 ARM: imx: workaround of ERR010579 for ipu on imx6dl

Workaround for ERR010579
When switching the clock source of IPU clock root in CCM, even setting
CCGR3[CG0]=0x0 to gate off clock before switching, IPU may hang due to
no IPU clock from CCM. The root cause is an integration bug in SOC level,
setting CCGR3[CG0]=0x0 can NOT gate off the clock after IPU clock source MUX.

The IPU clock source MUX is glitchg MUX, that means the clock glitch during
clock switch is unavoidable, which will cause the divider after it stop work
and no clock output. In order to avoid the clock glitch, we must obey below
procedures if clock source switch is needed:

1. gate off the CG after MUX
2. switch clock source
3. gate on the CG after MUX

On the other hand, the EN of the CG between MUX and divider is a feedback
logic(OR result) from several LPCG cells in SOC top, but for IPU clock, one
LPCG is forced to open forever, then the feedback OR result is always high,
it causes the CG can NOT be gated off even the CCGR3[CG0] is set to 0x0.

For detailed workaround steps, please refer to the errata document.

Tested-by: Ying Liu <victor.liu@nxp.com>
Signed-off-by: Bai Ping <ping.bai@nxp.com>

[qiang_li-mpu_se]

From my point, only the first time boot up, you can skip that ipu clock code, because Uboot had alreay initialized it. But for suspend/resume case, that code is needed.

In another words, you need make sure, blank and unblank the display, the display should be off and on successfully.

[qiang_li-mpu_se]

You can enable one core to boot up and add "while(1);" dead loop step by step to identify which code caused the display signal stop, then you can fix the code issue.

The target for the solution, avoid kernel to re-set the display. 

[diegoadrian]

Hello,

Unfortunately, we are no longer supporting this patch for the newer Linux versions and there is no future support. I apologize for the inconveniences this could give you.

Best regards,

Diego.