Hi Am 12.10.22 um 09:17 schrieb Arnd Bergmann:
On Wed, Oct 12, 2022, at 8:46 AM, Thomas Zimmermann wrote:Am 11.10.22 um 22:06 schrieb Arnd Bergmann:On Tue, Oct 11, 2022, at 1:30 PM, Thomas Zimmermann wrote:Am 11.10.22 um 09:46 schrieb Javier Martinez Canillas:+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.Does qemu mark the device has having a particular endianess then, or does it switch the layout of the framebuffer to match what the CPU does?
The latter. On neither architecture does qemu expose this flag. The default endianess corresponds to the host.
Best regards Thomas
I've seen other cases where devices in qemu were defined using an
arbitrary definition of "cpu-endian", which is generally not how
real hardware works.
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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
