From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:55:39
Detect the firmware framebuffer's parent device from the global
screen_info state and set up the framebuffer's device accordingly.
Remove the equivalent functionality from efifb. Other drivers for
firmware framebuffers, such as simpledrm or vesafb, now add these
new features.
Patches 1 and 2 provide a set of helper functions to avoid parsing
the screen_info values manually. Decoding screen_info is fragile and
many drivers get it wrong. We should later adopt these helpers in
existing drivers, such as efifb, vesafb, as well.
Patches 3 and 4 set the firmware framebuffer's parent device. There
is code in efifb to do something similar for power management. That
is now obsolete and being cleaned up. Setting the parent device makes
Linux track the power management correctly.
Patches 5 and 6 track the parent device's enable state. We don't
create framebuffer devices if the underlying hardware device has been
disabled. Remove the functionality from efifb.
Patches 7 and 8 track the parent device's PCI BAR location. It can
happen on aarch64 that the firmware framebuffer moves its location
during the kernel's boot. We now fix up the screen_info state to
point to the correct location. Again remove such functionality from
efifb.
Thomas Zimmermann (8):
video: Add helpers for decoding screen_info
video: Provide screen_info_get_pci_dev() to find screen_info's PCI
device
firmware/sysfb: Set firmware-framebuffer parent device
fbdev/efifb: Remove PM for parent device
firmware/sysfb: Create firmware device only for enabled PCI devices
fbdev/efifb: Do not track parent device status
firmware/sysfb: Update screen_info for relocated EFI framebuffers
fbdev/efifb: Remove framebuffer relocation tracking
drivers/firmware/Kconfig | 1 +
drivers/firmware/sysfb.c | 37 ++++++-
drivers/firmware/sysfb_simplefb.c | 5 +-
drivers/video/Kconfig | 4 +
drivers/video/Makefile | 4 +
drivers/video/fbdev/efifb.c | 97 +-----------------
drivers/video/screen_info_generic.c | 148 ++++++++++++++++++++++++++++
drivers/video/screen_info_pci.c | 142 ++++++++++++++++++++++++++
include/linux/screen_info.h | 126 +++++++++++++++++++++++
include/linux/sysfb.h | 3 +-
10 files changed, 472 insertions(+), 95 deletions(-)
create mode 100644 drivers/video/screen_info_generic.c
create mode 100644 drivers/video/screen_info_pci.c
--
2.43.0
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:55:33
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux device hierarchy and lets Linux handle dependencies among
devices. For example, the graphics hardware won't be suspended while
the firmware device is still active.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/sysfb.c | 11 ++++++++++-
drivers/firmware/sysfb_simplefb.c | 5 ++++-
include/linux/sysfb.h | 3 ++-
3 files changed, 16 insertions(+), 3 deletions(-)
@@ -83,10 +86,14 @@ static __init int sysfb_init(void)sysfb_apply_efi_quirks();+pparent=screen_info_pci_dev(si);+if(pparent)+parent=&pparent->dev;+/* try to create a simple-framebuffer device */compatible=sysfb_parse_mode(si,&mode);if(compatible){-pd=sysfb_create_simplefb(si,&mode);+pd=sysfb_create_simplefb(si,&mode,parent);if(!IS_ERR(pd))gotounlock_mutex;}
@@ -109,6 +116,8 @@ static __init int sysfb_init(void)gotounlock_mutex;}+pd->dev.parent=parent;+sysfb_set_efifb_fwnode(pd);ret=platform_device_add_data(pd,si,sizeof(*si));
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 11:29:00
Thomas Zimmermann [off-list ref] writes:
quoted hunk
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux device hierarchy and lets Linux handle dependencies among
devices. For example, the graphics hardware won't be suspended while
the firmware device is still active.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/sysfb.c | 11 ++++++++++-
drivers/firmware/sysfb_simplefb.c | 5 ++++-
include/linux/sysfb.h | 3 ++-
3 files changed, 16 insertions(+), 3 deletions(-)
Maybe pci_parent? It's easier to read than pparent IMO.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:56:03
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems may not set the type of video directly, but
only indicate the presence by storing 0x01 in orig_video_isVGA. The
decoding logic in screen_info_video_type() takes this into account.
It then follows similar code in vgacon's vgacon_startup() to detect
the video type from the given values.
A call to screen_info_resources() returns all known resources of the
given screen_info. The resources' values have been taken from existing
code in vgacon and vga16fb. These drivers can later be converted to
use the new interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/Kconfig | 1 +
drivers/video/Kconfig | 4 +
drivers/video/Makefile | 3 +
drivers/video/screen_info_generic.c | 148 ++++++++++++++++++++++++++++
include/linux/screen_info.h | 100 +++++++++++++++++++
5 files changed, 256 insertions(+)
create mode 100644 drivers/video/screen_info_generic.c
@@ -4,6 +4,106 @@#include<uapi/linux/screen_info.h>+/**+*SCREEN_INFO_MAX_RESOURCES-maximumnumberofresourcesperscreen_info+*/+#define SCREEN_INFO_MAX_RESOURCES 3++structresource;++staticinlinebool__screen_info_has_lfb(unsignedinttype)+{+return(type==VIDEO_TYPE_VLFB)||(type==VIDEO_TYPE_EFI);+}++staticinlineu64__screen_info_lfb_base(conststructscreen_info*si)+{+u64lfb_base=si->lfb_base;++if(si->capabilities&VIDEO_CAPABILITY_64BIT_BASE)+lfb_base|=(u64)si->ext_lfb_base<<32;++returnlfb_base;+}++staticinlineu64__screen_info_lfb_size(conststructscreen_info*si,unsignedinttype)+{+u64lfb_size=si->lfb_size;++if(type==VIDEO_TYPE_VLFB)+lfb_size<<=16;+returnlfb_size;+}++staticinlineunsignedint__screen_info_video_type(unsignedinttype)+{+switch(type){+caseVIDEO_TYPE_MDA:+caseVIDEO_TYPE_CGA:+caseVIDEO_TYPE_EGAM:+caseVIDEO_TYPE_EGAC:+caseVIDEO_TYPE_VGAC:+caseVIDEO_TYPE_VLFB:+caseVIDEO_TYPE_PICA_S3:+caseVIDEO_TYPE_MIPS_G364:+caseVIDEO_TYPE_SGI:+caseVIDEO_TYPE_TGAC:+caseVIDEO_TYPE_SUN:+caseVIDEO_TYPE_SUNPCI:+caseVIDEO_TYPE_PMAC:+caseVIDEO_TYPE_EFI:+returntype;+default:+return0;+}+}++/**+*screen_info_video_type()-Decodesthevideotypefromstructscreen_info+*@si:aninstanceofstructscreen_info+*+*Returns:+*AVIDEO_TYPE_constantrepresentingsi'stypeofvideodisplay,or0otherwise.+*/+staticinlineunsignedintscreen_info_video_type(conststructscreen_info*si)+{+unsignedinttype;++// check if display output is on+if(!si->orig_video_isVGA)+return0;++// check for a known VIDEO_TYPE_ constant+type=__screen_info_video_type(si->orig_video_isVGA);+if(type)+returnsi->orig_video_isVGA;++// check if text mode has been initialized+if(!si->orig_video_lines||!si->orig_video_cols)+return0;++// 80x25 text, mono+if(si->orig_video_mode==0x07){+if((si->orig_video_ega_bx&0xff)!=0x10)+returnVIDEO_TYPE_EGAM;+else+returnVIDEO_TYPE_MDA;+}++// EGA/VGA, 16 colors+if((si->orig_video_ega_bx&0xff)!=0x10){+if(si->orig_video_isVGA)+returnVIDEO_TYPE_VGAC;+else+returnVIDEO_TYPE_EGAC;+}++// the rest...+returnVIDEO_TYPE_CGA;+}++intscreen_info_resources(conststructscreen_info*si,structresource*r,size_tnum);+externstructscreen_infoscreen_info;#endif /* _SCREEN_INFO_H */
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 10:41:22
Thomas Zimmermann [off-list ref] writes:
Hello Thomas,
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems may not set the type of video directly, but
only indicate the presence by storing 0x01 in orig_video_isVGA. The
decoding logic in screen_info_video_type() takes this into account.
I always disliked how the orig_video_isVGA variable lost its meaning.
It then follows similar code in vgacon's vgacon_startup() to detect
the video type from the given values.
A call to screen_info_resources() returns all known resources of the
given screen_info. The resources' values have been taken from existing
code in vgacon and vga16fb. These drivers can later be converted to
use the new interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
Thanks for doing this! It's quite useful to have these helpers, since as
you mention the screen_info data decoding is complex and the variables
used to store the video type and modes are confusing / misleading.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
I just have a few comments below:
+static inline bool __screen_info_has_ega_gfx(unsigned int mode)
+{
+ switch (mode) {
+ case 0x0d: /* 320x200-4 */
+ case 0x0e: /* 640x200-4 */
+ case 0x0f: /* 640x350-1 */
+ case 0x10: /* 640x350-4 */
I wonder if makes sense to define some constant macros for these modes? I
know that check_mode_supported() in drivers/video/fbdev/vga16fb.c also use
magic numbers but I believe that it could ease readability.
I see that drivers/video/fbdev/i740_reg.h has a #define MDA_BASE
0x3B0. Maybe move to a header in include/video along with the other
constants mentioned above ?
+ if (num > 1)
+ resource_init_io_named(pos++, 0x3bf, 0x01, "mda");
+ if (num > 2)
+ resource_init_mem_named(pos++, 0xb0000, 0x2000, "mda");
Same for these start addresses. I see that are also used by mdacon_startup()
in drivers/video/console/mdacon.c, so some constants defined somewhere might
be useful for that console driver too.
The comment also applies to all the other start addresses, since I see
that those are used by other drivers (i810, vgacon, etc).
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-30 13:12:36
Hi
Am 29.01.24 um 11:41 schrieb Javier Martinez Canillas:
Thomas Zimmermann [off-list ref] writes:
Hello Thomas,
quoted
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems may not set the type of video directly, but
only indicate the presence by storing 0x01 in orig_video_isVGA. The
decoding logic in screen_info_video_type() takes this into account.
I always disliked how the orig_video_isVGA variable lost its meaning.
quoted
It then follows similar code in vgacon's vgacon_startup() to detect
the video type from the given values.
A call to screen_info_resources() returns all known resources of the
given screen_info. The resources' values have been taken from existing
code in vgacon and vga16fb. These drivers can later be converted to
use the new interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
Thanks for doing this! It's quite useful to have these helpers, since as
you mention the screen_info data decoding is complex and the variables
used to store the video type and modes are confusing / misleading.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
I just have a few comments below:
quoted
+static inline bool __screen_info_has_ega_gfx(unsigned int mode)
+{
+ switch (mode) {
+ case 0x0d: /* 320x200-4 */
+ case 0x0e: /* 640x200-4 */
+ case 0x0f: /* 640x350-1 */
+ case 0x10: /* 640x350-4 */
I wonder if makes sense to define some constant macros for these modes? I
know that check_mode_supported() in drivers/video/fbdev/vga16fb.c also use
magic numbers but I believe that it could ease readability.
They are known by their numbers, but have no names. There's also no
common practice or precedence I'm aware of.
OTOH, drivers like vga16fb should no longer have to test magic numbers
at all. They bind to a certain type of device, such as ega-txt and
vga-gfx, which implies a correctly set mode.
I see that drivers/video/fbdev/i740_reg.h has a #define MDA_BASE
0x3B0. Maybe move to a header in include/video along with the other
constants mentioned above ?
That could go into <video/vga.h>. MDA_BASE (and CGA_BASE) from the same
file are unused though.
Best regards
Thomas
quoted
+ if (num > 1)
+ resource_init_io_named(pos++, 0x3bf, 0x01, "mda");
+ if (num > 2)
+ resource_init_mem_named(pos++, 0xb0000, 0x2000, "mda");
Same for these start addresses. I see that are also used by mdacon_startup()
in drivers/video/console/mdacon.c, so some constants defined somewhere might
be useful for that console driver too.
The comment also applies to all the other start addresses, since I see
that those are used by other drivers (i810, vgacon, etc).
--
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)
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:56:06
The EFI device has the correct parent device set. This allows Linux
to handle the power management internally. Hence, remove the manual
PM management for the parent device from efifb.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/efifb.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 11:30:13
Thomas Zimmermann [off-list ref] writes:
The EFI device has the correct parent device set. This allows Linux
to handle the power management internally. Hence, remove the manual
PM management for the parent device from efifb.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.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: 2024-01-17 12:56:08
On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.
Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the screen_info state
between reloaction and creating the firmware framebuffer's device.
This functionality has been lifted from efifb. See the commit message
of commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that
covers the framebuffer") for more information.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/sysfb.c | 2 +
drivers/video/screen_info_pci.c | 88 +++++++++++++++++++++++++++++++++
include/linux/screen_info.h | 16 ++++++
3 files changed, 106 insertions(+)
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 11:52:40
Thomas Zimmermann [off-list ref] writes:
On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.
Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the screen_info state
between reloaction and creating the firmware framebuffer's device.
This functionality has been lifted from efifb. See the commit message
of commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that
covers the framebuffer") for more information.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
[...]
#if defined(CONFIG_PCI)
Shouldn't this be && !defined(CONFIG_X86) ? Or maybe &&
defined(CONFIG_ARM64), although I don't know if the same
also applies to other EFI platforms (e.g: CONFIG_RISCV).
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 12:03:22
Javier Martinez Canillas [off-list ref] writes:
Thomas Zimmermann [off-list ref] writes:
quoted
On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.
Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the screen_info state
between reloaction and creating the firmware framebuffer's device.
This functionality has been lifted from efifb. See the commit message
of commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that
covers the framebuffer") for more information.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
[...]
quoted
#if defined(CONFIG_PCI)
Shouldn't this be && !defined(CONFIG_X86) ? Or maybe &&
defined(CONFIG_ARM64), although I don't know if the same
also applies to other EFI platforms (e.g: CONFIG_RISCV).
Answering my own question, the !defined(CONFIG_X86) was dropped in the commit
dcf8f5ce3165 ("drivers/fbdev/efifb: Allow BAR to be moved instead of claiming
it"). The rationale is explained in that commit message:
While this is less likely to occur on x86, given that the firmware's
PCI resource allocation is more likely to be preserved, this is a
worthwhile sanity check to have in place, and so let's remove the
preprocessor conditional that makes it !X86 only.
So it is OK to just guard with #if defined(CONFIG_PCI).
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:56:11
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/Makefile | 1 +
drivers/video/screen_info_pci.c | 54 +++++++++++++++++++++++++++++++++
include/linux/screen_info.h | 10 ++++++
3 files changed, 65 insertions(+)
create mode 100644 drivers/video/screen_info_pci.c
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 11:04:40
Thomas Zimmermann [off-list ref] writes:
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
[...]
+struct pci_dev *screen_info_pci_dev(const struct screen_info *si)
+{
+ struct resource res[SCREEN_INFO_MAX_RESOURCES];
+ size_t i, numres;
+ int ret;
+
+ ret = screen_info_resources(si, res, ARRAY_SIZE(res));
+ if (ret < 0)
+ return ERR_PTR(ret);
+ numres = ret;
+
I would just drop the ret variable and assign the screen_info_resources()
return value to numres. I think that makes the code easier to follow.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-30 10:12:36
Hi
Am 29.01.24 um 12:04 schrieb Javier Martinez Canillas:
Thomas Zimmermann [off-list ref] writes:
quoted
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
[...]
quoted
+struct pci_dev *screen_info_pci_dev(const struct screen_info *si)
+{
+ struct resource res[SCREEN_INFO_MAX_RESOURCES];
+ size_t i, numres;
+ int ret;
+
+ ret = screen_info_resources(si, res, ARRAY_SIZE(res));
+ if (ret < 0)
+ return ERR_PTR(ret);
+ numres = ret;
+
I would just drop the ret variable and assign the screen_info_resources()
return value to numres. I think that makes the code easier to follow.
The value of ret could be an errno code. We would effectively return
NULL for errors. And I just noticed that the function docs imply this.
But NULL is also a valid value if there is no PCI device. I'd prefer to
keep the errno-pointer around.
Best regards
Thomas
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
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)
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-30 10:23:56
Thomas Zimmermann [off-list ref] writes:
Hi
Am 29.01.24 um 12:04 schrieb Javier Martinez Canillas:
quoted
Thomas Zimmermann [off-list ref] writes:
quoted
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
[...]
quoted
+struct pci_dev *screen_info_pci_dev(const struct screen_info *si)
+{
+ struct resource res[SCREEN_INFO_MAX_RESOURCES];
+ size_t i, numres;
+ int ret;
+
+ ret = screen_info_resources(si, res, ARRAY_SIZE(res));
+ if (ret < 0)
+ return ERR_PTR(ret);
+ numres = ret;
+
I would just drop the ret variable and assign the screen_info_resources()
return value to numres. I think that makes the code easier to follow.
The value of ret could be an errno code. We would effectively return
NULL for errors. And I just noticed that the function docs imply this.
But NULL is also a valid value if there is no PCI device. I'd prefer to
keep the errno-pointer around.
Yes. I meant making numres an int instead of size_t (SCREEN_INFO_MAX_RESOURCES
is only 3 after all). That way you could just return ERR_PTR(numres) if is < 0.
No strong preference, just think that the code is easier to read in that case.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:56:13
There will be no EFI framebuffer device for disabled parent devices
and thus we never probe efifb in that case. Hence remove the tracking
code from efifb.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/efifb.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
@@ -348,8 +348,6 @@ static struct attribute *efifb_attrs[] = {};ATTRIBUTE_GROUPS(efifb);-staticboolpci_dev_disabled;/* FB base matches BAR of a disabled device */-staticstructresource*bar_resource;staticu64bar_offset;
@@ -377,7 +375,7 @@ static int efifb_probe(struct platform_device *dev)if(!si)return-ENOMEM;-if(si->orig_video_isVGA!=VIDEO_TYPE_EFI||pci_dev_disabled)+if(si->orig_video_isVGA!=VIDEO_TYPE_EFI)return-ENODEV;if(fb_get_options("efifb",&option))
@@ -653,7 +651,6 @@ static void record_efifb_bar_resource(struct pci_dev *dev, int idx, u64 offset)pci_read_config_word(dev,PCI_COMMAND,&word);if(!(word&PCI_COMMAND_MEMORY)){-pci_dev_disabled=true;dev_err(&dev->dev,"BAR %d: assigned to efifb but device is disabled!\n",idx);
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 11:38:40
Thomas Zimmermann [off-list ref] writes:
There will be no EFI framebuffer device for disabled parent devices
and thus we never probe efifb in that case. Hence remove the tracking
code from efifb.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
Nice cleanup.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:56:15
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabled PCI devices.
So far, efifb tracked the status of the PCI parent device internally
and did not bind if it was disabled. This patch implements the
functionality for all firmware framebuffers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/sysfb.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
@@ -70,6 +70,27 @@ void sysfb_disable(void)}EXPORT_SYMBOL_GPL(sysfb_disable);+static__initboolsysfb_pci_dev_is_enabled(structpci_dev*pdev)+{+#if defined(CONFIG_PCI)+/*+*TODO:TrytointegratethiscodeintothePCIsubsystem+*/+intret;+u16command;++ret=pci_read_config_word(pdev,PCI_COMMAND,&command);+if(ret!=PCIBIOS_SUCCESSFUL)+returnfalse;+if(!(command&PCI_COMMAND_MEMORY))+returnfalse;+returntrue;+#else+// Getting here without PCI support is probably a bug.+returnfalse;+#endif+}+static__initintsysfb_init(void){conststructscreen_info*si=&screen_info;
@@ -87,8 +108,11 @@ static __init int sysfb_init(void)sysfb_apply_efi_quirks();pparent=screen_info_pci_dev(si);-if(pparent)+if(pparent){+if(!sysfb_pci_dev_is_enabled(pparent))+gotounlock_mutex;parent=&pparent->dev;+}/* try to create a simple-framebuffer device */compatible=sysfb_parse_mode(si,&mode);
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 11:36:10
Thomas Zimmermann [off-list ref] writes:
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabled PCI devices.
So far, efifb tracked the status of the PCI parent device internally
and did not bind if it was disabled. This patch implements the
functionality for all firmware framebuffers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
[...]
+static __init bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
+{
+#if defined(CONFIG_PCI)
+ /*
+ * TODO: Try to integrate this code into the PCI subsystem
+ */
+ int ret;
+ u16 command;
+
+ ret = pci_read_config_word(pdev, PCI_COMMAND, &command);
+ if (ret != PCIBIOS_SUCCESSFUL)
+ return false;
+ if (!(command & PCI_COMMAND_MEMORY))
+ return false;
+ return true;
+#else
+ // Getting here without PCI support is probably a bug.
+ return false;
Should we warn before return in this case ?
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-30 12:53:32
Hi
Am 29.01.24 um 12:36 schrieb Javier Martinez Canillas:
Thomas Zimmermann [off-list ref] writes:
quoted
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabled PCI devices.
So far, efifb tracked the status of the PCI parent device internally
and did not bind if it was disabled. This patch implements the
functionality for all firmware framebuffers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
[...]
quoted
+static __init bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
+{
+#if defined(CONFIG_PCI)
+ /*
+ * TODO: Try to integrate this code into the PCI subsystem
+ */
+ int ret;
+ u16 command;
+
+ ret = pci_read_config_word(pdev, PCI_COMMAND, &command);
+ if (ret != PCIBIOS_SUCCESSFUL)
+ return false;
+ if (!(command & PCI_COMMAND_MEMORY))
+ return false;
+ return true;
+#else
+ // Getting here without PCI support is probably a bug.
+ return false;
Should we warn before return in this case ?
I would not do so as the bug is not here, but in screen_info_pci_dev().
I'm going to update this chunk such that the non-PCI case is a separate
function.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
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)
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2024-01-17 12:56:18
If the firmware framebuffer has been reloacted, the sysfb code
fixes the screen_info state before it creates the framebuffer's
platform device. Efifb will automatically receive a screen_info
with updated values. Hence remove the tracking from efifb.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/efifb.c | 76 +------------------------------------
1 file changed, 1 insertion(+), 75 deletions(-)
@@ -47,8 +46,6 @@ static bool use_bgrt = true;staticboolrequest_mem_succeeded=false;staticu64mem_flags=EFI_MEMORY_WC|EFI_MEMORY_UC;-staticstructpci_dev*efifb_pci_dev;/* dev with BAR covering the efifb */-structefifb_par{u32pseudo_palette[16];resource_size_tbase;
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2024-01-29 12:03:52
Thomas Zimmermann [off-list ref] writes:
If the firmware framebuffer has been reloacted, the sysfb code
fixes the screen_info state before it creates the framebuffer's
platform device. Efifb will automatically receive a screen_info
with updated values. Hence remove the tracking from efifb.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat