From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752301AbdECDFg (ORCPT ); Tue, 2 May 2017 23:05:36 -0400 Received: from mail.netline.ch ([148.251.143.178]:36228 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751266AbdECDF2 (ORCPT ); Tue, 2 May 2017 23:05:28 -0400 Subject: Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN To: Gerd Hoffmann , Pekka Paalanen Cc: amd-gfx mailing list , Emil Velikov , open list , ML dri-devel , Daniel Vetter References: <20170502133404.15354-1-kraxel@redhat.com> <20170502133404.15354-2-kraxel@redhat.com> <20170502172724.31188e2d@eldfell> <1493737591.8581.126.camel@redhat.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <28424bad-95c8-7394-4742-cd258fd71032@daenzer.net> Date: Wed, 3 May 2017 12:05:00 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1493737591.8581.126.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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