Thread (27 messages) 27 messages, 6 authors, 2022-10-17

Re: [PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers

From: Thomas Zimmermann <tzimmermann@suse.de>
Date: 2022-10-12 06:46:14
Also in: dri-devel, linuxppc-dev

Hi

Am 11.10.22 um 22:06 schrieb Arnd Bergmann:
On Tue, Oct 11, 2022, at 1:30 PM, Thomas Zimmermann wrote:
quoted
Am 11.10.22 um 09:46 schrieb Javier Martinez Canillas:
quoted
quoted
+static bool display_get_big_endian_of(struct drm_device *dev, struct device_node *of_node)
+{
+	bool big_endian;
+
+#ifdef __BIG_ENDIAN
+	big_endian = true;
+	if (of_get_property(of_node, "little-endian", NULL))
+		big_endian = false;
+#else
+	big_endian = false;
+	if (of_get_property(of_node, "big-endian", NULL))
+		big_endian = true;
+#endif
+
+	return big_endian;
+}
+
Ah, I see. The heuristic then is whether the build is BE or LE or if the Device
Tree has an explicit node defining the endianess. The patch looks good to me:
Yes. I took this test from offb.
Has the driver been tested with little-endian kernels though? While
ppc32 kernels are always BE, you can build kernels as either big-endian
or little-endian for most (modern) powerpc64 and arm/arm64 hardware,
and I don't see why that should change the defaults of the driver
when describing the same framebuffer hardware.
Yes, I tested this on qemu's ppc64le and ppc64.

Best regards
Thomas
I could understand having a default to e.g. big-endian on all powerpc and
a default for little-endian on all arm, but having it tied to the
way the kernel is built seems wrong, and doesn't make sense in a
DT binding either.

       Arnd
-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help