Hello Prabhu, On Fri, Nov 17, 2017 at 8:37 PM, Prabhu Sundararaj <[email protected]> wrote: > Hi Otavio, Gary, > We tested only on SABRE boards and it got only 2GB MAX DDR.
Ok, this is a valid point but this does not mean it covers all possible use-cases. >> Using 4.1.15 of_reserved_mem.c works too but that is just a >> workaround, the viv driver should manage that case since Etnaviv does. > Wondering whether this restriction came in 4.9? > > This is not regression from in my point of view. May be we consider this a > requirement and fix it in separate patch. Sorry but it is a regression. The previous GA release works with 4GiB of RAM. The new one does not. > Fixing this and validation would require some time. Gary did figure out the root cause. He found two important information pieces: - A similar issue was seen and fixed on Etnaviv[1]. I guess a similar patch is required for this driver as well. Forcing the cma area to be under 0x90000000 (for imx6qdl) makes the driver work. [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=471070ab - A new patch[2], that is included in 4.9, changes the behavior of it [2] https://github.com/boundarydevices/linux-imx6/commit/e53b50c0cbe392c946807abf7d07615a3c588642 Another important aspect is that the 6.2.3.p0[3] available for i.MX8 adds a new gc_hal_kernel_allocator_reserved_mem.c to address this very issue. [3] http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/commit/drivers/mxc/gpu-viv?id=fe649d5ca8e6088d54eee89825705257f404576d So I think it all provides a good information about the issue. It seems that backporting the gc_hal_kernel_allocator_reserved_mem.c is the best option as it allows for no diverting of Linux kernel official behavior. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
