From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752812AbdECJYx convert rfc822-to-8bit (ORCPT ); Wed, 3 May 2017 05:24:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39334 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751661AbdECJYp (ORCPT ); Wed, 3 May 2017 05:24:45 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 39F8480C06 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 39F8480C06 Message-ID: <1493803481.8581.163.camel@redhat.com> Subject: Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN From: Gerd Hoffmann To: Michel =?ISO-8859-1?Q?D=E4nzer?= Cc: Pekka Paalanen , amd-gfx mailing list , Emil Velikov , open list , ML dri-devel , Daniel Vetter Date: Wed, 03 May 2017 11:24:41 +0200 In-Reply-To: <28424bad-95c8-7394-4742-cd258fd71032@daenzer.net> References: <20170502133404.15354-1-kraxel@redhat.com> <20170502133404.15354-2-kraxel@redhat.com> <20170502172724.31188e2d@eldfell> <1493737591.8581.126.camel@redhat.com> <28424bad-95c8-7394-4742-cd258fd71032@daenzer.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 03 May 2017 09:24:44 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > 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. Ok. Dropped patch #1. Updated patch #2 to include all formats returned by drm_mode_legacy_fb_format, and also renamed them to DRM_FORMAT_HOST_*. Question is how to go forward with patch #3. I'd prefer to not add drm_mode_legacy_fb_format_he if possible. Is there a chance to adapt the radeon and nvidia drivers to a fixed drm_mode_legacy_fb_format function (returning be formats on be) without invasive changes? Given they both treat formats as if they had DRM_FORMAT_BIG_ENDIAN set this could (with the help of the extended patch #2) be a simple s/DRM_FORMAT_/DRM_FORMAT_HOST/ at the right places ... Michael? Ilia? cheers, Gerd