Skip to contentSkip to conversation

video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

PATCH Superseded Lukasz Majewski 6 participants 13 messages Aug 8, 2012 – Jan 6, 2013

lore
Share & tools
lore

Lukasz Majewski

author
#0 lore raw

PATCH 1/2 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

This commit makes the video subsystem code cache aware. Memory allocated for decompressed BMP memory is now cache line aligned.

Flushing of the dcache is also performed after copying BMP data to fb address.

Signed-off-by Lukasz Majewski <[email protected]>
Signed-off-by Kyungmin Park <[email protected]>
Cc Anatolij Gustschin <[email protected]>
---
 common/cmd_bmp.c |    2 +-
 common/lcd.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletions(-)
common/cmd_bmp.c +1 -1
index b8809e3..7d3f45a 100644
@@ -54,7 +54,7 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
 	 * Decompress bmp image
 	 */
 	len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
-	dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+	dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);
 	if (dst == NULL) {
 		puts("Error: malloc in gunzip failed!\n");
 		return NULL;
common/lcd.c +3 -0
index 506a138..b092a11 100644
@@ -802,6 +802,9 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
 			}
 			fb  -= (lcd_line_length + width * (bpix / 8));
 		}
+		flush_dcache_range((unsigned long) fb,
+				   (unsigned long) fb +
+				   (lcd_line_length * height));
 		break;
 #endif /* CONFIG_BMP_32BPP */
 	default:
Signature · 1 line
1.7.2.3
author
#1 lore raw

PATCH 2/2 video:trats:logo: Make tizen_hd_logo cache line aligned.

The tizen_hd_logo is now aligned to cache line size.

Signed-off-by Lukasz Majewski <[email protected]>
Signed-off-by Kyungmin Park <[email protected]>
Cc Anatolij Gustschin <[email protected]>
---
 lib/tizen/tizen_hd_logo.h |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
lib/tizen/tizen_hd_logo.h +3 -1
index 2258fd5..51ed844 100644
@@ -22,7 +22,9 @@
 #ifndef _TIZEN_HD_LOGO_H_
 #define _TIZEN_HD_LOGO_H_
 
-unsigned char tizen_hd_logo[]={
+#include <linux/compiler.h>
+
+unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) tizen_hd_logo[] = {
 0x1f,0x8b,0x08,0x08,0xe0,0x6f,0x8f,0x4f,0x00,0x03,0x74,0x72,0x61,0x74,0x73,0x2e,
 0x62,0x6d,0x70,0x00,0xbc,0x5c,0xe9,0x53,0x1c,0x57,0x92,0xaf,0x6a,0xa0,0x81,0xa6,
 0xb9,0x1b,0x04,0x48,0x02,0x04,0x7d,0xd0,0xdd,0x1c,0x12,0xba,0xd1,0x61,0x59,0x48,
Signature · 1 line
1.7.2.3
#2 lore raw

PATCH 1/2 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

In reply to Lukasz Majewski
Quoted 5 lines · On Wednesday 08 August 2012 11:10:34 Lukasz Majewski wrote:

This commit makes the video subsystem code cache aware. Memory allocated for decompressed BMP memory is now cache line aligned.

Flushing of the dcache is also performed after copying BMP data to fb address.

i think this is a more comprehensive fix:
http://patchwork.ozlabs.org/patch/164722/

although your memalign() call might be useful to integrate into Simon's change -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120808/92bd6d36/attachment.pgp>

author
#3 lore raw

PATCH 1/2 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

Hi Mike,

Quoted 10 lines · On Wednesday 08 August 2012 11:10:34 Lukasz Majewski wrote:
Quoted 6 lines

This commit makes the video subsystem code cache aware. Memory allocated for decompressed BMP memory is now cache line aligned.

Flushing of the dcache is also performed after copying BMP data to fb address.

i think this is a more comprehensive fix:
http://patchwork.ozlabs.org/patch/164722/

Yes, indeed. Thanks for pointing out.

Quoted 3 lines

although your memalign() call might be useful to integrate into Simon's change -mike

I will comment the v3 patch verison.

Signature · 5 lines
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
author
#4 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

In reply to Lukasz Majewski

This commit makes the video subsystem code cache aware. Memory allocated for decompressed BMP memory is now cache line aligned.

Flushing of the dcache is also performed after copying BMP data to fb address (it is done for 32 BPP bitmap used on Trats board (Exynos4210)).

Tested-by Lukasz Majewski <[email protected]>
Signed-off-by Lukasz Majewski <[email protected]>
Signed-off-by Kyungmin Park <[email protected]>
Cc Anatolij Gustschin <[email protected]>
---
 common/cmd_bmp.c |    2 +-
 common/lcd.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletions(-)
common/cmd_bmp.c +1 -1
index 5a52edd..57f3eb5 100644
@@ -55,7 +55,7 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
 	 * Decompress bmp image
 	 */
 	len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
-	dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+	dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);
 	if (dst == NULL) {
 		puts("Error: malloc in gunzip failed!\n");
 		return NULL;
common/lcd.c +3 -0
index 4778655..784d1fb 100644
@@ -1023,6 +1023,9 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
 			}
 			fb  -= (lcd_line_length + width * (bpix / 8));
 		}
