linux-kernel - Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <28424bad-95c8-7394-4742-cd258fd71032@daenzer.net>
Date:   Wed, 3 May 2017 12:05:00 +0900
From:   Michel Dänzer <michel@...nzer.net>
To:     Gerd Hoffmann <kraxel@...hat.com>,
        Pekka Paalanen <ppaalanen@...il.com>
Cc:     amd-gfx mailing list <amd-gfx@...ts.freedesktop.org>,
        Emil Velikov <emil.l.velikov@...il.com>,
        open list <linux-kernel@...r.kernel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

On 03/05/17 12:06 AM, Gerd Hoffmann wrote:
> 
>> Removing the definition also removes the possibility to describe a lot
>> of pixel formats, so that should definitely be mentioned. I think it
>> would also be good to have some kind of justified claim that no
>> hardware actually needs the pixel formats this is removing (e.g. RGB565
>> BE).
> 
> That and RGB2101010 BE are the only candidates I can think of.
> 
> Dealing with those in none-native byteorder is a PITA though.  Display
> hardware is little endian (pci byte order) for quite a while already.

Maybe by default, but not exclusively.


> radeon looks differently on pre-R600 and R600+ hardware.
> 
> pre-R600 can byteswap on cpu access, so the cpu view is bigendian
> whereas things are actually stored on little endian byte order.
> Hardware supports both 16bit and 32bit swaps.  Used for fbdev emulation
> (probably 32bit swaps, but not fully sure).

32-bit swaps for 32 bpp, 16-bit swaps for 16 bpp.


> R600+ supports bigendian framebuffer formats, so no byteswapping on
> access is needed.  Not sure whenever that includes 16bpp formats or
> whenever this is limited to the 8 bit-per-color formats [...]

It includes 16bpp. Looking at
drivers/gpu/drm/radeon/atombios_crtc.c:dce4_crtc_do_set_base(), it sets
up byte-swapping for all multi-byte formats, so it effectively treats
all those formats as if they had DRM_FORMAT_BIG_ENDIAN set.

If the radeon (and amdgpu) driver were to be changed to use
drm_mode_legacy_fb_format_he for >= R600, that must also handle 16 bpp,
which requires DRM_FORMAT_BIG_ENDIAN. So I still don't see how that can
be removed or even deprecated.

>From Ilia's followup it sounds like there's a similar situation with
nouveau.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer