iMX53 Android BSP

[bfac]

Hello,

Our customer is using our official Android 2.3 BSP for iMX53QSB provided by Adeneo.

They are porting this BSP to their hardware, the work is almost done, but there are some issues on the video playback, it seems the framebuffer overlay is not working as expected.

- They start video reproduction - works fine

- At the end of the playback, the screen turns dark and the system seems to Freeze for the user.

- Doing tests, we found out that running the command echo 0 > /sys/class/graphics/fbX/blank in order to unblank the screen works fine.

So it looks like some driver is forcing a blank on the frame buffer after playback and no other driver unblanks it.

We did this exact same test with the QSB board, and the issue does not happen, it must be something on the porting.

The display in use is connected on the DI1 interface (not the LVDS or TVE).

Do you have an idea how to solve this?

I attach the code that was ported, note that the video_mode "QUANTA" was created for the new board.

Thanks!

Bruno

Original Attachment has been moved to: ldb.c.zip

Original Attachment has been moved to: mxcfb_quanta.c.zip

Original Attachment has been moved to: mx53_indash.c.zip

Original Attachment has been moved to: mx53_indash_android.h.zip

[qiang_li-mpu_se]

Can you attach the whole kernel boot log? After video playback, was the function lcd_poweroff() in mxcfb_quanta.c called? How about the backlight?

How do the customer playback the video, Gallery?

[bfac]

( Answer Rev2: forgot to attach files on Rev 1, I edited the answer with them).

1) Logs: Find Both attached.

Sure.

1) Logs: Find Both attached.

2) We noticed mxcfb_quanta.c is being compiled but never runs. It looks the attached file mxc_ipuv3_fb.c is being called instear.

Putting logs on function mxcfb_blank() on mxc_ipuv3_fb.c, we got the following:

[   87.776441] pmem: request for physical address of pmem region from process 2644.
[   87.907595] video4linux video16: Bypassing IC
[   87.912172] mxc_ipu mxc_ipu: Channel already disabled 10
[   87.912182] mxc_ipu mxc_ipu: Channel already uninitialized 10
[   87.947405] mxc_sdc_fb mxc_sdc_fb.2: unblanking framebuffer (here we have just started the playback)
[   87.947415] mxc_ipu mxc_ipu: Channel already disabled 10
[   87.947422] mxc_ipu mxc_ipu: Channel already uninitialized 10
[   92.871002] binder: 2184:2356 refcount change on invalid ref 9
[   92.952361] mxc_sdc_fb mxc_sdc_fb.2: blanking framebuffer (here playback is finished)
[   93.720394] binder: 2184:2650 refcount change on invalid ref 9
[   93.726261] binder: 2184:2650 refcount change on invalid ref 9
[   93.740314] binder: transaction release 5021 bad handle 9

The videos are reproduced using an overlay, for which we believe are created 3 frame buffers. Note the fb2 is getting unblanked then blanked, what is OK. The problem seems to be that the primary fb0 is never unblanked back.

What we cannot understand too, is why doing an unblank on any of the fbs, makes the fb0 to work back again.

3) Backlight is always on.

4) We are using Gallery 3D to reproduce the videos.

Thanks and BR,

Bruno

[qiang_li-mpu_se]

Hi Bruno, I think it should be a blank code issue, for overlay fb2, ipu_uninit_sync_panel() should not be called. This was fixed in iMX6 BSP.

The customer can apply the attached patch to fix this issue.

[bfac]

Hello Li, thanks for your answer and patch.

Unfortunately, customer tried the patch, but had no success, the behavior is exactly the same, the log is the same.

Thanks!

Bruno

[qiang_li-mpu_se]

Hi Bruno, is the issue fixed with that patch?

[qiang_li-mpu_se]

Hi Bruno, can you let the customer add the followed printk code in function mxcfb_blank():

case FB_BLANK_NORMAL:

        dev_info(info->device, "blanking framebuffer\n");

  ipu_disable_channel(mxc_fbi->ipu_ch, true);

  printk("mxc_fbi->ipu_di = %d.\r\n", mxc_fbi->ipu_di);

  if (mxc_fbi->ipu_di >= 0)

   ipu_uninit_sync_panel(mxc_fbi->ipu_di);

  ipu_uninit_channel(mxc_fbi->ipu_ch);

  break;

From the log "mxc_sdc_fb mxc_sdc_fb.2: blanking framebuffer ..", that means the blank only happens on fb2, the overlay, after applied patch, the fb2 blank will only disable the fb2 IDMAC, so it will not affect the fb0. I just want to make sure the patch code had been compiled into their kernel.

[bfac]

Hello Li, thanks for your reply.

Customer was on FTF, reason for the delay.

The patch didnt solve the issue, but he applied the printk you asked above, and the result is:

[   41.097031] pmem: request for physical address of pmem region from process 2623.
[   41.238876] video4linux video16: Bypassing IC
[   41.243271] mxc_ipu mxc_ipu: Channel already disabled 10
[   41.243282] mxc_ipu mxc_ipu: Channel already uninitialized 10
[   41.281106] mxc_sdc_fb mxc_sdc_fb.2: unblanking framebuffer
[   41.281115] mxc_ipu mxc_ipu: Channel already disabled 10
[   41.281122] mxc_ipu mxc_ipu: Channel already uninitialized 10
[   46.216654] binder: 2194:2251 refcount change on invalid ref 7
[   46.297578] mxc_sdc_fb mxc_sdc_fb.2: blanking framebuffer
[   46.334605] mxc_sdc_fb mxc_sdc_fb.2: mxc_fbi->ipu_di = -1.

Does that give you a better idea on what is happening?

Thanks!

Bruno

[qiang_li-mpu_se]

If so, I think the information is not enough to identify the issue. I think the customer should identiy which code in blanking fb2 caused fb0 no display. And they also need identify it is black screen output or no display output (No LCD pixel clock)?

[qiang_li-mpu_se]

When the issue happens, I think the customer can dump the IPU registers and add debug message to check IDMAC enable/disable (ipu_disable_channel() and ipu_enable_channel() in ipu_common.c).

[gruger]

Dear Qiang Li,

Attached you will find the log files with information you requested. I have dumped IPU registers before and after blanking and unblanking the framebuffers. Please, refer to the attached code for details.

[qiang_li-mpu_se]

And since the customer are using DI1 for display, I think they should also check the lcd driver code, such as file "kernel_imx\drivers\video\mxc\mxcfb_claa_wvga.c", function lcd_fb_event()

if (strcmp(event->info->fix.id, "DISP3 BG") &&

     strcmp(event->info->fix.id, "mxc_elcdif_fb"))

  return 0;

should be:

if (strcmp(event->info->fix.id, "DISP3 BG - DI1") &&

     strcmp(event->info->fix.id, "mxc_elcdif_fb"))

  return 0;

[qiang_li-mpu_se]

After video playback, can you check the backlight power? Is it caused by backlight turned off?

Maybe you can add debug message in kernel_imx\drivers\video\backlight\pwm_bl.c.

I think when blank happens, the backlight driver will also receive this event, and if the backlight driver will not identify the display, just turn off the backlight after received the event, there will be the issue.

[gruger]

Dear Qiang Li,

Attached is the stack trace when backlight is turned off after video stops playing. Hopefully it will give us a clue on where to look for the real problem:

We can see from this stack trace that all starts with the STREAM_OFF IOCTL (called when video stops playing). I believe that whenever a framebuffer is blanked, it generates an event to the backlight driver to turn it off. However, we do not want it for fb2, right? What are your thoughts about it? Where should I look?

[gruger]

Dear Qiang Li,

I think I have got it working now. I had to change a little bit the generic-bl driver. I will run several tests on Monday to see if everything is still working properly. Anyways, I am attaching a patch for that. This patch will make the backlight core driver to not turn backlights off when framebuffers are blanked, which I think is fine for most of applications.

[qiang_li-mpu_se · Accepted solution]

In Freescale default BSP, it used backlight driver "drivers\video\backlight\pwm_bl.c", there is no such issue, that check_fb() code is already there.

By the way, I thnk the followed code should be more better, it will only turn off the backligh when the blank is for BG frame buffer:

static int pwm_backlight_check_fb(struct backlight_device *bl,

     struct fb_info *info)

{

char *id = info->fix.id;

if (!strcmp(id, "DISP3 BG") ||

  !strcmp(id, "DISP3 BG - DI1"))

     return 1;

else

return 0;

}

[gruger]

Dear Qiang Li,

Thank you for your information. I will add that code to the pwm_bl driver for future use. In our current board, we are using a different backlight controller, so that's the reason we needed to use the generic_bl with our custom implementation.

I have used the default pwm_bl driver from Freescale BSP as a reference code for future generic implementations, as it works the best in this case. Thank you very much for your time.

So far, so good: I think the issue is solved. Thanks a lot!

Mauricio

[gruger]

Dear Qiang Li,

I think you have got the problem! The backlight is turning off when blanking fb2! Now, we need to fix it.. If fb2 is being blanked, then backlight should not be changed. Where should I modify the code to solve it?

See attached logs for reference.

[gruger]

Dear Qiang Li,

Do you have any idea where should I look for this in the code, so I can put some logs and provide you additional information?

[karina_valencia]

Deactivated user can you  help to attend this case?

[karina_valencia]

Qiang_FSL can you attend this case?