[U-Boot] [PATCH 1/2] sunxi: video: Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer
Do not use CONFIG_SYS_MEM_TOP_HIDE for the framebuffer, instead override board_get_usable_ram_top to make sure that u-boot is not relocated into the area where we want to use the framebuffer, and patch the devicetree from sunxi_simplefb_setup() to tell the kernel to not touch the framebuffer.
This makes u-boot properly see the framebuffer as dram, and initalize the level 2 cache for it, fixing the very slow cfb scrolling problem.
As an added bonus this stops us from reserving the framebuffer when simplefb is not used because an older kernel is booted, or hdp is used and no hdmi cable was plugged in, freeing up the memory for kernel use in these cases.
Reported-by: Siarhei Siamashka siarhei.siamashka@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/video/sunxi_display.c | 22 +++++++++++++++++++++- include/configs/sunxi-common.h | 8 +++----- 2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c index f5f24fc..a120e71 100644 --- a/drivers/video/sunxi_display.c +++ b/drivers/video/sunxi_display.c @@ -1060,6 +1060,11 @@ static const char *sunxi_get_mon_desc(enum sunxi_monitor monitor) return NULL; /* never reached */ }
+ulong board_get_usable_ram_top(ulong total_size) +{ + return gd->ram_top - CONFIG_SUNXI_MAX_FB_SIZE; +} + void *video_hw_init(void) { static GraphicDevice *graphic_device = &sunxi_display.graphic_device; @@ -1076,7 +1081,7 @@ void *video_hw_init(void) memset(&sunxi_display, 0, sizeof(struct sunxi_display));
printf("Reserved %dkB of RAM for Framebuffer.\n", - CONFIG_SUNXI_FB_SIZE >> 10); + CONFIG_SUNXI_MAX_FB_SIZE >> 10); gd->fb_base = gd->ram_top;
video_get_ctfb_res_modes(RES_MODE_1024x768, 24, &mode, @@ -1194,6 +1199,7 @@ int sunxi_simplefb_setup(void *blob) { static GraphicDevice *graphic_device = &sunxi_display.graphic_device; int offset, ret; + u64 start, size; const char *pipeline = NULL;
#ifdef CONFIG_MACH_SUN4I @@ -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. + */ + 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); + if (ret) { + eprintf("Cannot setup simplefb: Error reserving memory\n"); + return ret; + } + ret = fdt_setup_simplefb_node(blob, offset, gd->fb_base, graphic_device->winSizeX, graphic_device->winSizeY, graphic_device->winSizeX * graphic_device->gdfBytesPP, diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 3d69861..bf60dcb 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -259,10 +259,10 @@
#ifdef CONFIG_VIDEO /* - * The amount of RAM that is reserved for the FB. This will not show up as - * RAM to the kernel, but will be reclaimed by a KMS driver in future. + * The amount of RAM to keep free at the top of RAM when relocating u-boot, + * to use as framebuffer. This must be a multiple of 4096. */ -#define CONFIG_SUNXI_FB_SIZE (9 << 20) +#define CONFIG_SUNXI_MAX_FB_SIZE (9 << 20)
/* Do we want to initialize a simple FB? */ #define CONFIG_VIDEO_DT_SIMPLEFB @@ -280,8 +280,6 @@ /* stop x86 thinking in cfbconsole from trying to init a pc keyboard */ #define CONFIG_VGA_AS_SINGLE_DEVICE
-#define CONFIG_SYS_MEM_TOP_HIDE ((CONFIG_SUNXI_FB_SIZE + 0xFFF) & ~0xFFF) - /* To be able to hook simplefb into dt */ #ifdef CONFIG_VIDEO_DT_SIMPLEFB #define CONFIG_OF_BOARD_SETUP
Only use CONFIG_SUNXI_MAX_FB_SIZE to reserve memory at the top when relocating u-boot, and calculate the actual amount of memory necessary when setting up the video-mode and use only that, freeing up some additional memory for use by the kernel.
Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/video/sunxi_display.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c index a120e71..b8c8d43 100644 --- a/drivers/video/sunxi_display.c +++ b/drivers/video/sunxi_display.c @@ -46,6 +46,7 @@ struct sunxi_display { GraphicDevice graphic_device; enum sunxi_monitor monitor; unsigned int depth; + unsigned int fb_size; } sunxi_display;
#ifdef CONFIG_VIDEO_HDMI @@ -1080,10 +1081,6 @@ void *video_hw_init(void)
memset(&sunxi_display, 0, sizeof(struct sunxi_display));
- printf("Reserved %dkB of RAM for Framebuffer.\n", - CONFIG_SUNXI_MAX_FB_SIZE >> 10); - gd->fb_base = gd->ram_top; - video_get_ctfb_res_modes(RES_MODE_1024x768, 24, &mode, &sunxi_display.depth, &options); #ifdef CONFIG_VIDEO_HDMI @@ -1174,6 +1171,17 @@ void *video_hw_init(void) mode->yres, sunxi_get_mon_desc(sunxi_display.monitor)); }
+ sunxi_display.fb_size = + (mode->xres * mode->yres * 4 + 0xfff) & ~0xfff; + if (sunxi_display.fb_size > CONFIG_SUNXI_MAX_FB_SIZE) { + printf("Error need %dkB for fb, but only %dkB is reserved\n", + sunxi_display.fb_size >> 10, + CONFIG_SUNXI_MAX_FB_SIZE >> 10); + return NULL; + } + + gd->fb_base = gd->bd->bi_dram[0].start + + gd->bd->bi_dram[0].size - sunxi_display.fb_size; sunxi_engines_init(); sunxi_mode_set(mode, gd->fb_base - CONFIG_SYS_SDRAM_BASE);
@@ -1250,7 +1258,7 @@ int sunxi_simplefb_setup(void *blob) * linux/arch/arm/mm/ioremap.c around line 301. */ start = gd->bd->bi_dram[0].start; - size = gd->bd->bi_dram[0].size - CONFIG_SUNXI_MAX_FB_SIZE; + size = gd->bd->bi_dram[0].size - sunxi_display.fb_size; ret = fdt_fixup_memory_banks(blob, &start, &size, 1); if (ret) { eprintf("Cannot setup simplefb: Error reserving memory\n");
On Mon, 2015-02-02 at 19:57 +0100, Hans de Goede wrote:
Only use CONFIG_SUNXI_MAX_FB_SIZE to reserve memory at the top when relocating u-boot, and calculate the actual amount of memory necessary when setting up the video-mode and use only that, freeing up some additional memory for use by the kernel.
Signed-off-by: Hans de Goede hdegoede@redhat.com
Acked-by: Ian Campbell ijc@hellion.org.uk
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?
Hi,
On 02/03/2015 02:20 PM, Ian Campbell wrote:
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/.
OK, will fix.
*/- 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?
We get called after arch_fixup_fdt(), so we should be able to simply override what it has setup in the fdt.
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?
Then we need to keep track of if that callback succeeded, because without the reservation we should not enable simplefb. I would prefer to just keep this bit as is.
Regards,
Hans
On Tue, 2015-02-03 at 18:59 +0100, Hans de Goede wrote:
Then we need to keep track of if that callback succeeded, because without the reservation we should not enable simplefb. I would prefer to just keep this bit as is.
OK then. With the comment fixed up:
Acked-by: Ian Campbell ijc@hellion.org.uk
participants (2)
-
Hans de Goede -
Ian Campbell