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?
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
