From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 590FEC4332F for ; Mon, 17 Oct 2022 06:56:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229727AbiJQG40 convert rfc822-to-8bit (ORCPT ); Mon, 17 Oct 2022 02:56:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230096AbiJQG4O (ORCPT ); Mon, 17 Oct 2022 02:56:14 -0400 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BFDDA2036F for ; Sun, 16 Oct 2022 23:55:40 -0700 (PDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 29H6i57k008119; Mon, 17 Oct 2022 01:44:06 -0500 Message-ID: <365fe5029716e589eaef71ababf27a459348f9ff.camel@kernel.crashing.org> Subject: Re: [PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers From: Benjamin Herrenschmidt To: Javier Martinez Canillas , Michal =?ISO-8859-1?Q?Such=E1nek?= , Arnd Bergmann Cc: Thomas Zimmermann , David Airlie , Daniel Vetter , Helge Deller , Maxime Ripard , sam@ravnborg.org, Michael Ellerman , Paul Mackerras , Geert Uytterhoeven , mark.cave-ayland@ilande.co.uk, linux-fbdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org Date: Mon, 17 Oct 2022 17:44:05 +1100 In-Reply-To: References: <83071743-a7f2-f761-baa3-da688f26b5e3@suse.de> <9162f41f-28c3-493c-ab54-b1c4a2fdf494@app.fastmail.com> <654e3cfe-80d7-46c9-8e5e-461846e4df35@app.fastmail.com> <866c7033-0d4e-7b5d-008c-8eb16f99498b@suse.de> <0a15ecf5-939d-3b00-bcde-0fc7b449cfda@suse.de> <76d8a408-fc3e-4bd1-91c5-8278f7469979@app.fastmail.com> <20221012142707.GD28810@kitsune.suse.cz> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org On Thu, 2022-10-13 at 09:39 +0200, Javier Martinez Canillas wrote: > > In absence of such test results I think the most reasonable thing is to > > keep the logic that nobody complained about for 10+ years. > > > > I agree with Michal and Thomas on this. I don't see a strong reason to not > use the same heuristic that the offb fbdev driver has been doing for this. > > Otherwise if this turns out to be needed, it will cause a regression for a > user that switches to this driver instead. Specially since both fbdev and > DRM drivers match against the same "display" OF compatible string. I agree. In the end, what it boils down to is, we don't know, we should guess. The endianness of the kernel is as good a guess as anything here. If not that, then assume BE. That code was originally written for old macs. Those could simply not boot anything other than a BE kernel. OF would always setup a 8bpp fb (so endianness is irrelevant) but BootX could setup something else. There's almost no old LE powerpc system out there, and I'm reasonably sure actually none of any relevance to this code. That leaves us with newer systems capable of endian switching. Those should just get the property added. I don't know of many cases out there. There' SLOS on powerpc which still won't set it (which is what qemu uses). That could just be fixed. In the meantime it makes sense for the kernel to follow its existing behaviour. Cheers, Ben.