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 7E718C4332F for ; Wed, 12 Oct 2022 14:59:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229700AbiJLO7x (ORCPT ); Wed, 12 Oct 2022 10:59:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229502AbiJLO7w (ORCPT ); Wed, 12 Oct 2022 10:59:52 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8623D140BB for ; Wed, 12 Oct 2022 07:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665586791; x=1697122791; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=p5FnZ4+f6pmWst9wSfrEJB9i2nRqQShtidpftxEjnbE=; b=SFmfOY9lLErwMbpEHai8Q3eXnfG2Db2FLx7MN9DRX5rDj+Dc54Fm1bh1 0/2gt372SQ6SlfBvD9XHPW3G29yquTUV+zc7MKq813uLPpmgMNzYDGZzX cgxCaIAzrIyiJ1K9pETQKLMdk6UTie0OlWgYm2iT8oXRpwc1P5NEit3oz 3n3ASe9keQ0nxcCS9VuOPZ7BIhZCthaisDcd4jlGnhuUr3FiIGjvKLRSt 5cvZNwZa++pbI7Q0Ml6RukqyuULYxZhr8UEYnxKShs1GaBJSYZl66i+P8 VI4iiWysth4VTrX7Y4+g+Rr9XsSVfVbWVK1bRfaU4FS1MWbuP6l+Ck3Id g==; X-IronPort-AV: E=McAfee;i="6500,9779,10497"; a="391121509" X-IronPort-AV: E=Sophos;i="5.95,179,1661842800"; d="scan'208";a="391121509" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2022 07:59:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10497"; a="731455010" X-IronPort-AV: E=Sophos;i="5.95,179,1661842800"; d="scan'208";a="731455010" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.191]) by fmsmga002.fm.intel.com with SMTP; 12 Oct 2022 07:59:46 -0700 Received: by stinkbox (sSMTP sendmail emulation); Wed, 12 Oct 2022 17:59:45 +0300 Date: Wed, 12 Oct 2022 17:59:45 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Thomas Zimmermann Cc: Arnd Bergmann , Javier Martinez Canillas , David Airlie , Daniel Vetter , Helge Deller , Maxime Ripard , sam@ravnborg.org, Michal Suchanek , Michael Ellerman , benh@kernel.crashing.org, 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 Subject: Re: [PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers Message-ID: References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org On Wed, Oct 12, 2022 at 04:31:14PM +0200, Thomas Zimmermann wrote: > Hi > > Am 12.10.22 um 15:12 schrieb Arnd Bergmann: > > On Wed, Oct 12, 2022, at 2:00 PM, Thomas Zimmermann wrote: > >> > >> 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. > > > > I wouldn't change the code in offb unless a user reports a bug, > > but I don't see a point in adding the same mistake to ofdrm if we > > know it can't work on real hardware. > > As I said, this has worked with offb and apparently on real hardware. > For all I know, ATI hardware (before it became AMD) was used in PPC > Macintoshs and assumed big-endian access on those machines. At least mach64 class hardware has two frame buffer apertures, and byte swapping can be configured separately for each. But that means you only get correct byte swapping for at most two bpps at the same time (and that only if you know which aperture to access each time). IIRC Rage 128 already has the surface register stuff where you could byte swap a limited set of ranges independently. And old mga hardware has just one byte swap setting for the whole frame buffer aperture, so only one bpp at a time. That kind of horrible limitations of the byte swappers is the main reason why I wanted to make drm fourcc endianness explicit. Simply assuming host endianness would end in tears on big endian as soon as you need to access stuff with two bpps at the same time. Much better to just switch off those useless byte swappers and swap by hand when necessary. -- Ville Syrjälä Intel 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 923B2C433FE for ; Wed, 12 Oct 2022 15:00:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AD1FA10E518; Wed, 12 Oct 2022 15:00:07 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id BC98010E518 for ; Wed, 12 Oct 2022 15:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665586800; x=1697122800; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=p5FnZ4+f6pmWst9wSfrEJB9i2nRqQShtidpftxEjnbE=; b=RIRRtZtA+dBd4cvafmHCEJOIqz18JrKjwedQjaGYRp9UHMVvvgYywskB 7MEdfPaddsjRl/6V06Fy+7FOjJzecc+p7Yhmx6+EZi/6Srk7eLcbIvqGu w1k/fBe7KdYoYa1osGH/z9s49JgtbXpRmTEntVvDqt19Ii+AXRwOMUi4Q ODUULmLXmPfnUP31NCDmNCt0IBzJaU/MLGrYEWsiPJTylhKyaShGvMJdF 8cNyQFtamG1EHrONYa9YJNcs0Z+dn7QzNGtNglZ5xHxaGIjrnSTyWbRvi CclCJsCCxiw4xN3ofwezk08TptTB1sin51ABQrN0zxxlkfXZzU7uAJSMJ A==; X-IronPort-AV: E=McAfee;i="6500,9779,10497"; a="331308572" X-IronPort-AV: E=Sophos;i="5.95,179,1661842800"; d="scan'208";a="331308572" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2022 07:59:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10497"; a="731455010" X-IronPort-AV: E=Sophos;i="5.95,179,1661842800"; d="scan'208";a="731455010" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.191]) by fmsmga002.fm.intel.com with SMTP; 12 Oct 2022 07:59:46 -0700 Received: by stinkbox (sSMTP sendmail emulation); Wed, 12 Oct 2022 17:59:45 +0300 Date: Wed, 12 Oct 2022 17:59:45 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Thomas Zimmermann Subject: Re: [PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers Message-ID: References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fbdev@vger.kernel.org, Arnd Bergmann , David Airlie , Michael Ellerman , Helge Deller , linuxppc-dev@lists.ozlabs.org, mark.cave-ayland@ilande.co.uk, Javier Martinez Canillas , dri-devel@lists.freedesktop.org, Paul Mackerras , Maxime Ripard , Geert Uytterhoeven , Michal Suchanek , sam@ravnborg.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Oct 12, 2022 at 04:31:14PM +0200, Thomas Zimmermann wrote: > Hi > > Am 12.10.22 um 15:12 schrieb Arnd Bergmann: > > On Wed, Oct 12, 2022, at 2:00 PM, Thomas Zimmermann wrote: > >> > >> 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. > > > > I wouldn't change the code in offb unless a user reports a bug, > > but I don't see a point in adding the same mistake to ofdrm if we > > know it can't work on real hardware. > > As I said, this has worked with offb and apparently on real hardware. > For all I know, ATI hardware (before it became AMD) was used in PPC > Macintoshs and assumed big-endian access on those machines. At least mach64 class hardware has two frame buffer apertures, and byte swapping can be configured separately for each. But that means you only get correct byte swapping for at most two bpps at the same time (and that only if you know which aperture to access each time). IIRC Rage 128 already has the surface register stuff where you could byte swap a limited set of ranges independently. And old mga hardware has just one byte swap setting for the whole frame buffer aperture, so only one bpp at a time. That kind of horrible limitations of the byte swappers is the main reason why I wanted to make drm fourcc endianness explicit. Simply assuming host endianness would end in tears on big endian as soon as you need to access stuff with two bpps at the same time. Much better to just switch off those useless byte swappers and swap by hand when necessary. -- Ville Syrjälä Intel 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DF0A3C4332F for ; Thu, 13 Oct 2022 11:39:36 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Mp6xg3qSWz3dtW for ; Thu, 13 Oct 2022 22:39:35 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=k4/rn0ND; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=192.55.52.88; helo=mga01.intel.com; envelope-from=ville.syrjala@linux.intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=k4/rn0ND; dkim-atps=neutral Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4MnbRS5GKBz3bjX for ; Thu, 13 Oct 2022 02:00:03 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665586804; x=1697122804; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=p5FnZ4+f6pmWst9wSfrEJB9i2nRqQShtidpftxEjnbE=; b=k4/rn0NDF0J2cHR0rRdy3Ww4lzeVFJz5efWFGMon6C1w+0h0EAASwG9Z x8YKSDWYjfxpOE5jE2aylmCjcnTTGNqpJikbgSrTQ/CJ5O929q1O+iGOj JQ0MRSPqIfXDfe7LrXI6XyMwE5o3Eed9a9OSXJjC4sXzh1Tgm8B61wLX6 A0uFfHjjZQq03w/nu0egityXuLJkARoNH8TkHtecY4vcpArAY3uM9EdDZ KMlEyM/thwN5+YqF2X8ksGNHdVHWO/4ZJXCVInDPHmW/B8VUBajmGL8dh osBjnzbQtnbkR/6U62Y4l9Yz9C3jGoRHTe12xhwrOp+nhxOEHRzItDodw Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10497"; a="331308573" X-IronPort-AV: E=Sophos;i="5.95,179,1661842800"; d="scan'208";a="331308573" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2022 07:59:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10497"; a="731455010" X-IronPort-AV: E=Sophos;i="5.95,179,1661842800"; d="scan'208";a="731455010" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.191]) by fmsmga002.fm.intel.com with SMTP; 12 Oct 2022 07:59:46 -0700 Received: by stinkbox (sSMTP sendmail emulation); Wed, 12 Oct 2022 17:59:45 +0300 Date: Wed, 12 Oct 2022 17:59:45 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Thomas Zimmermann Subject: Re: [PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers Message-ID: References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment X-Mailman-Approved-At: Thu, 13 Oct 2022 22:37:49 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fbdev@vger.kernel.org, Arnd Bergmann , David Airlie , Helge Deller , linuxppc-dev@lists.ozlabs.org, mark.cave-ayland@ilande.co.uk, Javier Martinez Canillas , dri-devel@lists.freedesktop.org, Paul Mackerras , Maxime Ripard , Daniel Vetter , Geert Uytterhoeven , Michal Suchanek , sam@ravnborg.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Oct 12, 2022 at 04:31:14PM +0200, Thomas Zimmermann wrote: > Hi > > Am 12.10.22 um 15:12 schrieb Arnd Bergmann: > > On Wed, Oct 12, 2022, at 2:00 PM, Thomas Zimmermann wrote: > >> > >> 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. > > > > I wouldn't change the code in offb unless a user reports a bug, > > but I don't see a point in adding the same mistake to ofdrm if we > > know it can't work on real hardware. > > As I said, this has worked with offb and apparently on real hardware. > For all I know, ATI hardware (before it became AMD) was used in PPC > Macintoshs and assumed big-endian access on those machines. At least mach64 class hardware has two frame buffer apertures, and byte swapping can be configured separately for each. But that means you only get correct byte swapping for at most two bpps at the same time (and that only if you know which aperture to access each time). IIRC Rage 128 already has the surface register stuff where you could byte swap a limited set of ranges independently. And old mga hardware has just one byte swap setting for the whole frame buffer aperture, so only one bpp at a time. That kind of horrible limitations of the byte swappers is the main reason why I wanted to make drm fourcc endianness explicit. Simply assuming host endianness would end in tears on big endian as soon as you need to access stuff with two bpps at the same time. Much better to just switch off those useless byte swappers and swap by hand when necessary. -- Ville Syrjälä Intel