Dear Jeroen Hofstee,
In message 50E5C9A2.7090904@myspectrum.nl you wrote:
In any case the code should behave the same in U-Boot and Linux. If we can lift this restriction in Linux, then OK. If not, then the FB allocation in U-Boot (by lcd_setmem()) should result in the same size as allocated by Linux. After all, the allocated size should be a "resasonable" one ;-)
For completeness, removing size = ALIGN(size, SZ_2M); from vram.c in the linux dss driver and passing the correct vram= works fine.
Hm... I'm not sure if this is the right approach, then. If mainline Linux insists on such a 2 MB alignment, we shoud rather teach lcd_setmem() to follow tha rule, too. That should solve the problem as well (and probably more efficiently, especially if other features like pRAM or shared log buffer reserve high memory as well).
Anatolij, what do you think should be done here?
The frame buffer is then at the same physical address and I regain 15MB of memory. So solved as far as I am concerned till proven that it really hurts performance.
I can't grok this, though. I could understand if you say you saved up to 2 MB by lifting the 2 MB alignment requirement - but 15 MB? Please elucidate where this number is coming from.
Best regards,
Wolfgang Denk