diff mbox series

[07/12] arch/x86: Declare edid_info in <asm/screen_info.h>

Message ID 20230629121952.10559-8-tzimmermann@suse.de
State New
Headers show
Series arch,fbdev: Move screen_info into arch/ | expand

Commit Message

Thomas Zimmermann June 29, 2023, 11:45 a.m. UTC
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(-)

Comments

Arnd Bergmann June 29, 2023, 12:35 p.m. UTC | #1
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
Thomas Zimmermann June 29, 2023, 1:01 p.m. UTC | #2
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
Arnd Bergmann June 29, 2023, 1:21 p.m. UTC | #3
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
Thomas Zimmermann June 30, 2023, 7:46 a.m. UTC | #4
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
Arnd Bergmann June 30, 2023, 11:53 a.m. UTC | #5
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
Thomas Zimmermann July 5, 2023, 8:18 a.m. UTC | #6
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
Arnd Bergmann July 18, 2023, 2:47 p.m. UTC | #7
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 mbox series

Patch

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__ */