On Sat, 31 Jan 2015 10:34:36 +0000 Ian Campbell ijc@hellion.org.uk wrote:
On Sat, 2015-01-31 at 03:21 +0200, Siarhei Siamashka wrote:
Because the framebuffer resides in a hidden chopped off part of DRAM, caching is not enabled for this area automatically when the MMU is configured. So it needs to be set explicitly.
Additionally, the cfb console has a function to check whether the framebuffer resides in DRAM or not. And the hidden sunxi framebuffer needs special treatment again.
I wonder if this (essentially the need to make cfb_fb_is_in_dram __weak) suggests that we are not correctly doing this hiding? Or at least not doing it the same as other platforms which steal DRAM for use as video ram.
We seem to set pGD->frameAdrs (==VIDEO_FB_ADRS in cfb_console) correctly, which is one half of cfb_fb_is_in_dram's input. So is the real issue that we omit the fb from bd->bi_dram instead of including it there and marking it reserved in another way?
Since sunxi is using the following feature for the framebuffer reservation, we are indeed not doing it correctly (or at least doing something that does not match the current documentation):
- CONFIG_SYS_MEM_TOP_HIDE (PPC only): If CONFIG_SYS_MEM_TOP_HIDE is defined in the board config header, this specified memory area will get subtracted from the top (end) of RAM and won't get "touched" at all by U-Boot. By fixing up gd->ram_size the Linux kernel should gets passed the now "corrected" memory size and won't touch it either. This should work for arch/ppc and arch/powerpc. Only Linux board ports in arch/powerpc with bootwrapper support that recalculate the memory size from the SDRAM controller setup will have to get fixed in Linux additionally.
This option can be used as a workaround for the 440EPx/GRx CHIP 11 errata where the last 256 bytes in SDRAM shouldn't be touched.
WARNING: Please make sure that this value is a multiple of the Linux page size (normally 4k). If this is not the case, then the end address of the Linux memory will be located at a non page size aligned address and this could cause major problems.
Trying to to add the sunxi framebuffer into more u-boot structures is going to violate the promise, stating that "this specified memory area won't get touched at all by U-Boot". And by doing so, violate it even more than it is already violated by sunxi_display and cfb_console.
I have a look around some of the other drivers for other platforms and I must confess I couldn't figure out how this all fits together for them...
In terms of the kernel interface I'd expect we want to use an FDT memeserve for the region, i.e. call fdt_add_reservemap_entry at some suitable place.
Anatolij, how are we supposed to be doing this?
This fix resolves the sluggish scrolling problem.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
drivers/video/cfb_console.c | 2 +- drivers/video/sunxi_display.c | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c index a81affa..23b50df 100644 --- a/drivers/video/cfb_console.c +++ b/drivers/video/cfb_console.c @@ -2090,7 +2090,7 @@ static void *video_logo(void) } #endif
-static int cfb_fb_is_in_dram(void) +__weak int cfb_fb_is_in_dram(void) { bd_t *bd = gd->bd; #if defined(CONFIG_ARM) || defined(CONFIG_AVR32) || defined(COFNIG_NDS32) || \ diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c index f5f24fc..22a1319 100644 --- a/drivers/video/sunxi_display.c +++ b/drivers/video/sunxi_display.c @@ -1060,6 +1060,12 @@ static const char *sunxi_get_mon_desc(enum sunxi_monitor monitor) return NULL; /* never reached */ }
+/* The framebuffer is in DRAM, even though it is in the hidden part of it */ +int cfb_fb_is_in_dram(void) +{
- return 1;
+}
void *video_hw_init(void) { static GraphicDevice *graphic_device = &sunxi_display.graphic_device; @@ -1079,6 +1085,10 @@ void *video_hw_init(void) CONFIG_SUNXI_FB_SIZE >> 10); gd->fb_base = gd->ram_top;
- mmu_set_region_dcache_behaviour(gd->fb_base,
CONFIG_SUNXI_FB_SIZE,DCACHE_WRITEBACK);- video_get_ctfb_res_modes(RES_MODE_1024x768, 24, &mode, &sunxi_display.depth, &options);
#ifdef CONFIG_VIDEO_HDMI