Dear Jeroen Hofstee,
In message <50e5c9a2.7090...@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
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A Perl script is correct if it's halfway readable and gets the job
done before your boss fires you.
- L. Wall & R. L. Schwartz, _Programming Perl_
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
