• Locked Locked
  • Replies 3 replies
  • Subscribers 136 subscribers
  • Views 5583 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

warning when starting MMU on TCC8900

Juuso Takalainen
  • Note: This was originally posted on 10th June 2010 at http://forums.arm.com

    Hi Juuso,

    The Mali hardware has a range of memory it is permitted to write to directly. Typically, this should only cover the device's framebuffer memory region. The range is configured when the Mali driver is built. When the ranges match, the Mali hardware writes output directly to the framebuffer's back buffer, and on eglSwapBuffers() it waits for VSYNC and swaps the front and back buffers. We call this "direct rendering" and this is the expected and best use case from a performance point of view.

    If a Mali binary driver and a Linux kernel become mismatched (e.g. the platform provider moves the framebuffer in the kernel's physical memory map) then the Mali is no longer permitted to write directly to the framebuffer region. In this case, the Mali will drop back to what we call "blitting" where essentially the Mali hardware must render to some 'private' memory it has allocated, and then the CPU must copy (which the kernel memory manager will allow) the rendered buffer to the framebuffer memory region. In this scenario the output will only be single buffered, and eglSwapBuffers() will not wait for VSYNC, so the output may appear faster but less smooth, and will likely suffer from 'tearing' visual artefacts.

    The correct solution to the problem is to ensure the platform provider configures the Mali driver binaries with a suitable memory range which will cover the present Linux kernel's framebuffer memory layout, and update the driver binaries if the kernel memory map changes. What is happening in your case is that the platform provider has somehow got the supplied Mali driver binaries out of sync with their supplied Linux kernel.

    I'm afraid the guide mentioned in the driver message is for Mali silicon licensees - only they are entitled to the ARM Mali Software Integration Guide, which they use to adapt our Mali driver source code to their platform.

    HTH, Pete
  • Note: This was originally posted on 31st October 2011 at http://forums.arm.com

    The correct solution to the problem is to ensure the platform provider  configures the Mali driver binaries with a suitable memory range which  will cover the present Linux kernel's framebuffer memory layout, and  update the driver binaries if the kernel memory map changes. What is  happening in your case is that the platform provider has somehow got the  supplied Mali driver binaries out of sync with their supplied Linux  kernel.


    So it is a problem on the third-party provider's side, and not Mali's, correct?

  • Note: This was originally posted on 1st November 2011 at http://forums.arm.com

    Hi,

    yes - usually the board supplier just needs to rebuild the Mali binary drivers, correctly specifying the memory region the board can use for the framebuffer device. This can move if the kernel is reconfigured as it may change how many peripheral drivers are included - and each driver may be reserving some of the system memory map for its own uses.

    Mali will only direct-render to the framebuffer if the driver has been told it is permitted to write to that memory region.

    HTH, Pete