From: Ian Campbell <ijc+uboot@hellion.org.uk>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] sunxi: video: Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer
Date: Tue, 03 Feb 2015 13:20:03 +0000 [thread overview]
Message-ID: <1422969603.9323.72.camel@hellion.org.uk> (raw)
In-Reply-To: <1422903473-3822-1-git-send-email-hdegoede@redhat.com>
On Mon, 2015-02-02 at 19:57 +0100, Hans de Goede wrote:
> @@ -1237,6 +1243,20 @@ int sunxi_simplefb_setup(void *blob)
> return 0; /* Keep older kernels working */
> }
>
> + /*
> + * Do not report the framebuffer as free RAM to Linux, note we cannot
> + * use fdt_add_mem_rsv() here, because then it is still seen as RAM,
> + * and Linux refuses to iomap RAM on ARM, see:
> + * linux/arch/arm/mm/ioremap.c around line 301.
A little bit Linux centric ;-)
I'd suggest s/Linux/OS for the first one and s/and Linux refuses/for
example Linux refuses/.
> + */
> + start = gd->bd->bi_dram[0].start;
> + size = gd->bd->bi_dram[0].size - CONFIG_SUNXI_MAX_FB_SIZE;
> + ret = fdt_fixup_memory_banks(blob, &start, &size, 1);
I suppose this is currently safe when put up against arch_fixup_fdt(),
but it might be a bit fragile against future changes?
I'm not sure what else we can do though, directly adjusting
gd->bd->bi_dram[0].size seems iffy.
Perhaps a hook called from arch_fixup_fdt which is passed the arrays
which are about to be passed to fdt_fixup_memory_banks so it can adjust
them?
next prev parent reply other threads:[~2015-02-03 13:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 18:57 [U-Boot] [PATCH 1/2] sunxi: video: Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer Hans de Goede
2015-02-02 18:57 ` [U-Boot] [PATCH 2/2] sunxi: video: Dynamically reserve framebuffer memory Hans de Goede
2015-02-03 13:20 ` Ian Campbell
2015-02-03 13:20 ` Ian Campbell [this message]
2015-02-03 17:59 ` [U-Boot] [PATCH 1/2] sunxi: video: Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer Hans de Goede
2015-02-04 8:38 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1422969603.9323.72.camel@hellion.org.uk \
--to=ijc+uboot@hellion.org.uk \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.