Hi Am 11.10.22 um 09:46 schrieb Javier Martinez Canillas:
Hello Thomas,On 9/28/22 12:50, Thomas Zimmermann wrote:All DRM formats assume little-endian byte order. On big-endian systems, it is likely that the scanout buffer is in big endian as well. UpdateYou say it is likely, not always then? Does it depend on whether the Open Firmware is BE or LE ?
It's the endianess of the framebuffer. There's graphics hardware that can switch between the two or even support both at the same time (depending on the aperture range). I don't know the exact semantics when each is being used, but I suspect that it corresponds to host endianess.
[...]+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.
Reviewed-by: Javier Martinez Canillas <javi...@redhat.com>
Thanks Best regards Thomas -- 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
OpenPGP_signature
Description: OpenPGP digital signature
