Message ID | 20230426130420.19942-1-tzimmermann@suse.de |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp232095vqo; Wed, 26 Apr 2023 06:13:58 -0700 (PDT) X-Google-Smtp-Source: AKy350ZZSKZh36qYczmpQ5L/TcQwAPjuI0EGqEiQC9I01p0jkFOt/KeTHpl0fxGJEzulsk1qWwPV X-Received: by 2002:a05:6a20:1453:b0:ed:1355:f88a with SMTP id a19-20020a056a20145300b000ed1355f88amr27898944pzi.46.1682514837778; Wed, 26 Apr 2023 06:13:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682514837; cv=none; d=google.com; s=arc-20160816; b=K2AF+i5Su2Yokm/XW6/VHVLcNrNs2tKo7/XBpawRIjSG+5akWHLE0vMO3StiR2kxxb KAd6XA45j+ENNwzvXIvARNvQIi587Wf3gEkjPA3QthBW3fAqF0sjzMs6VU1AkN3e4xde 6KI1/KzMWe87G935PM88bYw4VqiWIkHV3sn3DO/ZdwAKRSohMNv73I9UFIZNjWjkoDwQ jPZrR0RT98PkSrC/o20zUMlxq7gQY4+Dd2ENnQGqwhd6rskGPc/ENVw+3+AAmijgyeSC QnEpT2q6g+CaT6K1Xl9eWfpt7Fv/GMypcynm+MEAaxtv/q/uqq3Xn0G93XOP2+X1LGWM Yw6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=ZvaBzh3f/aiqD52UlKjdoNF7+qwuUVn7MUgqdP2D7Nw=; b=gcRLjiQjLPQkmInYpKQCH/NZIGqALIg33O83zdrGPHe5ZFOgBBbyJbYrLe+zRzehui PZU+Y6q6/x30abyqnOl7mSiyPN2CoYxm9t19PsjuRAzmgXtj6pTsVjDFfoCnhjUgH4PU JmleGwVzlzhLXPGf1PkYl8DZekpX4qUSdrhTrIKyrArPBHSTC50QB1BZgVbRgtOtWl6+ tpm6bh2GZMSeXYOU1GW0ZWxXQE0XIT33EnIUuZTGi8MqOwIir0XuutkCuXATcwjLUOuG bLxuc3Du7XK1mWkmhj8HjiDaz1+J1GukVhi6iLanu6lu74gEDLXZBQC8OWcrcenvhEr2 xb0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=UUB5WwTL; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d4-20020a17090ab30400b002470448b9d2si7762630pjr.7.2023.04.26.06.13.42; Wed, 26 Apr 2023 06:13:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=UUB5WwTL; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240972AbjDZNE2 (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Wed, 26 Apr 2023 09:04:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240318AbjDZNEZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Apr 2023 09:04:25 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F5CA420C; Wed, 26 Apr 2023 06:04:24 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id F2B2A1FDC9; Wed, 26 Apr 2023 13:04:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1682514263; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ZvaBzh3f/aiqD52UlKjdoNF7+qwuUVn7MUgqdP2D7Nw=; b=UUB5WwTLuJwXSoCTJ3K7FRWI3bAowE0MAQQnTQ8Woqr9jGn3KSm4fv+l+btYHt/SEzCsD6 E6Tz3qvcxaYsO0Ane3YO3a66YgThKstJIJ4Lgjadjm2nGBl3KNTyxPMpou9Mnyuqc/adAL KiMTTGQM90NhVMGC3ytJZ9AIyukntHg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1682514263; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ZvaBzh3f/aiqD52UlKjdoNF7+qwuUVn7MUgqdP2D7Nw=; b=5Y5kjboljw7Gn1Hlnhprb8RfDWvqxVjp+TudZAikLk9S5eG7QO9FJaa/ij7yCLSwcYk6Zr niVmZqqNbyCVxQAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 86AF6138F0; Wed, 26 Apr 2023 13:04:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id eEa6H1YhSWSBMgAAMHmgww (envelope-from <tzimmermann@suse.de>); Wed, 26 Apr 2023 13:04:22 +0000 From: Thomas Zimmermann <tzimmermann@suse.de> To: deller@gmx.de, geert@linux-m68k.org, javierm@redhat.com, daniel@ffwll.ch, vgupta@kernel.org, chenhuacai@kernel.org, kernel@xen0n.name, davem@davemloft.net, James.Bottomley@HansenPartnership.com, arnd@arndb.de Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arch@vger.kernel.org, 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, Thomas Zimmermann <tzimmermann@suse.de> Subject: [PATCH 0/5] fbdev: Move framebuffer I/O helpers to <asm/fb.h> Date: Wed, 26 Apr 2023 15:04:15 +0200 Message-Id: <20230426130420.19942-1-tzimmermann@suse.de> X-Mailer: git-send-email 2.40.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764244678715323701?= X-GMAIL-MSGID: =?utf-8?q?1764244678715323701?= |
Series |
fbdev: Move framebuffer I/O helpers to <asm/fb.h>
|
|
Message
Thomas Zimmermann
April 26, 2023, 1:04 p.m. UTC
Fbdev provides helpers for framebuffer I/O, such as fb_readl(), fb_writel() or fb_memcpy_to_fb(). The implementation of each helper depends on the architecture. It's still all located in fbdev's main header file <linux/fb.h>. Move all of it into each archtecture's <asm/fb.h>, with shared code in <asm-generic/fb.h>. The first patch a simple whitespace cleanup. Until now, <linux/fb.h> contained an include of <asm/io.h>. As this will go away patches 2 to 4 prepare include statements in the various drivers. Source files that use regular I/O helpers, such as readl(), now include <linux/io.h>. Source files that use framebuffer I/O helpers, such as fb_readl(), now include <asm/fb.h>. The latter now includes <linux/io.h> internally. Patch 5 moves the framebuffer I/O helpers from <linux/fb.h> into the various architecture headers. The common case, where the framebuffer is located in I/O memory, serves as the generic implemenation. The patchset has been built for a variety of platforms, such as x86-64, arm, aarch64, ppc64, parisc, m64k, mips and sparc. Thomas Zimmermann (5): fbdev/matrox: Remove trailing whitespaces ipu-v3: Include <linux/io.h> fbdev: Include <linux/io.h> in various drivers fbdev: Include <linux/io.h> via <asm/fb.h> fbdev: Move framebuffer I/O helpers into <asm/fb.h> arch/arc/include/asm/fb.h | 29 +++++++ arch/ia64/include/asm/fb.h | 28 +++++++ arch/loongarch/include/asm/fb.h | 29 +++++++ arch/m68k/include/asm/fb.h | 29 +++++++ arch/sparc/include/asm/fb.h | 77 +++++++++++++++++ drivers/gpu/ipu-v3/ipu-prv.h | 1 + drivers/video/fbdev/arcfb.c | 1 + drivers/video/fbdev/arkfb.c | 2 + drivers/video/fbdev/aty/atyfb.h | 2 + drivers/video/fbdev/aty/mach64_cursor.c | 2 +- drivers/video/fbdev/chipsfb.c | 1 + drivers/video/fbdev/cirrusfb.c | 2 + drivers/video/fbdev/core/cfbcopyarea.c | 2 +- drivers/video/fbdev/core/cfbfillrect.c | 1 + drivers/video/fbdev/core/cfbimgblt.c | 1 + drivers/video/fbdev/core/svgalib.c | 3 +- drivers/video/fbdev/cyber2000fb.c | 2 + drivers/video/fbdev/ep93xx-fb.c | 2 + drivers/video/fbdev/hgafb.c | 3 +- drivers/video/fbdev/hitfb.c | 2 +- drivers/video/fbdev/kyro/fbdev.c | 3 +- drivers/video/fbdev/matrox/matroxfb_accel.c | 8 +- drivers/video/fbdev/matrox/matroxfb_base.h | 6 +- drivers/video/fbdev/pm2fb.c | 3 + drivers/video/fbdev/pm3fb.c | 2 + drivers/video/fbdev/pvr2fb.c | 2 + drivers/video/fbdev/s3fb.c | 2 + drivers/video/fbdev/sm712fb.c | 2 + drivers/video/fbdev/sstfb.c | 2 +- drivers/video/fbdev/stifb.c | 2 + drivers/video/fbdev/tdfxfb.c | 3 +- drivers/video/fbdev/tridentfb.c | 2 + drivers/video/fbdev/vga16fb.c | 3 +- drivers/video/fbdev/vt8623fb.c | 2 + drivers/video/fbdev/wmt_ge_rops.c | 2 + include/asm-generic/fb.h | 93 +++++++++++++++++++++ include/linux/fb.h | 53 ------------ 37 files changed, 340 insertions(+), 69 deletions(-)
Comments
Hi Thomas. On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote: > Fbdev provides helpers for framebuffer I/O, such as fb_readl(), > fb_writel() or fb_memcpy_to_fb(). The implementation of each helper > depends on the architecture. It's still all located in fbdev's main > header file <linux/fb.h>. Move all of it into each archtecture's > <asm/fb.h>, with shared code in <asm-generic/fb.h>. For once I think this cleanup is moving things in the wrong direction. The fb_* helpers predates the generic io.h support and try to add a generic layer for read read / write operations. The right fix would be to migrate fb_* to use the io helpers we have today - so we use the existing way to handle the architecture specific details. From a quick look there seems to be some challenges but the current helpers that re-do part of io.h is not the way forward and hiding them in arch/include/asm/fb.h seems counter productive. Sam
Hi Sam Am 26.04.23 um 21:21 schrieb Sam Ravnborg: > Hi Thomas. > > On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote: >> Fbdev provides helpers for framebuffer I/O, such as fb_readl(), >> fb_writel() or fb_memcpy_to_fb(). The implementation of each helper >> depends on the architecture. It's still all located in fbdev's main >> header file <linux/fb.h>. Move all of it into each archtecture's >> <asm/fb.h>, with shared code in <asm-generic/fb.h>. > > For once I think this cleanup is moving things in the wrong direction. > > The fb_* helpers predates the generic io.h support and try to > add a generic layer for read read / write operations. > > The right fix would be to migrate fb_* to use the io helpers > we have today - so we use the existing way to handle the architecture > specific details. I looked through the existing versions of the fb_() I/O helpers. They can apparently be implemented with the regular helpers of similar names. I'm not sure, but even Sparc looks compatible. At least these sbus_ functions seem to be equivalent to the __raw_() I/O helpers of similar names. Do you still have that Sparc emulator? > > From a quick look there seems to be some challenges but the current > helpers that re-do part of io.h is not the way forward and hiding them > in arch/include/asm/fb.h seems counter productive. Which challenges did you see? Best regards Thomas > > Sam -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
On Thu, Apr 27, 2023, at 08:22, Thomas Zimmermann wrote: > Am 26.04.23 um 21:21 schrieb Sam Ravnborg: >> On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote: >>> Fbdev provides helpers for framebuffer I/O, such as fb_readl(), >>> fb_writel() or fb_memcpy_to_fb(). The implementation of each helper >>> depends on the architecture. It's still all located in fbdev's main >>> header file <linux/fb.h>. Move all of it into each archtecture's >>> <asm/fb.h>, with shared code in <asm-generic/fb.h>. >> >> For once I think this cleanup is moving things in the wrong direction. >> >> The fb_* helpers predates the generic io.h support and try to >> add a generic layer for read read / write operations. >> >> The right fix would be to migrate fb_* to use the io helpers >> we have today - so we use the existing way to handle the architecture >> specific details. > > I looked through the existing versions of the fb_() I/O helpers. They > can apparently be implemented with the regular helpers of similar names. > > I'm not sure, but even Sparc looks compatible. At least these sbus_ > functions seem to be equivalent to the __raw_() I/O helpers of similar > names. Do you still have that Sparc emulator? I looked at the current code and came to the same conclusion: all architectures we support today do the same thing in __raw_readl() and fb_readl() etc, so we can completely remove the latter without changing semantics. I think the original list was necessary since not all architectures supported the __raw_ accessors in the past, so they were open-coded here for the rest. I thought there were also architectures on which __raw_readl() does a byteswap to reverse the swap done in a PCI host bridge, but it apears that none of those remain now, if we ever had them. Arnd
Hi Thomas, On Thu, Apr 27, 2023 at 09:22:47AM +0200, Thomas Zimmermann wrote: > Hi Sam > > Am 26.04.23 um 21:21 schrieb Sam Ravnborg: > > Hi Thomas. > > > > On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote: > > > Fbdev provides helpers for framebuffer I/O, such as fb_readl(), > > > fb_writel() or fb_memcpy_to_fb(). The implementation of each helper > > > depends on the architecture. It's still all located in fbdev's main > > > header file <linux/fb.h>. Move all of it into each archtecture's > > > <asm/fb.h>, with shared code in <asm-generic/fb.h>. > > > > For once I think this cleanup is moving things in the wrong direction. > > > > The fb_* helpers predates the generic io.h support and try to > > add a generic layer for read read / write operations. > > > > The right fix would be to migrate fb_* to use the io helpers > > we have today - so we use the existing way to handle the architecture > > specific details. > > I looked through the existing versions of the fb_() I/O helpers. They can > apparently be implemented with the regular helpers of similar names. > > I'm not sure, but even Sparc looks compatible. At least these sbus_ > functions seem to be equivalent to the __raw_() I/O helpers of similar > names. > Do you still have that Sparc emulator? I used qemu the last time I played with sparc and saved the instructions somewhere how to redo it - but that would use to bohcs driver only I think. I have saprc machines, but none of these are easy to get operational. We can always ask on sparclinux to get some testing feedback. > > > > > From a quick look there seems to be some challenges but the current > > helpers that re-do part of io.h is not the way forward and hiding them > > in arch/include/asm/fb.h seems counter productive. > > Which challenges did you see? sparc was the main thing - but maybe I did not look close enough. And then I tried to map the macros to some of the more highlevel ones from io.h, but as Arnd says the __raw* is the way to go here. Sam