[PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers
Thomas Zimmermann
tzimmermann at suse.de
Tue Oct 11 11:30:57 UTC 2022
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. Update
>
> You 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 <javierm at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20221011/51003fef/attachment.sig>
More information about the dri-devel
mailing list