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

[Thomas Zimmermann]

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: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20221011/51003fef/attachment.sig>