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