So, it was several days ago problem, and now it solved, with a little dirty hack inspired from, and commanded by a nice buddy :). Firstly, the problem seems to be, flickering issues which is also happened with Armadillo. Once, i saw and already get the patch related with mxcfb.c. Well, seems to be something silly for me. I know then, the writer of this patch must be see into new version of mxcfb.c released by freescale in their new kernel version.

Deeper analyze from them, the API for this two version of mxcfb.c is slighly the same. Means, there is no specific change in the part of the kernel used by mxcfb. Unfortunately, my kernel version is already 2.6.22.6 and already patched by freescale. Thanks to Phytec who points me in the right place, which is flickered screen. Nothing to do, then.

So, my boss take a print of this file, mxcfb.c, then told me to give a silly printk in every single function of mxcfb.c. I did it, and surprised!! there was a function, calling mxcfb_set_par repeatedly, and i learn from android zaurus, that is FBIOPUT_VSCREENINFO call mxcfb_set_par all the time. Again, Brilliant service point me in a right place. So, my buddy told me, let force kernel not to put anything on the screen, just comment out some lines and let see what will we get ?

we decide to comment out lines in fbmem.c :

case FBIOPUT_VSCREENINFO: /* printk("FBIOPUT_VSCREENINFO \n"); editP
if (copy_from_user(&var, argp, sizeof(var)))
return -EFAULT; acquire_console_sem();
info->flags |= FBINFO_MISC_USEREVENT;
i = fb_set_var(info, &var);
info->flags &= ~FBINFO_MISC_USEREVENT;
release_console_sem();
if (i) return i;
if (copy_to_user(argp, &var, sizeof(var)))
return -EFAULT;*/ return 0;

Then, we got smoothest screen for the first time. So, investigation still continue to FBIOPAN_DISPLAY, this is only my assumption firstly. mxcfb.c has it’s own pan_display function, and i saw in the fbmem.c, there’s kernel module loading , line 738 in my copy:

#ifdef CONFIG_KMOD static void try_to_load(int fb) { request_module("fb%d", fb); } #endif /* CONFIG_KMOD */

So,

request_module("fb%d", fb);

is subjected to mxcfb which is framebuffer driver. Eventually, kernel module loaded before FBIO function. My assumption, i did not investigate it deeper, there must be mxcfb runs before FBIO function. Let’s say, mxcfb_pan_display() runs first, and IPU channel initialized, then i can see something on the screen, while, FBIOPAN_DISPLAY also try to initialize the channel and exactly the device. With the same function and unsynchronized time based function will cause hard flicker on the screen.

Partially, device related, are processed by mxcfb.c and who is responsible with this ? compared with vanilla kernel (2.6.22.6), fbmem.c

  switch(cmd) {
        case FBIOGET_VSCREENINFO:
        case FBIOPUT_VSCREENINFO:
        case FBIOPAN_DISPLAY:
        case FBIOGET_CON2FBMAP:
        case FBIOPUT_CON2FBMAP:
                arg = (unsigned long) compat_ptr(arg);
        case FBIOBLANK:
                ret = fb_ioctl(inode, file, cmd, arg);
                break;

        case FBIOGET_FSCREENINFO:
                ret = fb_get_fscreeninfo(inode, file, cmd, arg);
                break;

        case FBIOGETCMAP:
        case FBIOPUTCMAP:
                ret = fb_getput_cmap(inode, file, cmd, arg);
                break;

        default:
                if (fb->fb_compat_ioctl)
                        ret = fb->fb_compat_ioctl(info, cmd, arg);
                break;
        }

So, that’s all.