From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anatolij Gustschin Date: Mon, 7 Jan 2013 00:09:26 +0100 Subject: [U-Boot] [PATCH RESEND] video:cache:fix: Buffer alignment and dcache flush for lcd subsystem In-Reply-To: <20130106202100.1E712203A73@gemini.denx.de> References: <1344438635-31169-1-git-send-email-l.majewski@samsung.com> <1357143901-10993-1-git-send-email-l.majewski@samsung.com> <20130106090356.29a7f9e4@jawa> <20130106202100.1E712203A73@gemini.denx.de> Message-ID: <20130107000926.33d7984a@crub> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Wolfgang, On Sun, 06 Jan 2013 21:21:00 +0100 Wolfgang Denk wrote: ... > > OK, so it is directly used as a frame buffer? In that case it looks > > right to me. I doubt you want to be able to control the cache features > > for this area, since you only write it once. But if you did, then the > > memory would currently need to be section-aligned. > > I don't think this is as it should be. Any frame buffer that actually > gets used as such should be located in the memory area specifically > allocated for this purpose using lcd_setmem(). This is especially > important when you load a splash screen image and intend to display it > flicker-free when booting an OS. If you use malloc() or memalign(), > it will be memory in the malloc arena, which gets overwritten when an > OS boots, resulting in a corrupted display. yes, for lcd.c driver the frame buffer is allocated by lcd_setmem(). malloc() is used only to buffer uncompressed BMP data here and it will be freed right after extracting the pixel data to the actual frame buffer. Thanks, Anatolij