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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 148DEC7EE29 for ; Tue, 2 May 2023 20:06:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1yiPHuPngCuDEmshJ9qRs5BQR8Wl2WjPkuZBBnJhf9M=; b=cydpTGc/qO5+cH 7jQRIicerrt9KAUATgHHrp8/khuZscHrpBB9Tjz3z7WOz0dkKLRB4erIpaGDLbNSiTaP9D/3yoXtB UuEwLIi5HZ9wIeBu1miGAbrjrZP4d8E8gPdJcUW9x2KppNevedKjgDK65tvzX8q97Pzic9E/ak62G V8aqOWV+Q1QoGaIhrjuROS4eSS1U7w6x2uXK5YAQctG8Znq9mQgSD+z6WiWLlXez5prDusU1JrjHB X8DjPvQ/wdasWFekVohvq789+I5sR6Kn6caZQ29pkr9Jz5/zUmdr3hkxYuY+FD2lD5LOXx0vsexo6 +LHxxzf4uAhtzK2StPDg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ptwGp-002Whg-0i; Tue, 02 May 2023 20:06:43 +0000 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ptwGk-002WgJ-1n; Tue, 02 May 2023 20:06:40 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id EB34B2B066FC; Tue, 2 May 2023 16:06:32 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Tue, 02 May 2023 16:06:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1683057992; x=1683065192; bh=5x TPMX3pv0srvr+ZsZiut6qJVZAYp0ChcBRbjNGHX30=; b=ZTvsHN9+uxpCL7FksS kwo3JrlnKSMBz/v6oovLN4gFfPuDwcis1zK1a7zX+U4EMCkEskzl8t9L3thdkkyp uYpHqLLEV8Y2/gwcUusIJLNIe8UPFQZDbvrgmfRa1pY2hBUtlVdJ/9XlRWissH8L RZUqWVGEZqc7kbQToz2df+wMKPzvJZz7OfH9fm/KKJfI4vdjYI50mKj4FFphTWtO 15HBxbJh0hY7E5UW3e2N1yL6hg5QoeHpQ3aNrNchnn1WlChZDtrEj2EiD/5MCGDF 40wwVa0xZ+AZ/o0IY+iQ3jM0Z1ruvVGOOHGjtm7BF+wspVkvTB48vtzziLBeW8k7 q61A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1683057992; x=1683065192; bh=5xTPMX3pv0srv r+ZsZiut6qJVZAYp0ChcBRbjNGHX30=; b=PU/7+KxYrASE8LNYfBiYFyUBHfHyC l+jhzmQBZAlBIO7EvQqNGSc1CmBFJf/RgZVQKMnPT5dOAs+EUf/U0nUYSNRtg8Co PzwAszRrzyl9Bj01mORZO8Iy7Pbm1Exx9HGDXLmQLfNT/EqHRH7kOp3xs314GtbL rDRPiHOPVfbZqPMsLcG97h9UMnWTdKQdNtHM+pCUcGCTFS7dUGxwWiyoQ7PfZ+3K 9xLpTd1yhPC9o5H73dTxWPQtmoY+hZcnopHUvwXwz3kk7Z15u87rIiHztLfs24rT q53zbLCDTHvpwvaxqrctfu8Q4n4okdhysDgOXqX/nncLC5HQ0cdYfOtdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedviedgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdet rhhnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrg htthgvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedt keetffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrhhnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id ED568B60086; Tue, 2 May 2023 16:06:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-386-g2404815117-fm-20230425.001-g24048151 Mime-Version: 1.0 Message-Id: <67d6a188-041f-4604-99a3-548c41af0693@app.fastmail.com> In-Reply-To: <20230502130223.14719-6-tzimmermann@suse.de> References: <20230502130223.14719-1-tzimmermann@suse.de> <20230502130223.14719-6-tzimmermann@suse.de> Date: Tue, 02 May 2023 22:06:10 +0200 From: "Arnd Bergmann" To: "Thomas Zimmermann" , "Helge Deller" , "Geert Uytterhoeven" , "Javier Martinez Canillas" , "Daniel Vetter" , "Vineet Gupta" , "Huacai Chen" , "WANG Xuerui" , "David S . Miller" , "James E . J . Bottomley" , "Sam Ravnborg" Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Linux-Arch , linux-snps-arc@lists.infradead.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, sparclinux@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org Subject: Re: [PATCH v3 5/6] fbdev: Move framebuffer I/O helpers into X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230502_130639_015758_87AC2299 X-CRM114-Status: GOOD ( 15.89 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org On Tue, May 2, 2023, at 15:02, Thomas Zimmermann wrote: > Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(), > in the architecture's header file or the generic one. > > The common case has been the use of regular I/O functions, such as > __raw_readb() or memset_io(). A few architectures used plain system- > memory reads and writes. Sparc used helpers for its SBus. > > The architectures that used special cases provide the same code in > their __raw_*() I/O helpers. So the patch replaces this code with the > __raw_*() functions and moves it to for all > architectures. > > v3: > * implement all architectures with generic helpers > * support reordering and native byte order (Geert, Arnd) This looks good for the read/write helpers, but I'm a little worried about the memset and memcpy functions, since they do change behavior on some architectures: - on sparc64, fb_mem{set,cpy} uses ASI_PHYS_BYPASS_EC_E (like __raw_readb) while mem{set_,cpy_from,cpy_to} uses ASI_PHYS_BYPASS_EC_E_L (like readb) I don't know the effect of that, but it seems intentional - on loongarch and csky, the _io variants avoid unaligned access, while the normal memcpy/memset is probably broken, so your patch is a bugfix - on ia64, the _io variants use bytewise access and avoid any longer loads and stores, so your patch probably makes things slower. It's probably safe to deal with all the above by either adding architecture specific overrides to the current version, or by doing the semantic changes before the move to asm/fb.h, but one way or the other I'd prefer this to be separate from the consolidation patch that should not have any changes in behavior. Arnd _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc