Here's the relevant thread on linaro-dev mailing list: 1. http://lists.linaro.org/pipermail/linaro-dev/2011-August/006962.html
There could be mis-use of the framebuffer's FBIOPUT_VSCREENINFO as a way to update the screen instead of using FBIOPAN_DISPLAY. The former ioctl could take significant amount of time re-calculating the timing assuming resolution/color depth changes, and re-initializing the controller for a new mode, and that could result in screen blinking. Please check your Android code against this theory. 2. http://lists.linaro.org/pipermail/linaro-dev/2011-August/006965.html > There could be mis-use of the framebuffer's FBIOPUT_VSCREENINFO as a > way to update the screen instead of using FBIOPAN_DISPLAY. That's exactly what Android does in a couple of places, e.g. system/core/init/logo.c, function fb_update() [that one actually calls FBIOPUT_VSCREENINFO _twice_ to update the screen] hardware/libhardware/modules/gralloc/framebuffer.cpp, function fb_post This should be fairly easy to fix, but googling it, I found an explanation from an upstream engineer on why they're doing it that way -- apparently on some graphics drivers, FBIOPAN_DISPLAY does smooth panning, which obviously isn't what you want for a simple screen refresh. I'm definitely going to change it to see whether or not this is the problem (and also to probably get a bit of a performance boost on Panda) - but I wonder what hardware we're going to break with that. Given other pieces of code (e.g. SDL) use FBIOPAN_DISPLAY for screen refreshes, I think using that ioctl should be mostly safe. > The former > ioctl could take significant amount of time re-calculating the timing > assuming resolution/color depth changes, and re-initializing the controller > for a new mode, and that could result in screen blinking. That is consistent with the messages I'm seeing in dmesg output. Maybe (in addition to fixing userland) the driver should be a bit smarter and not reinitialize the controller if it realizes the old and new modes are actually the same, given Android is probably not the only piece of code that uses FBIOPUT_VSCREENINFO, given apparently some fb drivers interpret FBIOPAN_DISPLAY as something different... 3. http://lists.linaro.org/pipermail/linaro-dev/2011-August/006971.html On 27 August 2011 21:45, Bernhard Rosenkranzer <bernhard.rosenkranzer at linaro.org> wrote: > That's exactly what Android does in a couple of places, e.g. > system/core/init/logo.c, function fb_update() [that one actually calls > FBIOPUT_VSCREENINFO _twice_ to update the screen] > hardware/libhardware/modules/gralloc/framebuffer.cpp, function fb_post I just changed it, and it works! We now have a really working display on iMX53 Android. Thanks to everyone who helped! ** Changed in: linaro-android Milestone: None => 11.09 -- You received this bug notification because you are a member of Linaro Release Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/824506 Title: Graphics driver on i.MX53 Android issues Status in Linaro Android: Confirmed Status in Linaro Freescale Landing Team Project: Confirmed Bug description: Booting Android on i.MX53 QSB using your bsp/freescale/linux-linaro- android.git kernel, with a display at a resolution with >= 1024 pixels width, results in endless loops of [...] <7>[ 120.044524] DMFC high resolution has set, will not change <7>[ 120.144532] DMFC high resolution has set, will not change <7>[ 120.224553] DMFC high resolution has set, will not change [...] This error message comes from drivers/mxc/ipu3/ipu_disp.c, _ipu_dmfc_init. _ipu_dmfc_init is called from _ipu_dmfc_set_wait4eot, ipu_probe and ipu_resume. _ipu_dmfc_set_wait4eot is called by ipu_init_channel_buffer (exported through the IPU_INIT_CHANNEL_BUFFER ioctl). There doesn't seem to be a reasonable code path that could hit those 10+ times a second, but I haven't put a lot of time into debugging this yet. In my current builds, I've speeded it up by hiding the warning and avoiding the logging activity. We can now see the right picture, but any screen update (e.g. moving the mouse cursor, or automatic updates when e.g. running 0xbench) causes the screen to blank for a while (and then come back up showing what it should be showing, behaves pretty much like an e-ink display). My current guess is that any screen update causes the driver to re-initialize, causing both the message and the blanking. To manage notifications about this bug go to: https://bugs.launchpad.net/linaro-android/+bug/824506/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~linaro-release Post to : linaro-release@lists.launchpad.net Unsubscribe : https://launchpad.net/~linaro-release More help : https://help.launchpad.net/ListHelp
