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

From: Thomas Zimmermann <tzimmermann@suse.de>
To: Arnd Bergmann <arnd@arndb.de>,
	Javier Martinez Canillas <javierm@redhat.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Helge Deller <deller@gmx.de>, Maxime Ripard <maxime@cerno.tech>,
	sam@ravnborg.org, Michal Suchanek <msuchanek@suse.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	benh@kernel.crashing.org, Paul Mackerras <paulus@samba.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	mark.cave-ayland@ilande.co.uk
Cc: linux-fbdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers
Date: Wed, 12 Oct 2022 14:00:46 +0200	[thread overview]
Message-ID: <0a15ecf5-939d-3b00-bcde-0fc7b449cfda@suse.de> (raw)
In-Reply-To: <fc33ebf7-ecb7-4686-ac31-0118a40595f6@app.fastmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 2277 bytes --]

Hi

Am 12.10.22 um 10:38 schrieb Arnd Bergmann:
> On Wed, Oct 12, 2022, at 10:27 AM, Thomas Zimmermann wrote:
>> Am 12.10.22 um 09:44 schrieb Arnd Bergmann:
>>> On Wed, Oct 12, 2022, at 9:40 AM, Thomas Zimmermann wrote:
>>>> Am 12.10.22 um 09:17 schrieb Arnd Bergmann:
>>>>> On Wed, Oct 12, 2022, at 8:46 AM, Thomas Zimmermann wrote:
>>>>
>>>>> 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.
>>>
>>> "host" as in the machine that qemu runs on, or the machine that is
>>> being emulated? I suppose it would be broken either way, but in the
>>> latter case, we could get away with detecting that the machine is
>>> running under qemu.
>>
>> Sorry, my mistake. I meant "guest": the endianess of the framebuffer
>> corresponds to the endianess of the emulated machine.  Given that many
>> graphics cards support LE and BE modes, I assume that this behavior
>> mimics real-hardware systems.
> 
> Not really: While the hardware may be able to switch between
> the modes, something has to actively set some hardware registers up
> that way, but the offb/ofdrm driver has no interface for interacting
> with that register, and the bootloader or firmware code that knows
> about the register has no information about what kernel it will
> eventually run. This is a bit architecture dependent, as e.g. on
> MIPS, a bi-endian hardware platform has to run a bootloader with the
> same endianness as the kernel, but on arm and powerpc the bootloader
> is usually fixed and the kernel switches to its configured endianness
> in the first few instructions after it gets entered.

Could well be. But ofdrm intents to replace offb and this test has 
worked well in offb for almost 15 yrs. If there are bug reports, I'm 
happy to take patches, but until then I see no reason to change it.

Best regards
Thomas

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]