From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeroen Hofstee <jeroen@myspectrum.nl>
Date: Thu, 03 Jan 2013 19:10:42 +0100
Subject: [U-Boot] [RFC]: always relocate u-boot before the framebuffer
In-Reply-To: <20130103104134.A2193200781@gemini.denx.de>
References: <20121229203157.0f50ba5e@black>
	<20121231153353.2d9a5dda@amdc308.digital.local>
	<20121231145425.DB5CF20051B@gemini.denx.de>
	<20130102154854.GC14738@bill-the-cat>
	<20130102201725.DC80A20035D@gemini.denx.de>
	<50E55D24.8000809@myspectrum.nl>
	<20130103104134.A2193200781@gemini.denx.de>
Message-ID: <50E5C9A2.7090904@myspectrum.nl>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi,

On 01/03/2013 11:41 AM, Wolfgang Denk wrote:
> In message <50E55D24.8000809@myspectrum.nl> you wrote:
>> As Wolfgang suggested, maybe I shouldn't point at U-boot but blame
>> linux and get rid of the 2MB alignment. I haven't checked yet, but I
>> don't see why that should not work. So this is resolved for my
>> case (thanks for the suggestion) for now until I meet
>>
>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg80440.html
> Hm...
>
> 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.
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.

Motivation for the 2mb alignment is at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035013.html

Regards,
Jeroen