+		flush_dcache_range((unsigned long) fb,
+				   (unsigned long) fb +
+				   (lcd_line_length * height));
 		break;
 #endif /* CONFIG_BMP_32BPP */
 	default:
Signature · 1 line
1.7.2.3
#5 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

Hi Lukasz,

Quoted 6 lines · Lukasz Majewski

This commit makes the video subsystem code cache aware. Memory allocated for decompressed BMP memory is now cache line aligned.

Flushing of the dcache is also performed after copying BMP data to fb address (it is done for 32 BPP bitmap used on Trats board (Exynos4210)).

Sorry if I have this wrong, just have a few comments.

Quoted 15 lines
Tested-by Lukasz Majewski <[email protected]>
Signed-off-by Lukasz Majewski <[email protected]>
Signed-off-by Kyungmin Park <[email protected]>
Cc Anatolij Gustschin <[email protected]>
---
 common/cmd_bmp.c |    2 +-
 common/lcd.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletions(-)
common/cmd_bmp.c +0 -0
index 5a52edd..57f3eb5 100644

common/cmd_bmp.c bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp) · line 58

Quoted 5 lines
common/cmd_bmp.c +1 -1
@@ -55,7 +55,7 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
         * Decompress bmp image
         */
        len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
-       dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+       dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);

Why do you need to align this one? It is just returned to the caller, isn't it?

Quoted 8 lines
common/cmd_bmp.c +0 -0
        if (dst == NULL) {
                puts("Error: malloc in gunzip failed!\n");
                return NULL;
common/lcd.c +0 -0
index 4778655..784d1fb 100644

common/lcd.c int lcd_display_bitmap(ulong bmp_image, int x, int y) · line 1028

Quoted 6 lines
common/lcd.c +3 -0
@@ -1023,6 +1023,9 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
                        }
                        fb  -= (lcd_line_length + width * (bpix / 8));
                }
+               flush_dcache_range((unsigned long) fb,
+                                  (unsigned long) fb +
+                                  (lcd_line_length * height));

I'm not sure this is needed - there is a call to lcd_sync() at the bottom of this function now which should do the same thing,

Please can you take a look at currently mainline and see if you need to do anything more?

Quoted 6 lines
common/lcd.c +0 -1
                break;
 #endif /* CONFIG_BMP_32BPP */
        default:
--

1.7.2.3

Regards,
Simon

#6 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

Hi Simon,

Quoted 25 lines

Hi Lukasz,

Quoted 8 lines · Lukasz Majewski

This commit makes the video subsystem code cache aware. Memory allocated for decompressed BMP memory is now cache line aligned.

Flushing of the dcache is also performed after copying BMP data to fb address (it is done for 32 BPP bitmap used on Trats board (Exynos4210)).

Sorry if I have this wrong, just have a few comments.

Quoted 10 lines
Tested-by Lukasz Majewski <[email protected]>
Signed-off-by Lukasz Majewski <[email protected]>
Signed-off-by Kyungmin Park <[email protected]>
Cc Anatolij Gustschin <[email protected]>
---
 common/cmd_bmp.c |    2 +-
 common/lcd.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletions(-)
Quoted 14 lines

common/cmd_bmp.c bmp_image_t *gunzip_bmp(unsigned long addr, · line 59

Quoted 11 lines
common/cmd_bmp.c +1 -1
index 5a52edd..57f3eb5 100644
@@ -55,7 +55,7 @@ bmp_image_t *gunzip_bmp(unsigned long addr,
 unsigned long *lenp)
         * Decompress bmp image
         */
        len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
-       dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+       dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);

Why do you need to align this one? It is just returned to the caller, isn't it?

Yes, it is returned to the caller, but afterwards lcd_display_bitmap takes this pointer (and thereof probably unaligned buffer) and works on it. (At least in the case of trats the bmp is gzipped).

Quoted 19 lines
Quoted 9 lines
common/cmd_bmp.c +0 -0
        if (dst == NULL) {
                puts("Error: malloc in gunzip failed!\n");

                return NULL;
common/lcd.c +0 -0
index 4778655..784d1fb 100644

common/lcd.c int lcd_display_bitmap(ulong bmp_image, int · line 1028

Quoted 6 lines
common/lcd.c +3 -0
@@ -1023,6 +1023,9 @@ int lcd_display_bitmap(ulong bmp_image, int
 x, int y) }
                        fb  -= (lcd_line_length + width * (bpix /
 8)); }
+               flush_dcache_range((unsigned long) fb,
+                                  (unsigned long) fb +
+                                  (lcd_line_length * height));

I'm not sure this is needed - there is a call to lcd_sync() at the bottom of this function now which should do the same thing,

Quoted 2 lines

Please can you take a look at currently mainline and see if you need to do anything more?

Ok, I've checked. You are right, there is lcd_sync. Thanks for pointing.

I will force trats board to use it, and prepare patches.

Quoted 14 lines
Quoted 7 lines
common/lcd.c +0 -1
                break;
 #endif /* CONFIG_BMP_32BPP */
        default:
--

1.7.2.3

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#7 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

Hi Lukasz,

Quoted 42 lines · Lukasz Majewski

Hi Simon,

Quoted 25 lines

Hi Lukasz,

Quoted 8 lines · Lukasz Majewski

This commit makes the video subsystem code cache aware. Memory allocated for decompressed BMP memory is now cache line aligned.

Flushing of the dcache is also performed after copying BMP data to fb address (it is done for 32 BPP bitmap used on Trats board (Exynos4210)).

Sorry if I have this wrong, just have a few comments.

Quoted 10 lines
Tested-by Lukasz Majewski <[email protected]>
Signed-off-by Lukasz Majewski <[email protected]>
Signed-off-by Kyungmin Park <[email protected]>
Cc Anatolij Gustschin <[email protected]>
---
 common/cmd_bmp.c |    2 +-
 common/lcd.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletions(-)
Quoted 14 lines

common/cmd_bmp.c bmp_image_t *gunzip_bmp(unsigned long addr, · line 59

Quoted 11 lines
common/cmd_bmp.c +1 -1
index 5a52edd..57f3eb5 100644
@@ -55,7 +55,7 @@ bmp_image_t *gunzip_bmp(unsigned long addr,
 unsigned long *lenp)
         * Decompress bmp image
         */
        len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
-       dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+       dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);

Why do you need to align this one? It is just returned to the caller, isn't it?

Quoted 3 lines

Yes, it is returned to the caller, but afterwards lcd_display_bitmap takes this pointer (and thereof probably unaligned buffer) and works on it. (At least in the case of trats the bmp is gzipped).

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.

Quoted 20 lines
Quoted 20 lines
Quoted 10 lines
common/cmd_bmp.c +0 -0
        if (dst == NULL) {
                puts("Error: malloc in gunzip failed!\n");

                return NULL;
common/lcd.c +0 -0
index 4778655..784d1fb 100644

common/lcd.c int lcd_display_bitmap(ulong bmp_image, int · line 1028

Quoted 6 lines
common/lcd.c +3 -0
@@ -1023,6 +1023,9 @@ int lcd_display_bitmap(ulong bmp_image, int
 x, int y) }
                        fb  -= (lcd_line_length + width * (bpix /
 8)); }
+               flush_dcache_range((unsigned long) fb,
+                                  (unsigned long) fb +
+                                  (lcd_line_length * height));

I'm not sure this is needed - there is a call to lcd_sync() at the bottom of this function now which should do the same thing,

Quoted 6 lines
Quoted 2 lines

Please can you take a look at currently mainline and see if you need to do anything more?

Ok, I've checked. You are right, there is lcd_sync. Thanks for pointing.

I will force trats board to use it, and prepare patches.

OK.

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
common/lcd.c +0 -1
                break;
 #endif /* CONFIG_BMP_32BPP */
        default:
--

1.7.2.3

Quoted 7 lines
Quoted 6 lines

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Regards,
Simon

#8 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

Dear Lukasz & Simon,

In message <CAPnjgZ3tfvRJO-16ncwE43hPptdMEtOmPEK7pfeLkrMn-rVrgw@mail.gmail.com>

Quoted 7 lines · Simon Glass
Quoted 7 lines
Quoted 6 lines

common/cmd_bmp.c bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp) · line 58

Quoted 3 lines
common/cmd_bmp.c +1 -1
-       dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+       dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);

Why do you need to align this one? It is just returned to the caller, isn't it?

Quoted 8 lines
Quoted 3 lines

Yes, it is returned to the caller, but afterwards lcd_display_bitmap takes this pointer (and thereof probably unaligned buffer) and works on it. (At least in the case of trats the bmp is gzipped).

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.

Note: I added Anatolij, our video custodian to the Cc: list.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you think the problem is bad now, just wait until we've solved it.
                                                        Epstein's Law
#9 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

Hi Wolfgang,

Quoted 29 lines · Wolfgang Denk

Dear Lukasz & Simon,

In message <CAPnjgZ3tfvRJO-16ncwE43hPptdMEtOmPEK7pfeLkrMn-rVrgw@mail.gmail.com>

Quoted 7 lines · Simon Glass
Quoted 7 lines
Quoted 6 lines

common/cmd_bmp.c bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp) · line 58

Quoted 3 lines
common/cmd_bmp.c +1 -1
-       dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+       dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);

Why do you need to align this one? It is just returned to the caller, isn't it?

Quoted 8 lines
Quoted 3 lines

Yes, it is returned to the caller, but afterwards lcd_display_bitmap takes this pointer (and thereof probably unaligned buffer) and works on it. (At least in the case of trats the bmp is gzipped).

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.

Quoted 1 line

Note: I added Anatolij, our video custodian to the Cc: list.

OK, well in that case we should deprecate this business of using a separate memory buffer as a frame buffer, and make people uncompress the BMP to the normal frame buffer. It would simplify a few things and I doubt there would be a speed penalty (or at least it could be corrected by decompressing directly to the frame buffer).

Regards,
Simon

Quoted 11 lines

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de If you think the problem is bad now, just wait until we've solved it.
Epstein's Law

#10 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

Dear Simon,

Quoted 9 lines · In message <CAPnjgZ1X+anT6x4C0D6ZCoB3VvVVm1aBudkrcGkxg122F8XGmQ@mail.gmail.com>…
Quoted 9 lines

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.

Quoted 7 lines
Quoted 1 line

Note: I added Anatolij, our video custodian to the Cc: list.

OK, well in that case we should deprecate this business of using a separate memory buffer as a frame buffer, and make people uncompress the BMP to the normal frame buffer. It would simplify a few things and I doubt there would be a speed penalty (or at least it could be corrected by decompressing directly to the frame buffer).

Agreed - thanks!

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All he had was nothing, but that was something, and now it  had  been
taken away.                             - Terry Pratchett, _Sourcery_
#11 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

In reply to Wolfgang Denk

Hello Wolfgang,

On Sun, 06 Jan 2013 21:21:00 +0100
Wolfgang Denk <[email protected]> wrote:
...

Quoted 5 lines
Quoted 4 lines

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.

Quoted 7 lines

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

#12 lore raw

PATCH RESEND 1/1 video:cache:fix: Buffer alignment and dcache flush for lcd subsystem

In reply to Simon Glass

Hi Simon, Lukasz,

On Sun, 6 Jan 2013 07:47:58 -0800
Simon Glass <[email protected]> wrote:
...

Quoted 15 lines
Quoted 15 lines
Quoted 14 lines

common/cmd_bmp.c bmp_image_t *gunzip_bmp(unsigned long addr, · line 59

Quoted 11 lines
common/cmd_bmp.c +1 -1
index 5a52edd..57f3eb5 100644
@@ -55,7 +55,7 @@ bmp_image_t *gunzip_bmp(unsigned long addr,
 unsigned long *lenp)
         * Decompress bmp image
         */
        len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
-       dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+       dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);

Why do you need to align this one? It is just returned to the caller, isn't it?

Quoted 5 lines
Quoted 3 lines

Yes, it is returned to the caller, but afterwards lcd_display_bitmap takes this pointer (and thereof probably unaligned buffer) and works on it. (At least in the case of trats the bmp is gzipped).

OK, so it is directly used as a frame buffer?

the allocated area isn't directly used as a frame buffer, it is a buffer for bmp image which will be processed by lcd_display_bitmap(). The latter looks at the image header/palette and fills the frame buffer (lcd_base) with the image data. This image buffer can be unaligned I think.

Thanks,
Anatolij