From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 12:20:05
The variables screen_info and edid_info provide information about
the system's screen, and possibly EDID data of the connected display.
Both are defined and set by architecture code. But both variables are
declared in non-arch header files. Dependencies are at bease loosely
tracked. To resolve this, move the global state screen_info and its
companion edid_info into arch/. Only declare them on architectures
that define them. List dependencies on the variables in the Kconfig
files. Also clean up the callers.
Patch 1 to 4 resolve a number of unnecessary include statements of
<linux/screen_info.h>. The header should only be included in source
files that access struct screen_info.
Patches 5 to 7 move the declaration of screen_info and edid_info to
<asm-generic/screen_info.h>. Architectures that provide either set
a Kconfig token to enable them.
Patches 8 to 9 make users of screen_info depend on the architecture's
feature.
Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
data to make use of existing helpers and the refactored edid_info.
Tested on x86-64. Built for a variety of platforms.
Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.
Thomas Zimmermann (12):
efi: Do not include <linux/screen_info.h> from EFI header
fbdev/sm712fb: Do not include <linux/screen_info.h>
sysfb: Do not include <linux/screen_info.h> from sysfb header
staging/sm750fb: Do not include <linux/screen_info.h>
arch: Remove trailing whitespaces
arch: Declare screen_info in <asm/screen_info.h>
arch/x86: Declare edid_info in <asm/screen_info.h>
drivers/firmware: Remove trailing whitespaces
drivers: Add dependencies on CONFIG_ARCH_HAS_SCREEN_INFO
fbdev/core: Use fb_is_primary_device() in fb_firmware_edid()
fbdev/core: Protect edid_info with CONFIG_ARCH_HAS_EDID_INFO
fbdev/core: Define empty fb_firmware_edid() in <linux/fb.h>
arch/Kconfig | 12 +++++++
arch/alpha/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm/kernel/efi.c | 2 ++
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/efi.c | 1 +
arch/csky/Kconfig | 1 +
arch/hexagon/Kconfig | 1 +
arch/ia64/Kconfig | 5 +--
arch/loongarch/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/riscv/Kconfig | 1 +
arch/sh/Kconfig | 7 ++--
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 2 ++
arch/xtensa/Kconfig | 1 +
drivers/firmware/Kconfig | 3 +-
drivers/firmware/efi/Kconfig | 1 +
drivers/firmware/efi/libstub/efi-stub-entry.c | 2 ++
drivers/firmware/efi/libstub/screen_info.c | 2 ++
drivers/gpu/drm/Kconfig | 1 +
drivers/hv/Kconfig | 1 +
drivers/staging/sm750fb/sm750.c | 1 -
drivers/staging/sm750fb/sm750_accel.c | 1 -
drivers/staging/sm750fb/sm750_cursor.c | 1 -
drivers/staging/sm750fb/sm750_hw.c | 1 -
drivers/video/console/Kconfig | 2 ++
drivers/video/fbdev/Kconfig | 4 +++
drivers/video/fbdev/core/fbmon.c | 34 ++++++-------------
drivers/video/fbdev/i810/i810-i2c.c | 2 +-
drivers/video/fbdev/intelfb/intelfbdrv.c | 2 +-
drivers/video/fbdev/nvidia/nv_i2c.c | 2 +-
drivers/video/fbdev/savage/savagefb-i2c.c | 2 +-
drivers/video/fbdev/sm712fb.c | 9 +++--
include/asm-generic/Kbuild | 1 +
include/asm-generic/screen_info.h | 18 ++++++++++
include/linux/efi.h | 3 +-
include/linux/fb.h | 10 +++++-
include/linux/screen_info.h | 2 +-
include/linux/sysfb.h | 3 +-
include/video/edid.h | 3 --
43 files changed, 105 insertions(+), 47 deletions(-)
create mode 100644 include/asm-generic/screen_info.h
base-commit: d2f0af8472494398a42153684b790b723a79f143
--
2.41.0
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 12:20:13
The header file <linux/efi.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm/kernel/efi.c | 2 ++
arch/arm64/kernel/efi.c | 1 +
drivers/firmware/efi/libstub/efi-stub-entry.c | 2 ++
drivers/firmware/efi/libstub/screen_info.c | 2 ++
include/linux/efi.h | 3 ++-
5 files changed, 9 insertions(+), 1 deletion(-)
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2023-07-04 16:24:37
Thomas Zimmermann [off-list ref] writes:
The header file <linux/efi.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Sui Jingfeng <hidden> Date: 2023-07-05 01:40:28
Hi, Thomas
I love your patch, LoongArch also have UEFI GOP support,
Maybe the arch/loongarch/kernel/efi.c don't include the '#include
<linux/screen_info.h>' explicitly.
The header file <linux/efi.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
With the above issue solved, please take my R-B if you would like.
Reviewed-by: Sui Jingfeng <redacted>
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-07-05 08:00:20
Hi
Am 05.07.23 um 03:40 schrieb Sui Jingfeng:
Hi, Thomas
I love your patch, LoongArch also have UEFI GOP support,
Maybe the arch/loongarch/kernel/efi.c don't include the '#include
<linux/screen_info.h>' explicitly.
Oh, thank you for testing. I try to build arch/ changes on all of the
affected platforms, but I cannot build for all of them. I have no means
of building for loongarch ATM.
I'll update the patch according to your feedback.
Best regards
Thomas
The header file <linux/efi.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
With the above issue solved, please take my R-B if you would like.
Reviewed-by: Sui Jingfeng <redacted>
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 12:20:19
Sm712fb's dependency on <linux/screen_info.h> is artificial in that
it only uses struct screen_info for its internals. Replace the use of
struct screen_info with a custom data structure and remove the include
of <linux/screen_info.h>.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
Cc: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/sm712fb.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2023-07-04 16:26:31
Thomas Zimmermann [off-list ref] writes:
Sm712fb's dependency on <linux/screen_info.h> is artificial in that
it only uses struct screen_info for its internals. Replace the use of
struct screen_info with a custom data structure and remove the include
of <linux/screen_info.h>.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
Cc: Helge Deller <deller@gmx.de>
---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 12:20:29
The header file <linux/sysfb.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Hans de Goede <redacted>
Cc: Javier Martinez Canillas <javierm@redhat.com>
---
include/linux/sysfb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2023-07-04 16:27:33
Thomas Zimmermann [off-list ref] writes:
The header file <linux/sysfb.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Hans de Goede <redacted>
Cc: Javier Martinez Canillas <javierm@redhat.com>
---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Sui Jingfeng <hidden> Date: 2023-07-05 01:42:03
On 2023/6/29 19:45, Thomas Zimmermann wrote:
The header file <linux/sysfb.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Hans de Goede <redacted>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2023-07-04 16:28:10
Thomas Zimmermann [off-list ref] writes:
The sm750fb driver does not need anything from <linux/screen_info.h>.
Remove the include statements.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
What is the purpose of adding a file in asm-generic? If all
architectures use the same generic file, I'd just leave the
declaration in include/linux/. I wouldn't bother adding the
#ifdef either, but I can see how that helps turn a link
error into an earlier compile error.
Arnd
What is the purpose of adding a file in asm-generic? If all
architectures use the same generic file, I'd just leave the
declaration in include/linux/. I wouldn't bother adding the
That appears a bit 'un-clean' for something that is defined in
architecture? But OK, I would not object.
#ifdef either, but I can see how that helps turn a link
error into an earlier compile error.
Yes, that's intentional. If there's a Kconfig token anyway, we can also
fail early during the build.
Best regards
Thomas
Arnd
--
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)
address translations. Page table walkers that clear the
accessed bit
may use this capability to reduce their search space.
+config ARCH_HAS_SCREEN_INFO
+ bool
+ help
+ Selected by architectures that provide a global instance of
+ screen_info.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
Hi,
Why this patch get dropped in the end?
Since the global screen_info is an arch-specific thing,
Whenever an arch-neutral module or subsystem references the global screen_info,
There are some complaints from either compile testing robot.
Well, a programmer may handle it by using the CONFIG_SYSFB guard,
but it is not as precise as what this patch provided.
Personally, I think this patch is still valuable.
I suggest either forcing all other architectures to export screen_info,
like the X86 and IA64 arch does, after all the screen_info is a good thing.
or provide the fine-control version like this patch does.
On 2023/6/29 19:45, Thomas Zimmermann wrote:
quoted hunk
The variable screen_info does not exist on all architectures. Declare
it in <asm-generic/screen_info.h>. All architectures that do declare it
will provide it via <asm/screen_info.h>.
Add the Kconfig token ARCH_HAS_SCREEN_INFO to guard against access on
architectures that don't provide screen_info.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Ivan Kokshaysky <redacted>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Guo Ren <guoren@kernel.org>
Cc: Brian Cain <redacted>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <redacted>
Cc: Paul Walmsley <redacted>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <redacted>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <redacted>
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Juerg Haefliger <redacted>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Anshuman Khandual <redacted>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: "Russell King (Oracle)" <redacted>
Cc: Linus Walleij <redacted>
Cc: Sebastian Reichel <redacted>
Cc: "Mike Rapoport (IBM)" <rppt@kernel.org>
Cc: "Kirill A. Shutemov" <redacted>
Cc: Zi Yan <ziy@nvidia.com>
Acked-by: WANG Xuerui <redacted> # loongarch
---
arch/Kconfig | 6 ++++++
arch/alpha/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/csky/Kconfig | 1 +
arch/hexagon/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/loongarch/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/riscv/Kconfig | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
drivers/video/Kconfig | 3 +++
include/asm-generic/Kbuild | 1 +
include/asm-generic/screen_info.h | 12 ++++++++++++
include/linux/screen_info.h | 2 +-
20 files changed, 38 insertions(+), 1 deletion(-)
create mode 100644 include/asm-generic/screen_info.h
Hi,
Why this patch get dropped in the end?
Since the global screen_info is an arch-specific thing,
Whenever an arch-neutral module or subsystem references the global
screen_info,
There are some complaints from either compile testing robot.
There are some complaints from either compile testing robot or domain
specific reviewers who doubt why you select the CONFIG_SYSFB not
CONFIG_VT or CONFIG_EFI.
Well, a programmer may handle it by using the CONFIG_SYSFB guard,
but it is not as precise as what this patch provided.
Personally, I think this patch is still valuable.
I suggest either forcing all other architectures to export screen_info,
like the X86 and IA64 arch does, after all the screen_info is a good
thing.
or provide the fine-control version like this patch does.
Because all of the three tokens(CONFIG_SYSFB not CONFIG_VT or CONFIG_EFI.)
have no direct relationship with the global screen_info if an arch is
not mentioned first.
On 2023/6/29 19:45, Thomas Zimmermann wrote:
quoted
The variable screen_info does not exist on all architectures. Declare
it in <asm-generic/screen_info.h>. All architectures that do declare it
will provide it via <asm/screen_info.h>.
Add the Kconfig token ARCH_HAS_SCREEN_INFO to guard against access on
architectures that don't provide screen_info.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Ivan Kokshaysky <redacted>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Guo Ren <guoren@kernel.org>
Cc: Brian Cain <redacted>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <redacted>
Cc: Paul Walmsley <redacted>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <redacted>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <redacted>
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Juerg Haefliger <redacted>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Anshuman Khandual <redacted>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: "Russell King (Oracle)" <redacted>
Cc: Linus Walleij <redacted>
Cc: Sebastian Reichel <redacted>
Cc: "Mike Rapoport (IBM)" <rppt@kernel.org>
Cc: "Kirill A. Shutemov" <redacted>
Cc: Zi Yan <ziy@nvidia.com>
Acked-by: WANG Xuerui <redacted> # loongarch
---
arch/Kconfig | 6 ++++++
arch/alpha/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/csky/Kconfig | 1 +
arch/hexagon/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/loongarch/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/riscv/Kconfig | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
drivers/video/Kconfig | 3 +++
include/asm-generic/Kbuild | 1 +
include/asm-generic/screen_info.h | 12 ++++++++++++
include/linux/screen_info.h | 2 +-
20 files changed, 38 insertions(+), 1 deletion(-)
create mode 100644 include/asm-generic/screen_info.h
address translations. Page table walkers that clear the
accessed bit
may use this capability to reduce their search space.
+config ARCH_HAS_SCREEN_INFO
+ bool
+ help
+ Selected by architectures that provide a global instance of
+ screen_info.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
@@ -159,7 +159,7 @@ int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)if(!edid&&conn==1){/* try to get from firmware */-constu8*e=fb_firmware_edid(info->device);+constu8*e=fb_firmware_edid(info);if(e!=NULL)edid=kmemdup(e,EDID_LENGTH,GFP_KERNEL);
@@ -227,7 +227,7 @@ int savagefb_probe_i2c_connector(struct fb_info *info, u8 **out_edid)if(!edid){/* try to get from firmware */-constu8*e=fb_firmware_edid(info->device);+constu8*e=fb_firmware_edid(info);if(e)edid=kmemdup(e,EDID_LENGTH,GFP_KERNEL);
This open codes what used to be the fb_is_primary_device() logic before
commit 5ca1479cd35d ("fbdev: Simplify fb_is_primary_device for x86").
But now after that commit there is functional change since the ROM
shadowing check would be dropped.
I believe that's OK and Sima explains in their commit message that
vga_default_device() should be enough and the check is redundant.
Still, I think that this change should be documented in your commit
message.
With that change,
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 12:21:02
Move the empty declaration of fb_firmware_edid() to <linux/fb.h>.
Follow common style and avoid the overhead of exporting the symbol.
No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Randy Dunlap <redacted>
---
drivers/video/fbdev/core/fbmon.c | 7 +------
include/linux/fb.h | 10 +++++++++-
2 files changed, 10 insertions(+), 7 deletions(-)
From: Sui Jingfeng <hidden> Date: 2023-07-05 01:43:22
Hi,
On 2023/6/29 19:45, Thomas Zimmermann wrote:
Guard usage of edid_info with CONFIG_ARCH_HAS_EDID_INFO instead
of CONFIG_X86. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 12:21:13
Various files within drivers/ depend on the declaration of the
screen_info variable. Add this information to Kconfig.
In the case of the dummy console, the dependency exists only
on ARM. Ignore it on !ARM platforms.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <redacted>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Randy Dunlap <redacted>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/firmware/Kconfig | 1 +
drivers/firmware/efi/Kconfig | 1 +
drivers/gpu/drm/Kconfig | 1 +
drivers/hv/Kconfig | 1 +
drivers/video/console/Kconfig | 2 ++
drivers/video/fbdev/Kconfig | 4 ++++
6 files changed, 10 insertions(+)
@@ -366,6 +366,7 @@ source "drivers/gpu/drm/sprd/Kconfig"configDRM_HYPERVtristate"DRM Support for Hyper-V synthetic video device"depends onDRM&&PCI&&MMU&&HYPERV+depends onARCH_HAS_SCREEN_INFOselectDRM_KMS_HELPERselectDRM_GEM_SHMEM_HELPERhelp
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
<asm/screen_info.h>.
Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.
I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?
Arnd
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 13:01:28
Hi
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
<asm/screen_info.h>.
Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.
I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?
FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
announces an architecture feature. They do different things.
Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA
systems. In the future, I want to add support for EDID data from EFI and
OF as well. It would be stored in edid_info. I assume that the new
symbol will become useful then.
Before this patchset, I originally wanted to make use of edid_info in
the simpledrm graphics driver. But I found that the rsp code could use
some work first. Maybe the patchset are already tailored towards the
future changes.
Best regards
Thomas
Arnd
--
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, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
quoted
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
<asm/screen_info.h>.
Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.
I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?
FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
announces an architecture feature. They do different things.
I still have trouble seeing the difference.
Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA
systems. In the future, I want to add support for EDID data from EFI and
OF as well. It would be stored in edid_info. I assume that the new
symbol will become useful then.
I don't see why an OF based system would have the same limitation
as legacy BIOS with supporting only a single monitor, if we need
to have a generic representation of EDID data in DT, that would
probably be in a per device property anyway.
I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.
Arnd
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-30 07:46:42
Hi
Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
quoted
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
quoted
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
<asm/screen_info.h>.
Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.
I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?
FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
announces an architecture feature. They do different things.
I still have trouble seeing the difference.
The idea here is that ARCH_HAS_ signals the architecture's support for
the feature. Drivers set 'depends on' in their Kconfig.
Another Kconfig token, VIDEO_SCREEN_INFO or FIRMWARE_EDID, would then
actually enable the feature. Drivers select VIDEO_SCREEN_INFO or
FIRMWARE_EDID and the architectures contains code like
#ifdef VIDEO_SCREEN_INFO
struct screen_info screen_info = {
/* set values here */
}
#endif
This allows us to disable code that requires screen_info/edid_info, but
also disable screen_info/edid_info unless such code has been enabled in
the kernel config.
Some architectures currently mimic this by guarding screen_info with
ifdef CONFIG_VT or similar. I'd like to make this more flexible. The
cost of a few more internal Kconfig tokens seems negligible.
quoted
Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA
systems. In the future, I want to add support for EDID data from EFI and
OF as well. It would be stored in edid_info. I assume that the new
symbol will become useful then.
I don't see why an OF based system would have the same limitation
as legacy BIOS with supporting only a single monitor, if we need
to have a generic representation of EDID data in DT, that would
probably be in a per device property anyway.
Sorry that was my mistake. OF has nothing to do with this.
I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.
The current code is build on top of screen_info and edid_info. I'd
preferably not replace that, if possible.
Best regards
Thomas
Arnd
--
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 Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote:
Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
quoted
On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
quoted
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
quoted
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
quoted
FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
announces an architecture feature. They do different things.
I still have trouble seeing the difference.
The idea here is that ARCH_HAS_ signals the architecture's support for
the feature. Drivers set 'depends on' in their Kconfig.
Another Kconfig token, VIDEO_SCREEN_INFO or FIRMWARE_EDID, would then
actually enable the feature. Drivers select VIDEO_SCREEN_INFO or
FIRMWARE_EDID and the architectures contains code like
Fair enough. In that case, I guess FIRMWARE_EDID will just depend on
ARCH_HAS_EDID_INFO, or possibly "depends on FIRMWARE_EDID || EFI"
after it starts calling into an EFI specific function, right?
#ifdef VIDEO_SCREEN_INFO
struct screen_info screen_info = {
/* set values here */
}
#endif
This allows us to disable code that requires screen_info/edid_info, but
also disable screen_info/edid_info unless such code has been enabled in
the kernel config.
Some architectures currently mimic this by guarding screen_info with
ifdef CONFIG_VT or similar. I'd like to make this more flexible. The
cost of a few more internal Kconfig tokens seems negligible.
I definitely get it for the screen_info, which needs the complexity.
For ARCHARCH_HAS_EDID_INFO I would hope that it's never selected by
anything other than x86, so I would still go with just a dependency
on x86 for simplicity, but I don't mind having the extra symbol if that
keeps it more consistent with how the screen_info is handled.
quoted
I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.
The current code is build on top of screen_info and edid_info. I'd
preferably not replace that, if possible.
One way I could imagine this looking in the end would be
something like
struct screen_info *fb_screen_info(struct device *dev)
{
struct screen_info *si = NULL;
if (IS_ENABLED(CONFIG_EFI))
si = efi_get_screen_info(dev);
if (IS_ENABLED(CONFIG_ARCH_HAS_SCREEN_INFO) && !si)
si = screen_info;
return si;
}
corresponding to fb_firmware_edid(). With this, any driver
that wants to access screen_info would call this function
instead of using the global pointer, plus either NULL pointer
check or a CONFIG_ARCH_HAS_SCREEN_INFO dependency.
This way we could completely eliminate the global screen_info
on arm64, riscv, and loongarch but still use the efi and
hyperv framebuffer/drm drivers.
Arnd
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-07-05 08:19:33
Hi Arnd
Am 30.06.23 um 13:53 schrieb Arnd Bergmann:
On Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote:
quoted
Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
quoted
On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
quoted
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
quoted
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
quoted
FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
announces an architecture feature. They do different things.
I still have trouble seeing the difference.
The idea here is that ARCH_HAS_ signals the architecture's support for
the feature. Drivers set 'depends on' in their Kconfig.
Another Kconfig token, VIDEO_SCREEN_INFO or FIRMWARE_EDID, would then
actually enable the feature. Drivers select VIDEO_SCREEN_INFO or
FIRMWARE_EDID and the architectures contains code like
Fair enough. In that case, I guess FIRMWARE_EDID will just depend on
ARCH_HAS_EDID_INFO, or possibly "depends on FIRMWARE_EDID || EFI"
after it starts calling into an EFI specific function, right?
quoted
#ifdef VIDEO_SCREEN_INFO
struct screen_info screen_info = {
/* set values here */
}
#endif
This allows us to disable code that requires screen_info/edid_info, but
also disable screen_info/edid_info unless such code has been enabled in
the kernel config.
Some architectures currently mimic this by guarding screen_info with
ifdef CONFIG_VT or similar. I'd like to make this more flexible. The
cost of a few more internal Kconfig tokens seems negligible.
I definitely get it for the screen_info, which needs the complexity.
For ARCHARCH_HAS_EDID_INFO I would hope that it's never selected by
anything other than x86, so I would still go with just a dependency
on x86 for simplicity, but I don't mind having the extra symbol if that
keeps it more consistent with how the screen_info is handled.
Well, I'd like to add edid_info to platforms with EFI. What would be
arm/arm64 and loongarch, I guess. See below for the future plans.
quoted
quoted
I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.
The current code is build on top of screen_info and edid_info. I'd
preferably not replace that, if possible.
One way I could imagine this looking in the end would be
something like
struct screen_info *fb_screen_info(struct device *dev)
{
struct screen_info *si = NULL;
if (IS_ENABLED(CONFIG_EFI))
si = efi_get_screen_info(dev);
if (IS_ENABLED(CONFIG_ARCH_HAS_SCREEN_INFO) && !si)
si = screen_info;
return si;
}
corresponding to fb_firmware_edid(). With this, any driver
that wants to access screen_info would call this function
instead of using the global pointer, plus either NULL pointer
check or a CONFIG_ARCH_HAS_SCREEN_INFO dependency.
This way we could completely eliminate the global screen_info
on arm64, riscv, and loongarch but still use the efi and
hyperv framebuffer/drm drivers.
If possible, I'd like to remove global screen_info and edid_info
entirely from fbdev and the various consoles.
We currently use screen_info to set up the generic framebuffer device in
drivers/firmware/sysfb.c. I'd like to use edid_info here as well, so
that the generic graphics drivers can get EDID information.
For the few fbdev drivers and consoles that require the global
screen_info/edid_info, I'd rather provide lookup functions in sysfb
(e.g., sysfb_get_screen_info(), sysfb_get_edid_info()). The global
screen_info/edid_info state would then become an internal artifact of
the sysfb code.
Hopefully that explains some of the decisions made in this patchset.
Best regards
Thomas
Arnd
--
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 Wed, Jul 5, 2023, at 10:18, Thomas Zimmermann wrote:
Am 30.06.23 um 13:53 schrieb Arnd Bergmann:
quoted
On Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote:
quoted
Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
I definitely get it for the screen_info, which needs the complexity.
For ARCHARCH_HAS_EDID_INFO I would hope that it's never selected by
anything other than x86, so I would still go with just a dependency
on x86 for simplicity, but I don't mind having the extra symbol if that
keeps it more consistent with how the screen_info is handled.
Well, I'd like to add edid_info to platforms with EFI. What would be
arm/arm64 and loongarch, I guess. See below for the future plans.
To be clear: I don't mind using a 'struct edid_info' being passed
around between subsystems, that is clearly an improvement over
'struct screen_info'. It's the global variable that seems like
an artifact of linux-2.4 days, and I think we can do better than that.
quoted
quoted
quoted
I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.
The current code is build on top of screen_info and edid_info. I'd
preferably not replace that, if possible.
One way I could imagine this looking in the end would be
something like
struct screen_info *fb_screen_info(struct device *dev)
{
struct screen_info *si = NULL;
if (IS_ENABLED(CONFIG_EFI))
si = efi_get_screen_info(dev);
if (IS_ENABLED(CONFIG_ARCH_HAS_SCREEN_INFO) && !si)
si = screen_info;
return si;
}
corresponding to fb_firmware_edid(). With this, any driver
that wants to access screen_info would call this function
instead of using the global pointer, plus either NULL pointer
check or a CONFIG_ARCH_HAS_SCREEN_INFO dependency.
This way we could completely eliminate the global screen_info
on arm64, riscv, and loongarch but still use the efi and
hyperv framebuffer/drm drivers.
If possible, I'd like to remove global screen_info and edid_info
entirely from fbdev and the various consoles.
ok
We currently use screen_info to set up the generic framebuffer device in
drivers/firmware/sysfb.c. I'd like to use edid_info here as well, so
that the generic graphics drivers can get EDID information.
For the few fbdev drivers and consoles that require the global
screen_info/edid_info, I'd rather provide lookup functions in sysfb
(e.g., sysfb_get_screen_info(), sysfb_get_edid_info()). The global
screen_info/edid_info state would then become an internal artifact of
the sysfb code.
Hopefully that explains some of the decisions made in this patchset.
I spent some more time looking at the screen_info side, after my
first set of patches to refine the #ifdefs, and I think we don't
even need to make screen_info available to non-x86 drivers at all:
- All the vgacon users except for x86 can just register a static
screen_info (or simplified into a simpler structure) with the
driver itself. This even includes ia64, which does not support
EFI framebuffers.
- The VESA, vga16, SIS, Intel and HyperV framebuffer drivers only
need access to screen_info on x86. HyperV is the only driver that
can currently access the data from EFI firmware on arm64, but
that is only used for 'gen 1' guests, which I'm pretty sure
only exist on x86.
- All the other references to screen_info are specific to EFI
firmware, so we can move the global definition from arm,
arm64, loongarch, riscv and ia64 into the EFI firmware
code itself. It is still accessed by efifb and efi-earlycon
at this point.
I have uploaded version 2 of my series to
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=screen-info-v2
and will send it out after I get the green light from build
bots.
Arnd
@@ -260,7 +260,7 @@ config PERMIT_BSP_REMOVEdefaultnhelpSayYhereifyourplatformSALwillsupportremovalofBSPwithHOTPLUG_CPU-support.+support.configFORCE_CPEI_RETARGETbool"Force assumption that CPEI can be re-targeted"
@@ -260,7 +260,7 @@ config PERMIT_BSP_REMOVEdefaultnhelpSayYhereifyourplatformSALwillsupportremovalofBSPwithHOTPLUG_CPU-support.+support.configFORCE_CPEI_RETARGETbool"Force assumption that CPEI can be re-targeted"
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
The variables screen_info and edid_info provide information about
the system's screen, and possibly EDID data of the connected display.
Both are defined and set by architecture code. But both variables are
declared in non-arch header files. Dependencies are at bease loosely
tracked. To resolve this, move the global state screen_info and its
companion edid_info into arch/. Only declare them on architectures
that define them. List dependencies on the variables in the Kconfig
files. Also clean up the callers.
Patch 1 to 4 resolve a number of unnecessary include statements of
<linux/screen_info.h>. The header should only be included in source
files that access struct screen_info.
Patches 5 to 7 move the declaration of screen_info and edid_info to
<asm-generic/screen_info.h>. Architectures that provide either set
a Kconfig token to enable them.
Patches 8 to 9 make users of screen_info depend on the architecture's
feature.
Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
data to make use of existing helpers and the refactored edid_info.
Tested on x86-64. Built for a variety of platforms.
This all looks like a nice cleanup!
Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.
I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.
We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.
Arnd
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2023-06-29 14:16:27
Hi
Am 29.06.23 um 15:31 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
The variables screen_info and edid_info provide information about
the system's screen, and possibly EDID data of the connected display.
Both are defined and set by architecture code. But both variables are
declared in non-arch header files. Dependencies are at bease loosely
tracked. To resolve this, move the global state screen_info and its
companion edid_info into arch/. Only declare them on architectures
that define them. List dependencies on the variables in the Kconfig
files. Also clean up the callers.
Patch 1 to 4 resolve a number of unnecessary include statements of
<linux/screen_info.h>. The header should only be included in source
files that access struct screen_info.
Patches 5 to 7 move the declaration of screen_info and edid_info to
<asm-generic/screen_info.h>. Architectures that provide either set
a Kconfig token to enable them.
Patches 8 to 9 make users of screen_info depend on the architecture's
feature.
Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
data to make use of existing helpers and the refactored edid_info.
Tested on x86-64. Built for a variety of platforms.
This all looks like a nice cleanup!
I guess that patches 1 to 4 are uncontroversial and could be landed
quickly. Patches 10 to 12 are probably as well.
quoted
Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.
I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.
That's quite possible. Only x86's bootparam and EFI code sets
screen_info from external data. The rest is hardcoded. A number of
architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. In a later patchset, I wanted to change this such that these users
of screen_info would enable the feature via select in their Kconfig.
Do you know the reason for this branch in dummycon:
https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21
What is special about arm that dummycon uses the screeninfo?
We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.
Can you elaborate?
Best regards
Thomas
Arnd
--
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, Jun 29, 2023, at 16:15, Thomas Zimmermann wrote:
Am 29.06.23 um 15:31 schrieb Arnd Bergmann:
quoted
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.
I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.
That's quite possible. Only x86's bootparam and EFI code sets
screen_info from external data. The rest is hardcoded. A number of
architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. In a later patchset, I wanted to change this such that these users
of screen_info would enable the feature via select in their Kconfig.
Do you know the reason for this branch in dummycon:
https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21
What is special about arm that dummycon uses the screeninfo?
I can only guess myself, but I see that the values are only ever
set from the old ATAGS data, and not from DT on any of the
modern ones, and my interpretation is that this is meant to
match whatever the vga console was set to on the three
platforms that support vgacon.
I see this was added in linux-2.1.111, just before the
corresponding sparc specific hack was removed, but I don't have
patch descriptions from that era. Russell might remember, or know
if that is actually still needed.
Arnd
On Thu, Jun 29, 2023, at 15:31, Arnd Bergmann wrote:
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
quoted
Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.
I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.
We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.
I tried to have another look at who uses what, and here are
some observations:
- EFIFB and hyperv are the only ones that are relevant on modern
systmes, and they are only used on systems using EFI, so they
could use a separate data structure that is defined as part of
drivers/firmware/efi. This would likely mean we don't have to
define a separate screen_info for arm64, loongarch, ia64 and
riscv, and could separate the legacy vgacon/vesafb stuff on
arm32 from the efi side.
- FB_SIS can likely be marked 'depends on X86' like FB_INTEL,
it seems to depend on x86 BOOT_VESA_SUPPORT.
- FB_VGA16 is currently support on powerpc and enabled on
one defconfig (pasemi), which I'm fairly sure is a mistake,
so this could be made x86 specific as well.
- VGA_CONSOLE has a complicated Kconfig dependency list that
lists platforms without VGA support but I think this is better
expressed with a positive list. It looks like csky, hexagon,
nios2 and xtensa should be excluded here and not provide
screen_info.
- arm and mips only need to provide screen_info on machines
with VGA_CONSOLE. On Arm we have a dependency on
footbridge/integrator/netwinder, while on mips the
dependency can be added to the platforms that fill
the info (mips, malta, sibyte, sni).
- DUMMY_CONSOLE only uses screen_info on arm, and this should
likely be limited to the three obsolete machines that
support VGACON. Almost all Arm machines use DT these days
and won't ever fill the screen info dynamically.
Arnd