[PATCH RFC libdrm 0/2] Big-endian fixes

[PATCH RFC libdrm 0/2] Big-endian fixes

[Geert Uytterhoeven]

	Hi all,

When starting to use modetest, I was a bit surprised to discover the
default XR24 format wasn't displayed correctly on my work-in-progress
Atari DRM driver, which runs on a big-endian system.

This RFC patch series fixes some endianness issues in libdrm.
It has been tested on ARAnyM using a work-in-progress Atari DRM driver,
which can now display the XR24 format by converting XRGB8888 to RGB332.

Overview:
  - Patch 1 improves the existing endianness checks in a header file for
    the Intel driver,
  - Patch 2 fixes the display of 32 bpp patterns on big-endian systems.

Futher endian fixes may be needed.  Note that I also have a variant of
patch 2 for 16 bpp, which works with the Atari DRM driver converting
RGB565 to RGB332.  But I want to get real 16 bpp working in the Atari
DRM driver first, as that uses a 16-bit big endian format.
And what about 24 bpp?

Please refer to [1] for more information.

Thanks for your comments!

[1] "[PATCH v2 00/10] drm: Add support for low-color frame buffer formats"
    https://lore.kernel.org/r/cover.1646683502.git.geert@linux-m68k.org

Geert Uytterhoeven (2):
  intel: Improve checks for big-endian
  util: Fix 32 bpp patterns on big-endian

 intel/uthash.h       |  2 +-
 tests/util/pattern.c | 30 +++++++++++++++++++++---------
 2 files changed, 22 insertions(+), 10 deletions(-)

-- 
2.25.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH RFC libdrm 1/2] intel: Improve checks for big-endian

[Geert Uytterhoeven]

  - sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but
    does define __sparc__, hence replace the check for SPARC by a check
    for __sparc__,
  - powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__,
    but does define __BIG_ENDIAN__.
    powerpc64le-linux-gnu-gcc does not define __ppc__ or __ppc64__, but
    does define __LITTLE_ENDIAN__.
    Hence remove the checks for __ppc__ and __ppc64__.
  - mips{,64}-linux-gnu{,abi64}-gcc does not define __BIG_ENDIAN__, but
    does define __MIPSEB__, so add a check for the latter,
  - m68k-linux-gnu-gcc does not define __BIG_ENDIAN__, but does define
    __mc68000__, so add a check for the latter,
  - hppa{,64}-linux-gnu-gcc defines __BIG_ENDIAN__, and thus should work
    out-of-the-box.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Untested due to lack of hardware.
---
 intel/uthash.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/intel/uthash.h b/intel/uthash.h
index 45d1f9fc12a1d6f9..0f5480be6e8ca033 100644
--- a/intel/uthash.h
+++ b/intel/uthash.h
@@ -648,7 +648,7 @@ do {
 #define MUR_PLUS2_ALIGNED(p) (((unsigned long)p & 3UL) == 2UL)
 #define MUR_PLUS3_ALIGNED(p) (((unsigned long)p & 3UL) == 3UL)
 #define WP(p) ((uint32_t*)((unsigned long)(p) & ~3UL))
-#if (defined(__BIG_ENDIAN__) || defined(SPARC) || defined(__ppc__) || defined(__ppc64__))
+#if (defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__))
 #define MUR_THREE_ONE(p) ((((*WP(p))&0x00ffffff) << 8) | (((*(WP(p)+1))&0xff000000) >> 24))
 #define MUR_TWO_TWO(p)   ((((*WP(p))&0x0000ffff) <<16) | (((*(WP(p)+1))&0xffff0000) >> 16))
 #define MUR_ONE_THREE(p) ((((*WP(p))&0x000000ff) <<24) | (((*(WP(p)+1))&0xffffff00) >>  8))
-- 
2.25.1

Re: [PATCH RFC libdrm 1/2] intel: Improve checks for big-endian

[Robin Murphy]

On 2022-03-07 20:53, Geert Uytterhoeven wrote:
>    - sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but
>      does define __sparc__, hence replace the check for SPARC by a check
>      for __sparc__,
>    - powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__,
>      but does define __BIG_ENDIAN__.
>      powerpc64le-linux-gnu-gcc does not define __ppc__ or __ppc64__, but
>      does define __LITTLE_ENDIAN__.
>      Hence remove the checks for __ppc__ and __ppc64__.
>    - mips{,64}-linux-gnu{,abi64}-gcc does not define __BIG_ENDIAN__, but
>      does define __MIPSEB__, so add a check for the latter,
>    - m68k-linux-gnu-gcc does not define __BIG_ENDIAN__, but does define
>      __mc68000__, so add a check for the latter,
>    - hppa{,64}-linux-gnu-gcc defines __BIG_ENDIAN__, and thus should work
>      out-of-the-box.

FWIW there's also __ARM_BIG_ENDIAN for arm-* and aarch64-* targets in BE 
mode, if you want to flesh out the list even more. In principle there's 
also "__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__" which should supposedly be 
consistent across platforms, but I don't know if that's even more of a 
specific GCC-ism.

Robin.

> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Untested due to lack of hardware.
> ---
>   intel/uthash.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/intel/uthash.h b/intel/uthash.h
> index 45d1f9fc12a1d6f9..0f5480be6e8ca033 100644
> --- a/intel/uthash.h
> +++ b/intel/uthash.h
> @@ -648,7 +648,7 @@ do {
>   #define MUR_PLUS2_ALIGNED(p) (((unsigned long)p & 3UL) == 2UL)
>   #define MUR_PLUS3_ALIGNED(p) (((unsigned long)p & 3UL) == 3UL)
>   #define WP(p) ((uint32_t*)((unsigned long)(p) & ~3UL))
> -#if (defined(__BIG_ENDIAN__) || defined(SPARC) || defined(__ppc__) || defined(__ppc64__))
> +#if (defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__))
>   #define MUR_THREE_ONE(p) ((((*WP(p))&0x00ffffff) << 8) | (((*(WP(p)+1))&0xff000000) >> 24))
>   #define MUR_TWO_TWO(p)   ((((*WP(p))&0x0000ffff) <<16) | (((*(WP(p)+1))&0xffff0000) >> 16))
>   #define MUR_ONE_THREE(p) ((((*WP(p))&0x000000ff) <<24) | (((*(WP(p)+1))&0xffffff00) >>  8))

[PATCH RFC libdrm 2/2] util: Fix 32 bpp patterns on big-endian

[Geert Uytterhoeven]

DRM formats are defined to be little-endian, unless the
DRM_FORMAT_BIG_ENDIAN flag is set.  Hence writes of multi-byte pixel
values need to take endianness into account.

Introduce a cpu_to_le32() helper to convert 32-bit values from
CPU-endian to little-endian, and use them in the various pattern fill
functions for 32-bit formats.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Works now with Linux' drm_fb_xrgb8888_to_rgb332_line(), which uses
le32_to_cpu() to read pixel values from memory.

---
 tests/util/pattern.c | 30 +++++++++++++++++++++---------
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index 42d75d700700dc3d..48677ea6d25b2676 100644
--- a/tests/util/pattern.c
+++ b/tests/util/pattern.c
@@ -61,6 +61,18 @@ struct color_yuv {
 	  .u = MAKE_YUV_601_U(r, g, b), \
 	  .v = MAKE_YUV_601_V(r, g, b) }
 
+#if defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__)
+static inline uint32_t cpu_to_le32(uint32_t x)
+{
+	return ((x & 0x000000ffU) << 24) |
+	       ((x & 0x0000ff00U) <<  8) |
+	       ((x & 0x00ff0000U) >>  8) |
+	       ((x & 0xff000000U) >> 24);
+}
+#else
+#define cpu_to_le32(x)	(x)
+#endif
+
 /* This function takes 8-bit color values */
 static inline uint32_t shiftcolor8(const struct util_color_component *comp,
 				  uint32_t value)
@@ -520,26 +532,26 @@ static void fill_smpte_rgb32(const struct util_rgb_info *rgb, void *mem,
 
 	for (y = 0; y < height * 6 / 9; ++y) {
 		for (x = 0; x < width; ++x)
-			((uint32_t *)mem)[x] = colors_top[x * 7 / width];
+			((uint32_t *)mem)[x] = cpu_to_le32(colors_top[x * 7 / width]);
 		mem += stride;
 	}
 
 	for (; y < height * 7 / 9; ++y) {
 		for (x = 0; x < width; ++x)
-			((uint32_t *)mem)[x] = colors_middle[x * 7 / width];
+			((uint32_t *)mem)[x] = cpu_to_le32(colors_middle[x * 7 / width]);
 		mem += stride;
 	}
 
 	for (; y < height; ++y) {
 		for (x = 0; x < width * 5 / 7; ++x)
 			((uint32_t *)mem)[x] =
-				colors_bottom[x * 4 / (width * 5 / 7)];
+				cpu_to_le32(colors_bottom[x * 4 / (width * 5 / 7)]);
 		for (; x < width * 6 / 7; ++x)
 			((uint32_t *)mem)[x] =
-				colors_bottom[(x - width * 5 / 7) * 3
-					      / (width / 7) + 4];
+				cpu_to_le32(colors_bottom[(x - width * 5 / 7) * 3
+							  / (width / 7) + 4]);
 		for (; x < width; ++x)
-			((uint32_t *)mem)[x] = colors_bottom[7];
+			((uint32_t *)mem)[x] = cpu_to_le32(colors_bottom[7]);
 		mem += stride;
 	}
 }
@@ -1017,7 +1029,7 @@ static void fill_tiles_rgb32(const struct util_format_info *info, void *mem,
 					  (rgb32 >> 8) & 0xff, rgb32 & 0xff,
 					  alpha);
 
-			((uint32_t *)mem)[x] = color;
+			((uint32_t *)mem)[x] = cpu_to_le32(color);
 		}
 		mem += stride;
 	}
@@ -1164,7 +1176,7 @@ static void fill_gradient_rgb32(const struct util_rgb_info *rgb,
 
 		for (j = 0; j < width / 2; j++) {
 			uint32_t value = MAKE_RGBA10(rgb, j & 0x3ff, j & 0x3ff, j & 0x3ff, 0);
-			row[2*j] = row[2*j+1] = value;
+			row[2*j] = row[2*j+1] = cpu_to_le32(value);
 		}
 		mem += stride;
 	}
@@ -1174,7 +1186,7 @@ static void fill_gradient_rgb32(const struct util_rgb_info *rgb,
 
 		for (j = 0; j < width / 2; j++) {
 			uint32_t value = MAKE_RGBA10(rgb, j & 0x3fc, j & 0x3fc, j & 0x3fc, 0);
-			row[2*j] = row[2*j+1] = value;
+			row[2*j] = row[2*j+1] = cpu_to_le32(value);
 		}
 		mem += stride;
 	}
-- 
2.25.1

Re: [PATCH RFC libdrm 2/2] util: Fix 32 bpp patterns on big-endian

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Mon,  7 Mar 2022 21:53:42 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> DRM formats are defined to be little-endian, unless the
> DRM_FORMAT_BIG_ENDIAN flag is set.  Hence writes of multi-byte pixel
> values need to take endianness into account.
> 
> Introduce a cpu_to_le32() helper to convert 32-bit values from
> CPU-endian to little-endian, and use them in the various pattern fill
> functions for 32-bit formats.

Hi Geert,

FWIW, this explanation matches my understanding, so it sounds correct
to me. That's all I can say. I guess that means

Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>

?


Thanks,
pq

> 
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Works now with Linux' drm_fb_xrgb8888_to_rgb332_line(), which uses
> le32_to_cpu() to read pixel values from memory.
> 
> ---
>  tests/util/pattern.c | 30 +++++++++++++++++++++---------
>  1 file changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> index 42d75d700700dc3d..48677ea6d25b2676 100644
> --- a/tests/util/pattern.c
> +++ b/tests/util/pattern.c
> @@ -61,6 +61,18 @@ struct color_yuv {
>  	  .u = MAKE_YUV_601_U(r, g, b), \
>  	  .v = MAKE_YUV_601_V(r, g, b) }
>  
> +#if defined(__BIG_ENDIAN__) || defined(__sparc__) || defined(__mc68000__) || defined(__MIPSEB__)
> +static inline uint32_t cpu_to_le32(uint32_t x)
> +{
> +	return ((x & 0x000000ffU) << 24) |
> +	       ((x & 0x0000ff00U) <<  8) |
> +	       ((x & 0x00ff0000U) >>  8) |
> +	       ((x & 0xff000000U) >> 24);
> +}
> +#else
> +#define cpu_to_le32(x)	(x)
> +#endif


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]