| Message ID | 20230629121952.10559-8-tzimmermann@suse.de (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | arch,fbdev: Move screen_info into arch/ | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/tree_selection | fail | Failed to apply to next/pending-fixes, riscv/for-next or riscv/master |
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
Hi Am 29.06.23 um 14:35 schrieb Arnd Bergmann: > 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? 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
On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote: > Am 29.06.23 um 14:35 schrieb Arnd Bergmann: >> 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? > > 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
Hi Am 29.06.23 um 15:21 schrieb Arnd Bergmann: > On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote: >> Am 29.06.23 um 14:35 schrieb Arnd Bergmann: >>> 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? >> >> 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. > >> 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
On Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote: > Am 29.06.23 um 15:21 schrieb Arnd Bergmann: >> On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote: >>> Am 29.06.23 um 14:35 schrieb Arnd Bergmann: >>>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote: > >>> >>> 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. >> 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
Hi Arnd Am 30.06.23 um 13:53 schrieb Arnd Bergmann: > On Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote: >> Am 29.06.23 um 15:21 schrieb Arnd Bergmann: >>> On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote: >>>> Am 29.06.23 um 14:35 schrieb Arnd Bergmann: >>>>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote: >> >>>> >>>> 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. 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. > >>> 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
On Wed, Jul 5, 2023, at 10:18, Thomas Zimmermann wrote: > Am 30.06.23 um 13:53 schrieb Arnd Bergmann: >> On Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote: >>> 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. >>>> 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
diff --git a/arch/Kconfig b/arch/Kconfig index 2f58293fd7bcb..ee9866e4df2b0 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -1466,6 +1466,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG address translations. Page table walkers that clear the accessed bit may use this capability to reduce their search space. +config ARCH_HAS_EDID_INFO + bool + help + Selected by architectures that provide a global instance of + edid_info. + config ARCH_HAS_SCREEN_INFO bool help diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d7c2bf4ee403d..ee81855116be7 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -76,6 +76,7 @@ config X86 select ARCH_HAS_DEBUG_VM_PGTABLE if !X86_PAE select ARCH_HAS_DEVMEM_IS_ALLOWED select ARCH_HAS_EARLY_DEBUG if KGDB + select ARCH_HAS_EDID_INFO select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_FAST_MULTIPLIER select ARCH_HAS_FORTIFY_SOURCE diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index d4a72bea56be0..8b2b9ac37c3df 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -21,9 +21,6 @@ config STI_CORE config VIDEO_CMDLINE bool -config ARCH_HAS_SCREEN_INFO - bool - config VIDEO_NOMODESET bool default n diff --git a/include/asm-generic/screen_info.h b/include/asm-generic/screen_info.h index 6fd0e50fabfcd..5efc99c296b40 100644 --- a/include/asm-generic/screen_info.h +++ b/include/asm-generic/screen_info.h @@ -5,6 +5,12 @@ #include <uapi/linux/screen_info.h> +#include <video/edid.h> + +#if defined(CONFIG_ARCH_HAS_EDID_INFO) +extern struct edid_info edid_info; +#endif + #if defined(CONFIG_ARCH_HAS_SCREEN_INFO) extern struct screen_info screen_info; #endif diff --git a/include/video/edid.h b/include/video/edid.h index f614371e9116a..52aabb7060321 100644 --- a/include/video/edid.h +++ b/include/video/edid.h @@ -4,7 +4,4 @@ #include <uapi/video/edid.h> -#ifdef CONFIG_X86 -extern struct edid_info edid_info; -#endif #endif /* __linux_video_edid_h__ */
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. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> 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: Helge Deller <deller@gmx.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Frederic Weisbecker <frederic@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Juerg Haefliger <juerg.haefliger@canonical.com> --- arch/Kconfig | 6 ++++++ arch/x86/Kconfig | 1 + drivers/video/Kconfig | 3 --- include/asm-generic/screen_info.h | 6 ++++++ include/video/edid.h | 3 --- 5 files changed, 13 insertions(+), 6 deletions(-)