| Message ID | 20230629121952.10559-1-tzimmermann@suse.de |
|---|---|
| Headers | show |
| Series | arch,fbdev: Move screen_info into arch/ | expand |
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
Hi Am 29.06.23 um 15:03 schrieb Arnd Bergmann: > On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote: > >> diff --git a/include/asm-generic/screen_info.h >> b/include/asm-generic/screen_info.h >> new file mode 100644 >> index 0000000000000..6fd0e50fabfcd >> --- /dev/null >> +++ b/include/asm-generic/screen_info.h >> @@ -0,0 +1,12 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> + >> +#ifndef _ASM_GENERIC_SCREEN_INFO_H >> +#define _ASM_GENERIC_SCREEN_INFO_H >> + >> +#include <uapi/linux/screen_info.h> >> + >> +#if defined(CONFIG_ARCH_HAS_SCREEN_INFO) >> +extern struct screen_info screen_info; >> +#endif >> + >> +#endif /* _ASM_GENERIC_SCREEN_INFO_H */ >> diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h >> index eab7081392d50..c764b9a51c24b 100644 >> --- a/include/linux/screen_info.h >> +++ b/include/linux/screen_info.h >> @@ -4,6 +4,6 @@ >> >> #include <uapi/linux/screen_info.h> >> >> -extern struct screen_info screen_info; >> +#include <asm/screen_info.h> >> > > 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
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
On Thu, Jun 29, 2023, at 15:31, Arnd Bergmann wrote: > On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote: >> >> 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
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