* Re: [PATCH] arch/mips: Drop CONFIG_FIRMWARE_EDID from defconfig files
From: Thomas Bogendoerfer @ 2026-04-06 12:34 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: arnd, linux-mips, linux-kernel, linux-fbdev, dri-devel
In-Reply-To: <20260401082805.214198-1-tzimmermann@suse.de>
On Wed, Apr 01, 2026 at 10:27:57AM +0200, Thomas Zimmermann wrote:
> CONFIG_FIRMWARE_EDID=y depends on X86 or EFI_GENERIC_STUB. Neither is
> true here, so drop the lines from the defconfig files.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> arch/mips/configs/ip32_defconfig | 1 -
> arch/mips/configs/lemote2f_defconfig | 1 -
> arch/mips/configs/malta_qemu_32r6_defconfig | 1 -
> arch/mips/configs/maltaaprp_defconfig | 1 -
> arch/mips/configs/maltasmvp_defconfig | 1 -
> arch/mips/configs/maltasmvp_eva_defconfig | 1 -
> arch/mips/configs/maltaup_defconfig | 1 -
> 7 files changed, 7 deletions(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Arnd Bergmann @ 2026-04-02 16:47 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <001efe27-9cbb-4a89-8d2d-a1f3ae15e505@suse.de>
On Thu, Apr 2, 2026, at 17:27, Thomas Zimmermann wrote:
> Am 02.04.26 um 16:59 schrieb Arnd Bergmann:
>> On Thu, Apr 2, 2026, at 16:10, Thomas Zimmermann wrote:
>>> Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>>> I don't really like this part of the series and would prefer
>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
>>>> (and EFI) specific implementation detail, with the hope
>>>> of eventually seperating out the x86 bits from the EFI ones.
>>> You mean, you want to use the EFI-provided framebuffers without the
>>> intermediate step of going through sysfb_primary_display?
>>>
>>> In that case, CONFIG_SYSFB would become an x86-internal thing, right?
>> The part that is still needed from sysfb is the arbitration
>> between DRM_EFI and the PCI device driver for the same hardware,
>> so I think some part of sysfb is clearly needed, in particular
>> the sysfb_disable() function that removes the EFI framebuffer
>> when there is a conflicting simpledrm or hardware specific
>> driver.
>
> We do most of that in the aperture-helper module. (see
> <linux/aperture.h>). Calling sysfb_disable() from there is a workaround
> for some corner cases. We can have an EFI-specific function that does
> the same.
That sounds good, yes. The same change would need to go into
of_platform_default_populate_init() then.
> BTW, simpledrm-on-EFI/VESA is considered obsolete and should preferably
> be removed from that driver. Simpledrm should become a driver for
> Devicetree nodes of type simple-framebuffer (as it originally has been
> intended).
Sure, I was only thinking of the case where there are both
sysfb (from Arm/riscv UEFI) and simpledrm (from devicetree)
objects referring to the same one, not the simpledrm
device created by sysfb_simplefb.
>> The parts that I want to keep out of that is anything
>> related to the x86 boot protocol, non-EFI framebuffers,
>> text console, and kexec handoff, which we don't need on
>> non-x86 UEFI systems.
>>
>> I don't mind the idea of having a sysfb_primary_display
>> in the EFI code if that helps keep EFI sane on x86,
>> but it would be good to make that local to
>> drivers/firmware/efi and (eventually) detached from
>> include/uapi/linux/screen_info.h.
>
> Efidrm retrieves the framebuffer settings from the contained struct
> screen_info. Disconnecting from screen_info would require separate
> graphics drivers for x86 and non-x86. If we split off EFI from sysfb,
> we'd likely need a sysfbdrm driver of some sort. Just saying.
Yes, I saw that as well and don't have an immediate idea for how
to best do it. I saw that you already abstracted the access to
the screen_info members in drm_sysfb_screen_info.c, which I think
is a step in that direction.
I also noticed that efidrm is mostly a subset of vesadrm, so
in theory they could be merged back into an x86 drm driver
along with the drm_sysfb_screen_info helpers, and have a non-x86
driver that constructs a drm_sysfb_device directly from the
EFI structures.
> I think we'd also have to duplicate the framebuffer-relocation code that
> currently works on anything using struct screen_info (see patch 5).
You mean the code from include/linux/screen_info.h? I think
it would make sense to have an x86 specific version of that
to operate on the x86 screen_info, and a simpler version
that just updates the resource for the efirdrm driver, but
that could also be done one level higher or lower.
>>>> In general, I am always in favor of properly using Kconfig
>>>> dependencies over 'select' statements, for the same reasons
>>>> you describe, but I don't want the the x86 logic for
>>>> the legacy VESA and VGA console handling to leak into more
>>>> architectures than necessary.
>>>>
>>>> Do you think we could instead move the sysfb_init()
>>>> function into the same two places that contain the
>>>> sysfb_primary_display definition (arch/x86/kernel/setup.c,
>>>> drivers/firmware/efi/efi-init.c) and simplify the efi version
>>>> to take out the x86 bits? That would reduce the rest
>>>> of sysfb-primary.c to the logic to unregister the device,
>>>> and that could then be selected by both x86 and EFI.
>>> No, I'm more than happy that sysfb finally consolidates all the
>>> init-framebuffer setup and detection that floated around in the kernel.
>>> I would not want it to be duplicated again.
>>>
>>> For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
>>> Although I think this will require soem sort of solution at a later point.
>> Can you clarify which problem you are trying to solve
>> with that?
>
> One thing is that some users simply what control over their kernel build.
>
> I also think that there might be systems that want to use
> sysfb_primary_display (plus the relocation feature), but not create the
> framebuffer device. Say for efi-earlycon. It needs user-control over the
> SYSFB option to do that.
I'm still not following, sorry. efi-earlycon doesn't require
CONFIG_SYSFB today, and I don't see why that would need to change,
or why it couldn't just 'select SYSFB' if it it does change.
> As a side-effect, user-configurable SYSFB gives us a nice place to put
> SYSFB_SIMPLEFB and FIRMWARE_EDID; two options that currently float
> around in the config somewhat arbitrarily.
You said that SYSFB_SIMPLEFB should get phased out in the future,
right?
I'm also missing your plan for CONFIG_FIRMWARE_EDID. I only
see three legacy drivers using the old fb_firmware_edid()
interface, so I assume this is not what you are interested in.
For the global copy that is filled by x86 and efi, and
consumed by vesadrm and efidrm, does that even need to
be a configuration option rather than get always enabled?
Arnd
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Thomas Zimmermann @ 2026-04-02 15:27 UTC (permalink / raw)
To: Arnd Bergmann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <d3d7c545-3b07-4881-a16d-45b6f039de19@app.fastmail.com>
Hi
Am 02.04.26 um 16:59 schrieb Arnd Bergmann:
> On Thu, Apr 2, 2026, at 16:10, Thomas Zimmermann wrote:
>> Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>> I don't really like this part of the series and would prefer
>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
>>> (and EFI) specific implementation detail, with the hope
>>> of eventually seperating out the x86 bits from the EFI ones.
>> You mean, you want to use the EFI-provided framebuffers without the
>> intermediate step of going through sysfb_primary_display?
>>
>> In that case, CONFIG_SYSFB would become an x86-internal thing, right?
> The part that is still needed from sysfb is the arbitration
> between DRM_EFI and the PCI device driver for the same hardware,
> so I think some part of sysfb is clearly needed, in particular
> the sysfb_disable() function that removes the EFI framebuffer
> when there is a conflicting simpledrm or hardware specific
> driver.
We do most of that in the aperture-helper module. (see
<linux/aperture.h>). Calling sysfb_disable() from there is a workaround
for some corner cases. We can have an EFI-specific function that does
the same.
BTW, simpledrm-on-EFI/VESA is considered obsolete and should preferably
be removed from that driver. Simpledrm should become a driver for
Devicetree nodes of type simple-framebuffer (as it originally has been
intended).
>
> The parts that I want to keep out of that is anything
> related to the x86 boot protocol, non-EFI framebuffers,
> text console, and kexec handoff, which we don't need on
> non-x86 UEFI systems.
>
> I don't mind the idea of having a sysfb_primary_display
> in the EFI code if that helps keep EFI sane on x86,
> but it would be good to make that local to
> drivers/firmware/efi and (eventually) detached from
> include/uapi/linux/screen_info.h.
Efidrm retrieves the framebuffer settings from the contained struct
screen_info. Disconnecting from screen_info would require separate
graphics drivers for x86 and non-x86. If we split off EFI from sysfb,
we'd likely need a sysfbdrm driver of some sort. Just saying.
I think we'd also have to duplicate the framebuffer-relocation code that
currently works on anything using struct screen_info (see patch 5).
>
>>> In general, I am always in favor of properly using Kconfig
>>> dependencies over 'select' statements, for the same reasons
>>> you describe, but I don't want the the x86 logic for
>>> the legacy VESA and VGA console handling to leak into more
>>> architectures than necessary.
>>>
>>> Do you think we could instead move the sysfb_init()
>>> function into the same two places that contain the
>>> sysfb_primary_display definition (arch/x86/kernel/setup.c,
>>> drivers/firmware/efi/efi-init.c) and simplify the efi version
>>> to take out the x86 bits? That would reduce the rest
>>> of sysfb-primary.c to the logic to unregister the device,
>>> and that could then be selected by both x86 and EFI.
>> No, I'm more than happy that sysfb finally consolidates all the
>> init-framebuffer setup and detection that floated around in the kernel.
>> I would not want it to be duplicated again.
>>
>> For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
>> Although I think this will require soem sort of solution at a later point.
> Can you clarify which problem you are trying to solve
> with that?
One thing is that some users simply what control over their kernel build.
I also think that there might be systems that want to use
sysfb_primary_display (plus the relocation feature), but not create the
framebuffer device. Say for efi-earlycon. It needs user-control over the
SYSFB option to do that.
As a side-effect, user-configurable SYSFB gives us a nice place to put
SYSFB_SIMPLEFB and FIRMWARE_EDID; two options that currently float
around in the config somewhat arbitrarily.
Best regards
Thomas
>
> Arnd
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Arnd Bergmann @ 2026-04-02 14:59 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <3e466158-c2e5-4e23-934f-dcdbb71ad41f@suse.de>
On Thu, Apr 2, 2026, at 16:10, Thomas Zimmermann wrote:
> Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>> I don't really like this part of the series and would prefer
>> to keep CONFIG_SYSFB hidden as much as possible as an x86
>> (and EFI) specific implementation detail, with the hope
>> of eventually seperating out the x86 bits from the EFI ones.
>
> You mean, you want to use the EFI-provided framebuffers without the
> intermediate step of going through sysfb_primary_display?
>
> In that case, CONFIG_SYSFB would become an x86-internal thing, right?
The part that is still needed from sysfb is the arbitration
between DRM_EFI and the PCI device driver for the same hardware,
so I think some part of sysfb is clearly needed, in particular
the sysfb_disable() function that removes the EFI framebuffer
when there is a conflicting simpledrm or hardware specific
driver.
The parts that I want to keep out of that is anything
related to the x86 boot protocol, non-EFI framebuffers,
text console, and kexec handoff, which we don't need on
non-x86 UEFI systems.
I don't mind the idea of having a sysfb_primary_display
in the EFI code if that helps keep EFI sane on x86,
but it would be good to make that local to
drivers/firmware/efi and (eventually) detached from
include/uapi/linux/screen_info.h.
>> In general, I am always in favor of properly using Kconfig
>> dependencies over 'select' statements, for the same reasons
>> you describe, but I don't want the the x86 logic for
>> the legacy VESA and VGA console handling to leak into more
>> architectures than necessary.
>>
>> Do you think we could instead move the sysfb_init()
>> function into the same two places that contain the
>> sysfb_primary_display definition (arch/x86/kernel/setup.c,
>> drivers/firmware/efi/efi-init.c) and simplify the efi version
>> to take out the x86 bits? That would reduce the rest
>> of sysfb-primary.c to the logic to unregister the device,
>> and that could then be selected by both x86 and EFI.
>
> No, I'm more than happy that sysfb finally consolidates all the
> init-framebuffer setup and detection that floated around in the kernel.
> I would not want it to be duplicated again.
>
> For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
> Although I think this will require soem sort of solution at a later point.
Can you clarify which problem you are trying to solve
with that?
Arnd
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Thomas Zimmermann @ 2026-04-02 14:10 UTC (permalink / raw)
To: Arnd Bergmann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <78f76717-8f1e-41d6-92f7-261df96b84b6@app.fastmail.com>
Hi
Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>> Add a descriptive string and help text to CONFIG_SYSFB, so that users
>> can modify it. Flip all implicit selects in the Kconfig options into
>> dependencies. This avoids cyclic dependencies in the config.
>>
>> Enabling CONFIG_SYSFB makes the kernel provide a device for the firmware
>> framebuffer. As this can (slightly) affect system behavior, having a
>> user-facing option seems preferable. Some users might also want to set
>> every detail of their kernel config.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> I don't really like this part of the series and would prefer
> to keep CONFIG_SYSFB hidden as much as possible as an x86
> (and EFI) specific implementation detail, with the hope
> of eventually seperating out the x86 bits from the EFI ones.
You mean, you want to use the EFI-provided framebuffers without the
intermediate step of going through sysfb_primary_display?
In that case, CONFIG_SYSFB would become an x86-internal thing, right?
>
> In general, I am always in favor of properly using Kconfig
> dependencies over 'select' statements, for the same reasons
> you describe, but I don't want the the x86 logic for
> the legacy VESA and VGA console handling to leak into more
> architectures than necessary.
>
> Do you think we could instead move the sysfb_init()
> function into the same two places that contain the
> sysfb_primary_display definition (arch/x86/kernel/setup.c,
> drivers/firmware/efi/efi-init.c) and simplify the efi version
> to take out the x86 bits? That would reduce the rest
> of sysfb-primary.c to the logic to unregister the device,
> and that could then be selected by both x86 and EFI.
No, I'm more than happy that sysfb finally consolidates all the
init-framebuffer setup and detection that floated around in the kernel.
I would not want it to be duplicated again.
For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
Although I think this will require soem sort of solution at a later point.
Best regards
Thomas
>
> Arnd
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Arnd Bergmann @ 2026-04-02 13:08 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <20260402092305.208728-4-tzimmermann@suse.de>
On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
> Add a descriptive string and help text to CONFIG_SYSFB, so that users
> can modify it. Flip all implicit selects in the Kconfig options into
> dependencies. This avoids cyclic dependencies in the config.
>
> Enabling CONFIG_SYSFB makes the kernel provide a device for the firmware
> framebuffer. As this can (slightly) affect system behavior, having a
> user-facing option seems preferable. Some users might also want to set
> every detail of their kernel config.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
I don't really like this part of the series and would prefer
to keep CONFIG_SYSFB hidden as much as possible as an x86
(and EFI) specific implementation detail, with the hope
of eventually seperating out the x86 bits from the EFI ones.
In general, I am always in favor of properly using Kconfig
dependencies over 'select' statements, for the same reasons
you describe, but I don't want the the x86 logic for
the legacy VESA and VGA console handling to leak into more
architectures than necessary.
Do you think we could instead move the sysfb_init()
function into the same two places that contain the
sysfb_primary_display definition (arch/x86/kernel/setup.c,
drivers/firmware/efi/efi-init.c) and simplify the efi version
to take out the x86 bits? That would reduce the rest
of sysfb-primary.c to the logic to unregister the device,
and that could then be selected by both x86 and EFI.
Arnd
^ permalink raw reply
* RE: [PATCH 1/8] hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
From: Saurabh Singh Sengar @ 2026-04-02 10:50 UTC (permalink / raw)
To: Thomas Zimmermann, javierm@redhat.com, arnd@arndb.de,
ardb@kernel.org, ilias.apalodimas@linaro.org,
chenhuacai@kernel.org, kernel@xen0n.name,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
airlied@gmail.com, simona@ffwll.ch, KY Srinivasan, Haiyang Zhang,
wei.liu@kernel.org, Dexuan Cui, Long Li, deller@gmx.de
Cc: linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
linux-efi@vger.kernel.org, linux-riscv@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
linux-fbdev@vger.kernel.org, Michael Kelley, Saurabh Sengar,
stable@vger.kernel.org
In-Reply-To: <20260402092305.208728-2-tzimmermann@suse.de>
> Hyperv's sysfb access only exists in the VMBUS support. Therefore only select
> CONFIG_SYSFB for CONFIG_HYPERV_VMBUS. Avoids sysfb code on systems
> that don't need it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V
> guests")
> Cc: Michael Kelley <mhklinux@outlook.com>
> Cc: Saurabh Sengar <ssengar@linux.microsoft.com>
> Cc: Wei Liu <wei.liu@kernel.org>
> Cc: "K. Y. Srinivasan" <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Dexuan Cui <decui@microsoft.com>
> Cc: Long Li <longli@microsoft.com>
> Cc: linux-hyperv@vger.kernel.org
> Cc: <stable@vger.kernel.org> # v6.16+
> ---
> drivers/hv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index
> 7937ac0cbd0f..2d0b3fcb0ff8 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -9,7 +9,6 @@ config HYPERV
> select PARAVIRT
> select X86_HV_CALLBACK_VECTOR if X86
> select OF_EARLY_FLATTREE if OF
> - select SYSFB if EFI && !HYPERV_VTL_MODE
> select IRQ_MSI_LIB if X86
> help
> Select this option to run Linux as a Hyper-V client operating @@ -62,6
> +61,7 @@ config HYPERV_VMBUS
> tristate "Microsoft Hyper-V VMBus driver"
> depends on HYPERV
> default HYPERV
> + select SYSFB if EFI && !HYPERV_VTL_MODE
> help
> Select this option to enable Hyper-V Vmbus driver.
>
> --
> 2.53.0
Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
^ permalink raw reply
* [PATCH] fbdev: omap2: fix inconsistent lock returns in omapfb_mmap
From: zenghongling @ 2026-04-02 9:34 UTC (permalink / raw)
To: deller, linux-omap, linux-fbdev, dri-devel
Cc: linux-kernel, zhongling0719, zenghongling, kernel test robot
Fix the warning about inconsistent returns for '&rg->lock' in
omapfb_mmap() function. The warning arises because the error path
uses 'ofbi->region' while the normal path uses 'rg'.
smatch warnings:
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1126 omapfb_mmap()
warn: inconsistent returns '&rg->lock'.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: zenghongling <zenghongling@kylinos.cn>
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index a8b2930290e1..d70deb6a9150 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -1121,7 +1121,7 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
return 0;
error:
- omapfb_put_mem_region(ofbi->region);
+ omapfb_put_mem_region(rg);
return r;
}
--
2.25.1
^ permalink raw reply related
* [PATCH 5/8] firmware: sysfb: Implement screen_info relocation for primary display
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
Move the relocation tracking for screen_info from the screen_info
helpers to sysfb. The relocation code operates on sysfb_primary_display,
which belongs to sysfb. The remaining screen_info helpers are now free
from global state.
Adapt some symbol names. Now prefer early returns in the helper
sysfb_apply_screen_info_fixup() over nested branching. Also return an
errno code from sysfb_apply_screen_info_fixup() if the relocation
failed. In this case, do not create a device for the framebuffer.
The original code advertised this behavior in a comment but never
implemented it.
Framebuffer aperture relocation can happen during boot if the PCI
graphics device is located behind a PCI bridge. If the bridge's sub-
bus gets relocated, the framebuffer aperture moves accordingly. The
helper for tracking these relocations fixes up the values stored in
sysfb_primary_display so that they refer to the correct address range
again. Generic system-framebuffer drivers would not work otherwise.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/sysfb.h | 5 ++
drivers/firmware/sysfb_pci.c | 111 +++++++++++++++++++++++++++++++
drivers/firmware/sysfb_primary.c | 9 ++-
drivers/video/screen_info_pci.c | 110 ------------------------------
include/linux/screen_info.h | 3 -
5 files changed, 123 insertions(+), 115 deletions(-)
diff --git a/drivers/firmware/sysfb.h b/drivers/firmware/sysfb.h
index 9f7fe2e03f68..1eaa3b0fa364 100644
--- a/drivers/firmware/sysfb.h
+++ b/drivers/firmware/sysfb.h
@@ -8,8 +8,13 @@
struct pci_dev;
#ifdef CONFIG_PCI
+int sysfb_apply_screen_info_fixups(void);
bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev);
#else
+static inline int sysfb_apply_screen_info_fixups(void)
+{
+ return 0;
+}
static inline bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
{
return false;
diff --git a/drivers/firmware/sysfb_pci.c b/drivers/firmware/sysfb_pci.c
index 8f3adeef4fb1..d972750c6bc6 100644
--- a/drivers/firmware/sysfb_pci.c
+++ b/drivers/firmware/sysfb_pci.c
@@ -1,9 +1,120 @@
// SPDX-License-Identifier: GPL-2.0-or-later
#include <linux/pci.h>
+#include <linux/printk.h>
+#include <linux/screen_info.h>
+#include <linux/sysfb.h>
#include "sysfb.h"
+static struct pci_dev *sysfb_lfb_pdev;
+static size_t sysfb_lfb_bar;
+static resource_size_t sysfb_lfb_res_start; // original start of resource
+static resource_size_t sysfb_lfb_offset; // framebuffer offset within resource
+
+static bool __sysfb_relocation_is_valid(const struct screen_info *si, struct resource *pr)
+{
+ u64 size = __screen_info_lfb_size(si, screen_info_video_type(si));
+
+ if (sysfb_lfb_offset > resource_size(pr))
+ return false;
+ if (size > resource_size(pr))
+ return false;
+ if (resource_size(pr) - size < sysfb_lfb_offset)
+ return false;
+
+ return true;
+}
+
+int sysfb_apply_screen_info_fixups(void)
+{
+ struct screen_info *si = &sysfb_primary_display.screen;
+ struct resource *pr;
+
+ if (!sysfb_lfb_pdev)
+ return 0; /* primary display is not on a PCI device */
+
+ pr = &sysfb_lfb_pdev->resource[sysfb_lfb_bar];
+
+ if (pr->start == sysfb_lfb_res_start)
+ return 0; /* no relocation took place */
+
+ if (!__sysfb_relocation_is_valid(si, pr))
+ return -ENXIO;
+
+ /*
+ * Only update base if we have an actual relocation to a valid I/O range.
+ */
+ __screen_info_set_lfb_base(si, pr->start + sysfb_lfb_offset);
+ pr_info("Relocating firmware framebuffer to offset %pa[d] within %pr\n",
+ &sysfb_lfb_offset, pr);
+
+ return 0;
+}
+
+static int __screen_info_lfb_pci_bus_region(const struct screen_info *si, unsigned int type,
+ struct pci_bus_region *r)
+{
+ u64 base, size;
+
+ base = __screen_info_lfb_base(si);
+ if (!base)
+ return -EINVAL;
+
+ size = __screen_info_lfb_size(si, type);
+ if (!size)
+ return -EINVAL;
+
+ r->start = base;
+ r->end = base + size - 1;
+
+ return 0;
+}
+
+static void sysfb_fixup_lfb(struct pci_dev *pdev)
+{
+ unsigned int type;
+ struct pci_bus_region bus_region;
+ int ret;
+ struct resource r = {
+ .flags = IORESOURCE_MEM,
+ };
+ const struct resource *pr;
+ const struct screen_info *si = &sysfb_primary_display.screen;
+
+ if (sysfb_lfb_pdev)
+ return; // already found
+
+ type = screen_info_video_type(si);
+ if (!__screen_info_has_lfb(type))
+ return; // only applies to EFI; maybe VESA
+
+ ret = __screen_info_lfb_pci_bus_region(si, type, &bus_region);
+ if (ret < 0)
+ return;
+
+ /*
+ * Translate the PCI bus address to resource. Account for an offset if
+ * the framebuffer is behind a PCI host bridge.
+ */
+ pcibios_bus_to_resource(pdev->bus, &r, &bus_region);
+
+ pr = pci_find_resource(pdev, &r);
+ if (!pr)
+ return;
+
+ /*
+ * We've found a PCI device with the framebuffer resource. Store away
+ * the parameters to track relocation of the framebuffer aperture.
+ */
+ sysfb_lfb_pdev = pdev;
+ sysfb_lfb_bar = pr - pdev->resource;
+ sysfb_lfb_offset = r.start - pr->start;
+ sysfb_lfb_res_start = bus_region.start;
+}
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, 16,
+ sysfb_fixup_lfb);
+
bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
{
/*
diff --git a/drivers/firmware/sysfb_primary.c b/drivers/firmware/sysfb_primary.c
index ab8d7fc468bb..298f87a43a7e 100644
--- a/drivers/firmware/sysfb_primary.c
+++ b/drivers/firmware/sysfb_primary.c
@@ -32,6 +32,7 @@
#include <linux/pci.h>
#include <linux/platform_data/simplefb.h>
#include <linux/platform_device.h>
+#include <linux/printk.h>
#include <linux/screen_info.h>
#include <linux/sysfb.h>
@@ -127,11 +128,15 @@ static __init int sysfb_init(void)
struct simplefb_platform_data mode;
const char *name;
bool compatible;
- int ret = 0;
+ int ret;
- screen_info_apply_fixups();
+ ret = sysfb_apply_screen_info_fixups();
mutex_lock(&disable_lock);
+ if (ret) {
+ pr_warn("Invalid relocation, disabling system framebuffer\n");
+ disabled = true; /* screen_info relocation failed */
+ }
if (disabled)
goto unlock_mutex;
diff --git a/drivers/video/screen_info_pci.c b/drivers/video/screen_info_pci.c
index 8f34d8a74f09..d8985a54ce71 100644
--- a/drivers/video/screen_info_pci.c
+++ b/drivers/video/screen_info_pci.c
@@ -1,117 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/pci.h>
-#include <linux/printk.h>
#include <linux/screen_info.h>
-#include <linux/string.h>
-#include <linux/sysfb.h>
-
-static struct pci_dev *screen_info_lfb_pdev;
-static size_t screen_info_lfb_bar;
-static resource_size_t screen_info_lfb_res_start; // original start of resource
-static resource_size_t screen_info_lfb_offset; // framebuffer offset within resource
-
-static bool __screen_info_relocation_is_valid(const struct screen_info *si, struct resource *pr)
-{
- u64 size = __screen_info_lfb_size(si, screen_info_video_type(si));
-
- if (screen_info_lfb_offset > resource_size(pr))
- return false;
- if (size > resource_size(pr))
- return false;
- if (resource_size(pr) - size < screen_info_lfb_offset)
- return false;
-
- return true;
-}
-
-void screen_info_apply_fixups(void)
-{
- struct screen_info *si = &sysfb_primary_display.screen;
-
- if (screen_info_lfb_pdev) {
- struct resource *pr = &screen_info_lfb_pdev->resource[screen_info_lfb_bar];
-
- if (pr->start != screen_info_lfb_res_start) {
- if (__screen_info_relocation_is_valid(si, pr)) {
- /*
- * Only update base if we have an actual
- * relocation to a valid I/O range.
- */
- __screen_info_set_lfb_base(si, pr->start + screen_info_lfb_offset);
- pr_info("Relocating firmware framebuffer to offset %pa[d] within %pr\n",
- &screen_info_lfb_offset, pr);
- } else {
- pr_warn("Invalid relocating, disabling firmware framebuffer\n");
- }
- }
- }
-}
-
-static int __screen_info_lfb_pci_bus_region(const struct screen_info *si, unsigned int type,
- struct pci_bus_region *r)
-{
- u64 base, size;
-
- base = __screen_info_lfb_base(si);
- if (!base)
- return -EINVAL;
-
- size = __screen_info_lfb_size(si, type);
- if (!size)
- return -EINVAL;
-
- r->start = base;
- r->end = base + size - 1;
-
- return 0;
-}
-
-static void screen_info_fixup_lfb(struct pci_dev *pdev)
-{
- unsigned int type;
- struct pci_bus_region bus_region;
- int ret;
- struct resource r = {
- .flags = IORESOURCE_MEM,
- };
- const struct resource *pr;
- const struct screen_info *si = &sysfb_primary_display.screen;
-
- if (screen_info_lfb_pdev)
- return; // already found
-
- type = screen_info_video_type(si);
- if (!__screen_info_has_lfb(type))
- return; // only applies to EFI; maybe VESA
-
- ret = __screen_info_lfb_pci_bus_region(si, type, &bus_region);
- if (ret < 0)
- return;
-
- /*
- * Translate the PCI bus address to resource. Account
- * for an offset if the framebuffer is behind a PCI host
- * bridge.
- */
- pcibios_bus_to_resource(pdev->bus, &r, &bus_region);
-
- pr = pci_find_resource(pdev, &r);
- if (!pr)
- return;
-
- /*
- * We've found a PCI device with the framebuffer
- * resource. Store away the parameters to track
- * relocation of the framebuffer aperture.
- */
- screen_info_lfb_pdev = pdev;
- screen_info_lfb_bar = pr - pdev->resource;
- screen_info_lfb_offset = r.start - pr->start;
- screen_info_lfb_res_start = bus_region.start;
-}
-DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, 16,
- screen_info_fixup_lfb);
static struct pci_dev *__screen_info_pci_dev(struct resource *res)
{
diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
index c022403c599a..2adbe25b88d8 100644
--- a/include/linux/screen_info.h
+++ b/include/linux/screen_info.h
@@ -140,11 +140,8 @@ u32 __screen_info_lfb_bits_per_pixel(const struct screen_info *si);
int screen_info_pixel_format(const struct screen_info *si, struct pixel_format *f);
#if defined(CONFIG_PCI)
-void screen_info_apply_fixups(void);
struct pci_dev *screen_info_pci_dev(const struct screen_info *si);
#else
-static inline void screen_info_apply_fixups(void)
-{ }
static inline struct pci_dev *screen_info_pci_dev(const struct screen_info *si)
{
return NULL;
--
2.53.0
^ permalink raw reply related
* [PATCH 8/8] firmware: sysfb: Move CONFIG_FIRMWARE_EDID to firmware options
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
Move the Kconfig option for CONFIG_FIRMWARE_EDID to the firmware
subsystem. The option controls architecture and firmware code, so
it fits here better than in video.
Also make it depend on CONFIG_SYSFB. The EDID data is stored in
sysfb_primary_display and only useful with a sysfb framebuffer. This
further allows for removing an explicit test for CONFIG_FIRMWARE_EDID
from the EFI init code. For loongson, select CONFIG_SYSFB in the
defconfig files.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
arch/loongarch/configs/loongson32_defconfig | 1 +
arch/loongarch/configs/loongson64_defconfig | 1 +
drivers/firmware/Kconfig | 20 ++++++++++++++++++++
drivers/firmware/efi/efi-init.c | 2 +-
drivers/video/Kconfig | 19 -------------------
5 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/arch/loongarch/configs/loongson32_defconfig b/arch/loongarch/configs/loongson32_defconfig
index 276b1577e0be..1c0897723247 100644
--- a/arch/loongarch/configs/loongson32_defconfig
+++ b/arch/loongarch/configs/loongson32_defconfig
@@ -786,6 +786,7 @@ CONFIG_DRM_VIRTIO_GPU=m
CONFIG_DRM_LOONGSON=y
CONFIG_FB=y
CONFIG_FB_RADEON=y
+CONFIG_SYSFB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=m
diff --git a/arch/loongarch/configs/loongson64_defconfig b/arch/loongarch/configs/loongson64_defconfig
index a14db1a95e7e..38340537dfd4 100644
--- a/arch/loongarch/configs/loongson64_defconfig
+++ b/arch/loongarch/configs/loongson64_defconfig
@@ -816,6 +816,7 @@ CONFIG_DRM_VIRTIO_GPU=m
CONFIG_DRM_LOONGSON=y
CONFIG_FB=y
CONFIG_FB_RADEON=y
+CONFIG_SYSFB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=m
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 52f8253a46b1..edfb171d9eab 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -225,6 +225,26 @@ config SYSFB_SIMPLEFB
If unsure, say Y.
+config FIRMWARE_EDID
+ bool "Enable firmware EDID"
+ depends on SYSFB
+ depends on EFI_GENERIC_STUB || X86
+ help
+ This enables access to the EDID transferred from the firmware.
+ On EFI systems, the EDID comes from the same device as the
+ primary GOP. On x86 with BIOS, it comes from the VESA BIOS.
+ DRM display drivers will be able to export the information
+ to userspace.
+
+ Also enable this if DDC/I2C transfers do not work for your driver
+ and if you are using nvidiafb, i810fb or savagefb.
+
+ In general, choosing Y for this option is safe. If you
+ experience extremely long delays while booting before you get
+ something on your display, try setting this to N. Matrox cards in
+ combination with certain motherboards and monitors are known to
+ suffer from this problem.
+
config TH1520_AON_PROTOCOL
tristate "Always-On firmware protocol"
depends on ARCH_THEAD || COMPILE_TEST
diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c
index 002518b642ed..c4088fb8482b 100644
--- a/drivers/firmware/efi/efi-init.c
+++ b/drivers/firmware/efi/efi-init.c
@@ -60,7 +60,7 @@ extern __weak const efi_config_table_type_t efi_arch_tables[];
* x86 defines its own instance of sysfb_primary_display and uses
* it even without EFI, everything else can get them from here.
*/
-#if !defined(CONFIG_X86) && (defined(CONFIG_SYSFB) || defined(CONFIG_FIRMWARE_EDID))
+#if !defined(CONFIG_X86) && defined(CONFIG_SYSFB)
struct sysfb_display_info sysfb_primary_display __section(".data");
EXPORT_SYMBOL_GPL(sysfb_primary_display);
#endif
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index a7144d275f54..1c9ac3b029a7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -62,25 +62,6 @@ config HDMI
endif # HAS_IOMEM
-config FIRMWARE_EDID
- bool "Enable firmware EDID"
- depends on EFI_GENERIC_STUB || X86
- help
- This enables access to the EDID transferred from the firmware.
- On EFI systems, the EDID comes from the same device as the
- primary GOP. On x86 with BIOS, it comes from the VESA BIOS.
- DRM display drivers will be able to export the information
- to userspace.
-
- Also enable this if DDC/I2C transfers do not work for your driver
- and if you are using nvidiafb, i810fb or savagefb.
-
- In general, choosing Y for this option is safe. If you
- experience extremely long delays while booting before you get
- something on your display, try setting this to N. Matrox cards in
- combination with certain motherboards and monitors are known to
- suffer from this problem.
-
if VT
source "drivers/video/console/Kconfig"
endif
--
2.53.0
^ permalink raw reply related
* [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
Add a descriptive string and help text to CONFIG_SYSFB, so that users
can modify it. Flip all implicit selects in the Kconfig options into
dependencies. This avoids cyclic dependencies in the config.
Enabling CONFIG_SYSFB makes the kernel provide a device for the firmware
framebuffer. As this can (slightly) affect system behavior, having a
user-facing option seems preferable. Some users might also want to set
every detail of their kernel config.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/Kconfig | 18 ++++++++++++++++--
drivers/gpu/drm/sysfb/Kconfig | 4 ++--
drivers/hv/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 5 +++--
4 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index bbd2155d8483..52f8253a46b1 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -179,14 +179,28 @@ config MTK_ADSP_IPC
Client might use shared memory to exchange information with ADSP.
config SYSFB
- bool
+ bool "Enable system framebuffer provided by boot loader"
select BOOT_VESA_SUPPORT
select SCREEN_INFO
+ help
+ Use the system framebuffer provided by the boot loader. This will
+ create a device representing the framebuffer. The output depends on
+ EFI, VESA, VGA, or some other firmware-based interface.
+
+ The firmware or boot loader sets the display resolution and color
+ mode. See your boot loader's documentation on how to do this. On
+ some systems the display can also be configured during boot with
+ the kernel's video= or vga= parameters.
+
+ Besides this option, you also have to enable a compatible graphics
+ driver, such as efidrm or vesadrm.
+
+ If unsure, say Y.
config SYSFB_SIMPLEFB
bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
+ depends on SYSFB
depends on X86 || EFI
- select SYSFB
help
Firmwares often provide initial graphics framebuffers so the BIOS,
bootloader or kernel can show basic video-output during boot for
diff --git a/drivers/gpu/drm/sysfb/Kconfig b/drivers/gpu/drm/sysfb/Kconfig
index 2559ead6cf1f..74be3c8e6657 100644
--- a/drivers/gpu/drm/sysfb/Kconfig
+++ b/drivers/gpu/drm/sysfb/Kconfig
@@ -26,12 +26,12 @@ config DRM_COREBOOTDRM
config DRM_EFIDRM
tristate "EFI framebuffer driver"
depends on DRM && MMU && EFI && (!SYSFB_SIMPLEFB || COMPILE_TEST)
+ depends on SYSFB
select APERTURE_HELPERS
select DRM_CLIENT_SELECTION
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
select DRM_SYSFB_HELPER
- select SYSFB
help
DRM driver for EFI framebuffers.
@@ -76,12 +76,12 @@ config DRM_SIMPLEDRM
config DRM_VESADRM
tristate "VESA framebuffer driver"
depends on DRM && MMU && X86 && (!SYSFB_SIMPLEFB || COMPILE_TEST)
+ depends on SYSFB
select APERTURE_HELPERS
select DRM_CLIENT_SELECTION
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
select DRM_SYSFB_HELPER
- select SYSFB
help
DRM driver for VESA framebuffers.
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 2d0b3fcb0ff8..af0ac6516159 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -60,8 +60,8 @@ config HYPERV_BALLOON
config HYPERV_VMBUS
tristate "Microsoft Hyper-V VMBus driver"
depends on HYPERV
+ depends on SYSFB if EFI && !HYPERV_VTL_MODE
default HYPERV
- select SYSFB if EFI && !HYPERV_VTL_MODE
help
Select this option to enable Hyper-V Vmbus driver.
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ac9ac4287c6a..6f55bec8c207 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -333,6 +333,7 @@ config FB_IMSTT
config FB_VGA16
tristate "VGA 16-color graphics support"
depends on FB && X86
+ depends on SYSFB
select APERTURE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -424,9 +425,9 @@ config FB_UVESA
config FB_VESA
bool "VESA VGA graphics support"
depends on (FB = y) && X86
+ depends on SYSFB
select APERTURE_HELPERS
select FB_IOMEM_HELPERS
- select SYSFB
help
This is the frame buffer device driver for generic VESA 2.0
compliant graphic cards. The older VESA 1.2 cards are not supported.
@@ -436,10 +437,10 @@ config FB_VESA
config FB_EFI
bool "EFI-based Framebuffer Support"
depends on (FB = y) && EFI
+ depends on SYSFB
select APERTURE_HELPERS
select DRM_PANEL_ORIENTATION_QUIRKS
select FB_IOMEM_HELPERS
- select SYSFB
help
This is the EFI frame buffer device driver. If the firmware on
your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
2.53.0
^ permalink raw reply related
* [PATCH 7/8] firmware: efi: Make CONFIG_EFI_EARLYCON depend on CONFIG_SYSFB; clean up
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
Efi-earlycon uses sysfb_primary_display. Therefore make it depend on
the corresponding config symbol. With this in place, go through the
source files and reduce tests to CONFIG_SYSFB. Efi-earlycon is now
just another regular user of sysfb.
This also enables the screen_info relocation feature for efi-earlycon.
Systems might move the framebuffer aperture while booting the kernel. PCI
bridges sometimes do this as part of relocating the sub-bus aperture.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
arch/arm64/kernel/image-vars.h | 2 +-
arch/loongarch/kernel/efi.c | 4 ++--
arch/loongarch/kernel/image-vars.h | 2 +-
arch/riscv/kernel/image-vars.h | 2 +-
drivers/firmware/efi/Kconfig | 3 ++-
drivers/firmware/efi/efi-init.c | 6 ++----
drivers/firmware/efi/libstub/efi-stub-entry.c | 4 +---
7 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index d7b0d12b1015..7e0e61385286 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -37,7 +37,7 @@ PROVIDE(__efistub__text = _text);
PROVIDE(__efistub__end = _end);
PROVIDE(__efistub___inittext_end = __inittext_end);
PROVIDE(__efistub__edata = _edata);
-#if defined(CONFIG_EFI_EARLYCON) || defined(CONFIG_SYSFB)
+#if defined(CONFIG_SYSFB)
PROVIDE(__efistub_sysfb_primary_display = sysfb_primary_display);
#endif
PROVIDE(__efistub__ctype = _ctype);
diff --git a/arch/loongarch/kernel/efi.c b/arch/loongarch/kernel/efi.c
index 69dd83f8082f..6c25e2ecf45f 100644
--- a/arch/loongarch/kernel/efi.c
+++ b/arch/loongarch/kernel/efi.c
@@ -74,7 +74,7 @@ bool efi_poweroff_required(void)
unsigned long __initdata primary_display_table = EFI_INVALID_TABLE_ADDR;
-#if defined(CONFIG_SYSFB) || defined(CONFIG_EFI_EARLYCON)
+#if defined(CONFIG_SYSFB)
struct sysfb_display_info sysfb_primary_display __section(".data");
EXPORT_SYMBOL_GPL(sysfb_primary_display);
#endif
@@ -129,7 +129,7 @@ void __init efi_init(void)
set_bit(EFI_CONFIG_TABLES, &efi.flags);
- if (IS_ENABLED(CONFIG_EFI_EARLYCON) || IS_ENABLED(CONFIG_SYSFB))
+ if (IS_ENABLED(CONFIG_SYSFB))
init_primary_display();
if (boot_memmap == EFI_INVALID_TABLE_ADDR)
diff --git a/arch/loongarch/kernel/image-vars.h b/arch/loongarch/kernel/image-vars.h
index e557ebd46c2b..c43f9326f344 100644
--- a/arch/loongarch/kernel/image-vars.h
+++ b/arch/loongarch/kernel/image-vars.h
@@ -11,7 +11,7 @@ __efistub_strcmp = strcmp;
__efistub_kernel_entry = kernel_entry;
__efistub_kernel_asize = kernel_asize;
__efistub_kernel_fsize = kernel_fsize;
-#if defined(CONFIG_EFI_EARLYCON) || defined(CONFIG_SYSFB)
+#if defined(CONFIG_SYSFB)
__efistub_sysfb_primary_display = sysfb_primary_display;
#endif
diff --git a/arch/riscv/kernel/image-vars.h b/arch/riscv/kernel/image-vars.h
index 3bd9d06a8b8f..3ab2529c4154 100644
--- a/arch/riscv/kernel/image-vars.h
+++ b/arch/riscv/kernel/image-vars.h
@@ -28,7 +28,7 @@ __efistub__start_kernel = _start_kernel;
__efistub__end = _end;
__efistub__edata = _edata;
__efistub___init_text_end = __init_text_end;
-#if defined(CONFIG_EFI_EARLYCON) || defined(CONFIG_SYSFB)
+#if defined(CONFIG_SYSFB)
__efistub_sysfb_primary_display = sysfb_primary_display;
#endif
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 29e0729299f5..925ded080eb4 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -219,8 +219,9 @@ config EFI_DISABLE_PCI_DMA
config EFI_EARLYCON
def_bool y
depends on SERIAL_EARLYCON && !ARM
- select FONT_SUPPORT
+ depends on SYSFB
select ARCH_USE_MEMREMAP_PROT
+ select FONT_SUPPORT
config EFI_CUSTOM_SSDT_OVERLAYS
bool "Load custom ACPI SSDT overlay from an EFI variable"
diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c
index 6103b1a082d2..002518b642ed 100644
--- a/drivers/firmware/efi/efi-init.c
+++ b/drivers/firmware/efi/efi-init.c
@@ -60,7 +60,7 @@ extern __weak const efi_config_table_type_t efi_arch_tables[];
* x86 defines its own instance of sysfb_primary_display and uses
* it even without EFI, everything else can get them from here.
*/
-#if !defined(CONFIG_X86) && (defined(CONFIG_SYSFB) || defined(CONFIG_EFI_EARLYCON) || defined(CONFIG_FIRMWARE_EDID))
+#if !defined(CONFIG_X86) && (defined(CONFIG_SYSFB) || defined(CONFIG_FIRMWARE_EDID))
struct sysfb_display_info sysfb_primary_display __section(".data");
EXPORT_SYMBOL_GPL(sysfb_primary_display);
#endif
@@ -271,8 +271,6 @@ void __init efi_init(void)
memblock_reserve(data.phys_map & PAGE_MASK,
PAGE_ALIGN(data.size + (data.phys_map & ~PAGE_MASK)));
- if (IS_ENABLED(CONFIG_X86) ||
- IS_ENABLED(CONFIG_SYSFB) ||
- IS_ENABLED(CONFIG_EFI_EARLYCON))
+ if (IS_ENABLED(CONFIG_X86) || IS_ENABLED(CONFIG_SYSFB))
init_primary_display();
}
diff --git a/drivers/firmware/efi/libstub/efi-stub-entry.c b/drivers/firmware/efi/libstub/efi-stub-entry.c
index aa85e910fe59..214fa4d84df0 100644
--- a/drivers/firmware/efi/libstub/efi-stub-entry.c
+++ b/drivers/firmware/efi/libstub/efi-stub-entry.c
@@ -19,9 +19,7 @@ struct sysfb_display_info *alloc_primary_display(void)
if (IS_ENABLED(CONFIG_ARM))
return __alloc_primary_display();
- if (IS_ENABLED(CONFIG_X86) ||
- IS_ENABLED(CONFIG_EFI_EARLYCON) ||
- IS_ENABLED(CONFIG_SYSFB))
+ if (IS_ENABLED(CONFIG_X86) || IS_ENABLED(CONFIG_SYSFB))
return kernel_image_addr(&sysfb_primary_display);
return NULL;
--
2.53.0
^ permalink raw reply related
* [PATCH 2/8] firmware: efi: Never declare sysfb_primary_display on x86
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann, kernel test robot
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
The x86 architecture comes with its own instance of the global
state variable sysfb_primary_display. Never declare it in the EFI
subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID")
Cc: kernel test robot <lkp@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: linux-efi@vger.kernel.org
---
drivers/firmware/efi/efi-init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c
index 5a595d026f58..6103b1a082d2 100644
--- a/drivers/firmware/efi/efi-init.c
+++ b/drivers/firmware/efi/efi-init.c
@@ -60,7 +60,7 @@ extern __weak const efi_config_table_type_t efi_arch_tables[];
* x86 defines its own instance of sysfb_primary_display and uses
* it even without EFI, everything else can get them from here.
*/
-#if !defined(CONFIG_X86) && (defined(CONFIG_SYSFB) || defined(CONFIG_EFI_EARLYCON)) || defined(CONFIG_FIRMWARE_EDID)
+#if !defined(CONFIG_X86) && (defined(CONFIG_SYSFB) || defined(CONFIG_EFI_EARLYCON) || defined(CONFIG_FIRMWARE_EDID))
struct sysfb_display_info sysfb_primary_display __section(".data");
EXPORT_SYMBOL_GPL(sysfb_primary_display);
#endif
--
2.53.0
^ permalink raw reply related
* [PATCH 6/8] firmware: sysfb: Avoid forward-declaring sysfb_parent_dev()
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
Move sysfb_parent_dev() to the top of the source file to avoid
the extra declaration. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/sysfb_primary.c | 36 +++++++++++++++-----------------
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/firmware/sysfb_primary.c b/drivers/firmware/sysfb_primary.c
index 298f87a43a7e..a7f8cede60ad 100644
--- a/drivers/firmware/sysfb_primary.c
+++ b/drivers/firmware/sysfb_primary.c
@@ -42,7 +42,23 @@ static struct platform_device *pd;
static DEFINE_MUTEX(disable_lock);
static bool disabled;
-static struct device *sysfb_parent_dev(const struct screen_info *si);
+static struct device *sysfb_parent_dev(const struct screen_info *si)
+{
+ struct pci_dev *pdev;
+
+ pdev = screen_info_pci_dev(si);
+ if (IS_ERR(pdev)) {
+ return ERR_CAST(pdev);
+ } else if (pdev) {
+ if (!sysfb_pci_dev_is_enabled(pdev)) {
+ pci_dev_put(pdev);
+ return ERR_PTR(-ENODEV);
+ }
+ return &pdev->dev;
+ }
+
+ return NULL;
+}
static bool sysfb_unregister(void)
{
@@ -101,24 +117,6 @@ bool sysfb_handles_screen_info(void)
}
EXPORT_SYMBOL_GPL(sysfb_handles_screen_info);
-static struct device *sysfb_parent_dev(const struct screen_info *si)
-{
- struct pci_dev *pdev;
-
- pdev = screen_info_pci_dev(si);
- if (IS_ERR(pdev)) {
- return ERR_CAST(pdev);
- } else if (pdev) {
- if (!sysfb_pci_dev_is_enabled(pdev)) {
- pci_dev_put(pdev);
- return ERR_PTR(-ENODEV);
- }
- return &pdev->dev;
- }
-
- return NULL;
-}
-
static __init int sysfb_init(void)
{
struct sysfb_display_info *dpy = &sysfb_primary_display;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/8] hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann, Michael Kelley,
Saurabh Sengar, stable
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
Hyperv's sysfb access only exists in the VMBUS support. Therefore
only select CONFIG_SYSFB for CONFIG_HYPERV_VMBUS. Avoids sysfb code
on systems that don't need it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests")
Cc: Michael Kelley <mhklinux@outlook.com>
Cc: Saurabh Sengar <ssengar@linux.microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Long Li <longli@microsoft.com>
Cc: linux-hyperv@vger.kernel.org
Cc: <stable@vger.kernel.org> # v6.16+
---
drivers/hv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 7937ac0cbd0f..2d0b3fcb0ff8 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -9,7 +9,6 @@ config HYPERV
select PARAVIRT
select X86_HV_CALLBACK_VECTOR if X86
select OF_EARLY_FLATTREE if OF
- select SYSFB if EFI && !HYPERV_VTL_MODE
select IRQ_MSI_LIB if X86
help
Select this option to run Linux as a Hyper-V client operating
@@ -62,6 +61,7 @@ config HYPERV_VMBUS
tristate "Microsoft Hyper-V VMBus driver"
depends on HYPERV
default HYPERV
+ select SYSFB if EFI && !HYPERV_VTL_MODE
help
Select this option to enable Hyper-V Vmbus driver.
--
2.53.0
^ permalink raw reply related
* [PATCH 4/8] firmware: sysfb: Split sysfb.c into sysfb_primary.c and sysfb_pci.c
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann
In-Reply-To: <20260402092305.208728-1-tzimmermann@suse.de>
Move the init code for the primary graphics device and the PCI-helpers
into separate source files. Only build the PCI helpers if CONFIG_PCI is
set. Prepares sysfb for additional PCI helpers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/firmware/Makefile | 7 ++++--
drivers/firmware/sysfb.h | 19 ++++++++++++++
drivers/firmware/sysfb_pci.c | 21 ++++++++++++++++
drivers/firmware/{sysfb.c => sysfb_primary.c} | 25 ++-----------------
4 files changed, 47 insertions(+), 25 deletions(-)
create mode 100644 drivers/firmware/sysfb.h
create mode 100644 drivers/firmware/sysfb_pci.c
rename drivers/firmware/{sysfb.c => sysfb_primary.c} (92%)
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 4ddec2820c96..5b0592c078df 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -16,13 +16,16 @@ obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
obj-$(CONFIG_MTK_ADSP_IPC) += mtk-adsp-ipc.o
obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o
-obj-$(CONFIG_SYSFB) += sysfb.o
-obj-$(CONFIG_SYSFB_SIMPLEFB) += sysfb_simplefb.o
obj-$(CONFIG_TH1520_AON_PROTOCOL) += thead,th1520-aon.o
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o
+sysfb-y := sysfb_primary.o
+sysfb-$(CONFIG_PCI) += sysfb_pci.o
+sysfb-$(CONFIG_SYSFB_SIMPLEFB) += sysfb_simplefb.o
+obj-$(CONFIG_SYSFB) += sysfb.o
+
obj-y += arm_ffa/
obj-y += arm_scmi/
obj-y += broadcom/
diff --git a/drivers/firmware/sysfb.h b/drivers/firmware/sysfb.h
new file mode 100644
index 000000000000..9f7fe2e03f68
--- /dev/null
+++ b/drivers/firmware/sysfb.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef FIRMWARE_SYSFB_H
+#define FIRMWARE_SYSFB_H
+
+#include <linux/types.h>
+
+struct pci_dev;
+
+#ifdef CONFIG_PCI
+bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev);
+#else
+static inline bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
+{
+ return false;
+}
+#endif
+
+#endif
diff --git a/drivers/firmware/sysfb_pci.c b/drivers/firmware/sysfb_pci.c
new file mode 100644
index 000000000000..8f3adeef4fb1
--- /dev/null
+++ b/drivers/firmware/sysfb_pci.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include <linux/pci.h>
+
+#include "sysfb.h"
+
+bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
+{
+ /*
+ * 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;
+}
diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb_primary.c
similarity index 92%
rename from drivers/firmware/sysfb.c
rename to drivers/firmware/sysfb_primary.c
index 8833582c1883..ab8d7fc468bb 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb_primary.c
@@ -35,6 +35,8 @@
#include <linux/screen_info.h>
#include <linux/sysfb.h>
+#include "sysfb.h"
+
static struct platform_device *pd;
static DEFINE_MUTEX(disable_lock);
static bool disabled;
@@ -98,29 +100,6 @@ bool sysfb_handles_screen_info(void)
}
EXPORT_SYMBOL_GPL(sysfb_handles_screen_info);
-#if defined(CONFIG_PCI)
-static bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
-{
- /*
- * 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
-static bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev)
-{
- return false;
-}
-#endif
-
static struct device *sysfb_parent_dev(const struct screen_info *si)
{
struct pci_dev *pdev;
--
2.53.0
^ permalink raw reply related
* [PATCH 0/8] firmware: sysfb: Consolidate config/code wrt. sysfb_primary_screen
From: Thomas Zimmermann @ 2026-04-02 9:09 UTC (permalink / raw)
To: javierm, arnd, ardb, ilias.apalodimas, chenhuacai, kernel,
maarten.lankhorst, mripard, airlied, simona, kys, haiyangz,
wei.liu, decui, longli, deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, Thomas Zimmermann
The global state sysfb_primary_screen holds information about the
framebuffer provided by EFI/BIOS systems. It is part of the sysfb
module, but used in several places without direct connection to
sysfb. Fix this by making users of sysfb_primary_screen depend on
CONFIG_SYSFB. Fix a few issues in the process.
Patches 1 and 2 fix general errors in the Kconfig rules. In any case,
these patches should be considered even without the rest of the series.
Patch 3 makes CONFIG_SYSFB a user-controlled option, which gives users
more control over the configuration.
Patches 4 to 6 slightly refactor the sysfb code. The PCI helpers are
now in a separate source file. Support for relocating the PCI framebuffer
is now located in sysfb, where it belongs.
Patches 7 and 8 make earlycon and the firmware EDID depend on sysfb. Both
rely on sysfb_primary_display to work correctly.
Smoke-tested with bochs on qemu. Built with/without CONFIG_SYSFB enabled.
Note: vgaarb still guards sysfb_primary_display with CONFIG_X86 instead
of CONFIG_SYSFB. That works reliably and is left in place, as a change to
guard with SYSFB_SYSFB might affect non-x86 systems in unknown ways.
Thomas Zimmermann (8):
hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
firmware: efi: Never declare sysfb_primary_display on x86
firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
firmware: sysfb: Split sysfb.c into sysfb_primary.c and sysfb_pci.c
firmware: sysfb: Implement screen_info relocation for primary display
firmware: sysfb: Avoid forward-declaring sysfb_parent_dev()
firmware: efi: Make CONFIG_EFI_EARLYCON depend on CONFIG_SYSFB; clean
up
firmware: sysfb: Move CONFIG_FIRMWARE_EDID to firmware options
arch/arm64/kernel/image-vars.h | 2 +-
arch/loongarch/configs/loongson32_defconfig | 1 +
arch/loongarch/configs/loongson64_defconfig | 1 +
arch/loongarch/kernel/efi.c | 4 +-
arch/loongarch/kernel/image-vars.h | 2 +-
arch/riscv/kernel/image-vars.h | 2 +-
drivers/firmware/Kconfig | 38 ++++-
drivers/firmware/Makefile | 7 +-
drivers/firmware/efi/Kconfig | 3 +-
drivers/firmware/efi/efi-init.c | 6 +-
drivers/firmware/efi/libstub/efi-stub-entry.c | 4 +-
drivers/firmware/sysfb.h | 24 ++++
drivers/firmware/sysfb_pci.c | 132 ++++++++++++++++++
drivers/firmware/{sysfb.c => sysfb_primary.c} | 70 ++++------
drivers/gpu/drm/sysfb/Kconfig | 4 +-
drivers/hv/Kconfig | 2 +-
drivers/video/Kconfig | 19 ---
drivers/video/fbdev/Kconfig | 5 +-
drivers/video/screen_info_pci.c | 110 ---------------
include/linux/screen_info.h | 3 -
20 files changed, 241 insertions(+), 198 deletions(-)
create mode 100644 drivers/firmware/sysfb.h
create mode 100644 drivers/firmware/sysfb_pci.c
rename drivers/firmware/{sysfb.c => sysfb_primary.c} (90%)
base-commit: 5d36e6d54e963f0c1137aaf2249d2baa781f08c2
--
2.53.0
^ permalink raw reply
* Re: [PATCH v10 07/21] gpu: nova-core: mm: Add TLB flush support
From: Matthew Brost @ 2026-04-02 5:59 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, rust-for-linux, Nikola Djukic, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian Koenig, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-8-joelagnelf@nvidia.com>
On Tue, Mar 31, 2026 at 05:20:34PM -0400, Joel Fernandes wrote:
> Add TLB (Translation Lookaside Buffer) flush support for GPU MMU.
>
> After modifying page table entries, the GPU's TLB must be invalidated
> to ensure the new mappings take effect. The Tlb struct provides flush
> functionality through BAR0 registers.
>
> The flush operation writes the page directory base address and triggers
> an invalidation, polling for completion with a 2 second timeout matching
> the Nouveau driver.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/mm.rs | 1 +
> drivers/gpu/nova-core/mm/tlb.rs | 95 +++++++++++++++++++++++++++++++++
> drivers/gpu/nova-core/regs.rs | 42 +++++++++++++++
> 3 files changed, 138 insertions(+)
> create mode 100644 drivers/gpu/nova-core/mm/tlb.rs
>
> diff --git a/drivers/gpu/nova-core/mm.rs b/drivers/gpu/nova-core/mm.rs
> index 8f3089a5fa88..cfe9cbe11d57 100644
> --- a/drivers/gpu/nova-core/mm.rs
> +++ b/drivers/gpu/nova-core/mm.rs
> @@ -5,6 +5,7 @@
> #![expect(dead_code)]
>
> pub(crate) mod pramin;
> +pub(crate) mod tlb;
>
> use kernel::sizes::SZ_4K;
>
> diff --git a/drivers/gpu/nova-core/mm/tlb.rs b/drivers/gpu/nova-core/mm/tlb.rs
> new file mode 100644
> index 000000000000..cd3cbcf4c739
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm/tlb.rs
> @@ -0,0 +1,95 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! TLB (Translation Lookaside Buffer) flush support for GPU MMU.
> +//!
> +//! After modifying page table entries, the GPU's TLB must be flushed to
> +//! ensure the new mappings take effect. This module provides TLB flush
> +//! functionality for virtual memory managers.
> +//!
> +//! # Example
> +//!
> +//! ```ignore
> +//! use crate::mm::tlb::Tlb;
> +//!
> +//! fn page_table_update(tlb: &Tlb, pdb_addr: VramAddress) -> Result<()> {
> +//! // ... modify page tables ...
> +//!
> +//! // Flush TLB to make changes visible (polls for completion).
> +//! tlb.flush(pdb_addr)?;
> +//!
> +//! Ok(())
> +//! }
> +//! ```
> +
> +use kernel::{
> + devres::Devres,
> + io::poll::read_poll_timeout,
> + io::Io,
> + new_mutex,
> + prelude::*,
> + sync::{
> + Arc,
> + Mutex, //
> + },
> + time::Delta, //
> +};
> +
> +use crate::{
> + driver::Bar0,
> + mm::VramAddress,
> + regs, //
> +};
> +
> +/// TLB manager for GPU translation buffer operations.
> +#[pin_data]
> +pub(crate) struct Tlb {
> + bar: Arc<Devres<Bar0>>,
> + /// TLB flush serialization lock: This lock is acquired during the
> + /// DMA fence signalling critical path. It must NEVER be held across any
> + /// reclaimable CPU memory allocations because the memory reclaim path can
> + /// call `dma_fence_wait()`, which would deadlock with this lock held.
> + #[pin]
> + lock: Mutex<()>,
> +}
> +
> +impl Tlb {
> + /// Create a new TLB manager.
> + pub(super) fn new(bar: Arc<Devres<Bar0>>) -> impl PinInit<Self> {
> + pin_init!(Self {
> + bar,
> + lock <- new_mutex!((), "tlb_flush"),
> + })
> + }
> +
> + /// Flush the GPU TLB for a specific page directory base.
> + ///
> + /// This invalidates all TLB entries associated with the given PDB address.
> + /// Must be called after modifying page table entries to ensure the GPU sees
> + /// the updated mappings.
> + pub(crate) fn flush(&self, pdb_addr: VramAddress) -> Result {
This landed on my list randomly, so I took a look.
Wouldn’t you want to virtualize the invalidation based on your device?
For example, what if you need to register interface changes on future hardware?
Or, if you’re a VF, can you even do MMIO?
I’d relayer this.
Matt
> + let _guard = self.lock.lock();
> +
> + let bar = self.bar.try_access().ok_or(ENODEV)?;
> +
> + // Write PDB address.
> + bar.write_reg(regs::NV_TLB_FLUSH_PDB_LO::from_pdb_addr(pdb_addr.raw_u64()));
> + bar.write_reg(regs::NV_TLB_FLUSH_PDB_HI::from_pdb_addr(pdb_addr.raw_u64()));
> +
> + // Trigger flush: invalidate all pages and enable.
> + bar.write_reg(
> + regs::NV_TLB_FLUSH_CTRL::zeroed()
> + .with_page_all(true)
> + .with_enable(true),
> + );
> +
> + // Poll for completion - enable bit clears when flush is done.
> + read_poll_timeout(
> + || Ok(bar.read(regs::NV_TLB_FLUSH_CTRL)),
> + |ctrl: ®s::NV_TLB_FLUSH_CTRL| !ctrl.enable(),
> + Delta::ZERO,
> + Delta::from_secs(2),
> + )?;
> +
> + Ok(())
> + }
> +}
> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
> index a3ca02345e20..5e3f5933a55c 100644
> --- a/drivers/gpu/nova-core/regs.rs
> +++ b/drivers/gpu/nova-core/regs.rs
> @@ -548,3 +548,45 @@ pub(crate) mod ga100 {
> }
> }
> }
> +
> +// MMU TLB
> +
> +register! {
> + /// TLB flush register: PDB address bits [39:8].
> + pub(crate) NV_TLB_FLUSH_PDB_LO(u32) @ 0x00b830a0 {
> + /// PDB address bits [39:8].
> + 31:0 pdb_lo => u32;
> + }
> +
> + /// TLB flush register: PDB address bits [47:40].
> + pub(crate) NV_TLB_FLUSH_PDB_HI(u32) @ 0x00b830a4 {
> + /// PDB address bits [47:40].
> + 7:0 pdb_hi => u8;
> + }
> +
> + /// TLB flush control register.
> + pub(crate) NV_TLB_FLUSH_CTRL(u32) @ 0x00b830b0 {
> + /// Invalidate all pages.
> + 0:0 page_all => bool;
> + /// Enable/trigger flush (clears when flush completes).
> + 31:31 enable => bool;
> + }
> +}
> +
> +impl NV_TLB_FLUSH_PDB_LO {
> + /// Create a register value from a PDB address.
> + ///
> + /// Extracts bits [39:8] of the address and shifts it right by 8 bits.
> + pub(crate) fn from_pdb_addr(addr: u64) -> Self {
> + Self::zeroed().with_pdb_lo(((addr >> 8) & 0xFFFF_FFFF) as u32)
> + }
> +}
> +
> +impl NV_TLB_FLUSH_PDB_HI {
> + /// Create a register value from a PDB address.
> + ///
> + /// Extracts bits [47:40] of the address and shifts it right by 40 bits.
> + pub(crate) fn from_pdb_addr(addr: u64) -> Self {
> + Self::zeroed().with_pdb_hi(((addr >> 40) & 0xFF) as u8)
> + }
> +}
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v10 21/21] gpu: nova-core: Use runtime BAR1 size instead of hardcoded 256MB
From: Eliot Courtney @ 2026-04-02 5:54 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-22-joelagnelf@nvidia.com>
On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
> From: Zhi Wang <zhiw@nvidia.com>
>
> Remove the hardcoded BAR1_SIZE = SZ_256M constant. On GPUs like L40 the
> BAR1 aperture is larger than 256MB; using a hardcoded size prevents large
> BAR1 from working and mapping it would fail.
>
> Signed-off-by: Zhi Wang <zhiw@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/driver.rs | 8 ++------
> drivers/gpu/nova-core/gpu.rs | 7 +------
> 2 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
> index b1aafaff0cee..6f95f8672158 100644
> --- a/drivers/gpu/nova-core/driver.rs
> +++ b/drivers/gpu/nova-core/driver.rs
> @@ -13,10 +13,7 @@
> Vendor, //
> },
> prelude::*,
> - sizes::{
> - SZ_16M,
> - SZ_256M, //
> - },
> + sizes::SZ_16M,
> sync::{
> atomic::{
> Atomic,
> @@ -40,7 +37,6 @@ pub(crate) struct NovaCore {
> }
>
> const BAR0_SIZE: usize = SZ_16M;
> -pub(crate) const BAR1_SIZE: usize = SZ_256M;
>
> // For now we only support Ampere which can use up to 47-bit DMA addresses.
> //
> @@ -51,7 +47,7 @@ pub(crate) struct NovaCore {
> const GPU_DMA_BITS: u32 = 47;
>
> pub(crate) type Bar0 = pci::Bar<BAR0_SIZE>;
> -pub(crate) type Bar1 = pci::Bar<BAR1_SIZE>;
> +pub(crate) type Bar1 = pci::Bar;
>
> kernel::pci_device_table!(
> PCI_TABLE,
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index 8206ec015b26..ba6f1f6f0485 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -353,16 +353,11 @@ pub(crate) fn run_selftests(
>
> #[cfg(CONFIG_NOVA_MM_SELFTESTS)]
> fn run_mm_selftests(self: Pin<&mut Self>, pdev: &pci::Device<device::Bound>) -> Result {
> - use crate::driver::BAR1_SIZE;
> -
> // PRAMIN aperture self-tests.
> crate::mm::pramin::run_self_test(pdev.as_ref(), self.mm.pramin(), self.spec.chipset)?;
>
> // BAR1 self-tests.
> - let bar1 = Arc::pin_init(
> - pdev.iomap_region_sized::<BAR1_SIZE>(1, c"nova-core/bar1"),
> - GFP_KERNEL,
> - )?;
> + let bar1 = Arc::pin_init(pdev.iomap_region(1, c"nova-core/bar1"), GFP_KERNEL)?;
> let bar1_access = bar1.access(pdev.as_ref())?;
>
> crate::mm::bar_user::run_self_test(
Can we move this directly after patch 17 which adds the fixed bar1? Or
alternatively fold it in while preserving Zhi's attribution (I am not
sure what the conventional method for this is).
^ permalink raw reply
* Re: [PATCH v10 02/21] gpu: nova-core: gsp: Extract usable FB region from GSP
From: Eliot Courtney @ 2026-04-02 5:49 UTC (permalink / raw)
To: Joel Fernandes, Eliot Courtney, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, joel, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
In-Reply-To: <d6fe3e40-0310-4b90-ac8c-8beeec886f90@nvidia.com>
On Thu Apr 2, 2026 at 8:24 AM JST, Joel Fernandes wrote:
>
>
> On 4/1/2026 4:27 AM, Eliot Courtney wrote:
>> On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
>>> Add first_usable_fb_region() to GspStaticConfigInfo to extract the first
>>> usable FB region from GSP's fbRegionInfoParams. Usable regions are those
>>> that are not reserved or protected.
>>>
>>> The extracted region is stored in GetGspStaticInfoReply and exposed as
>>> usable_fb_region field for use by the memory subsystem.
>>>
>>> Cc: Nikola Djukic <ndjukic@nvidia.com>
>>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>>> ---
>>
>> Please see my feedback from v9[1] which still applies.
>>
>> [1]: https://lore.kernel.org/all/DH1GK30TUB4V.2GR6ANXIZDFFQ@nvidia.com/
>
> Yeah, I am seeing it now. Amidst making the earlier 7.1 merge window for
> the DRM buddy and earlier patches in the series, I missed this. They seem
> to be simple nits and I will address them in the next revision. thanks,
>
> --
> Joel Fernandes
No worries. Sorry I have not gotten to more of the patches yet. Trying
to get through some more now. Thanks!
^ permalink raw reply
* Re: [PATCH v10 07/21] gpu: nova-core: mm: Add TLB flush support
From: Eliot Courtney @ 2026-04-02 5:49 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-8-joelagnelf@nvidia.com>
On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
> Add TLB (Translation Lookaside Buffer) flush support for GPU MMU.
>
> After modifying page table entries, the GPU's TLB must be invalidated
> to ensure the new mappings take effect. The Tlb struct provides flush
> functionality through BAR0 registers.
>
> The flush operation writes the page directory base address and triggers
> an invalidation, polling for completion with a 2 second timeout matching
> the Nouveau driver.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/mm.rs | 1 +
> drivers/gpu/nova-core/mm/tlb.rs | 95 +++++++++++++++++++++++++++++++++
> drivers/gpu/nova-core/regs.rs | 42 +++++++++++++++
> 3 files changed, 138 insertions(+)
> create mode 100644 drivers/gpu/nova-core/mm/tlb.rs
>
> diff --git a/drivers/gpu/nova-core/mm.rs b/drivers/gpu/nova-core/mm.rs
> index 8f3089a5fa88..cfe9cbe11d57 100644
> --- a/drivers/gpu/nova-core/mm.rs
> +++ b/drivers/gpu/nova-core/mm.rs
> @@ -5,6 +5,7 @@
> #![expect(dead_code)]
>
> pub(crate) mod pramin;
> +pub(crate) mod tlb;
>
> use kernel::sizes::SZ_4K;
>
> diff --git a/drivers/gpu/nova-core/mm/tlb.rs b/drivers/gpu/nova-core/mm/tlb.rs
> new file mode 100644
> index 000000000000..cd3cbcf4c739
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm/tlb.rs
> @@ -0,0 +1,95 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! TLB (Translation Lookaside Buffer) flush support for GPU MMU.
> +//!
> +//! After modifying page table entries, the GPU's TLB must be flushed to
> +//! ensure the new mappings take effect. This module provides TLB flush
> +//! functionality for virtual memory managers.
> +//!
> +//! # Example
> +//!
> +//! ```ignore
> +//! use crate::mm::tlb::Tlb;
> +//!
> +//! fn page_table_update(tlb: &Tlb, pdb_addr: VramAddress) -> Result<()> {
> +//! // ... modify page tables ...
> +//!
> +//! // Flush TLB to make changes visible (polls for completion).
> +//! tlb.flush(pdb_addr)?;
> +//!
> +//! Ok(())
> +//! }
> +//! ```
> +
> +use kernel::{
> + devres::Devres,
> + io::poll::read_poll_timeout,
> + io::Io,
> + new_mutex,
> + prelude::*,
> + sync::{
> + Arc,
> + Mutex, //
> + },
> + time::Delta, //
> +};
> +
> +use crate::{
> + driver::Bar0,
> + mm::VramAddress,
> + regs, //
> +};
> +
> +/// TLB manager for GPU translation buffer operations.
> +#[pin_data]
> +pub(crate) struct Tlb {
> + bar: Arc<Devres<Bar0>>,
> + /// TLB flush serialization lock: This lock is acquired during the
> + /// DMA fence signalling critical path. It must NEVER be held across any
> + /// reclaimable CPU memory allocations because the memory reclaim path can
> + /// call `dma_fence_wait()`, which would deadlock with this lock held.
> + #[pin]
This comment says that the lock is acquired during the DMA fence
signalling critical path, but IIUC we don't have anything like that
right now. Is this based on future yet to be done work? Can we reword
this in a way so it makes sense in the current state?
> + lock: Mutex<()>,
> +}
> +
> +impl Tlb {
> + /// Create a new TLB manager.
> + pub(super) fn new(bar: Arc<Devres<Bar0>>) -> impl PinInit<Self> {
> + pin_init!(Self {
> + bar,
> + lock <- new_mutex!((), "tlb_flush"),
> + })
> + }
> +
> + /// Flush the GPU TLB for a specific page directory base.
> + ///
> + /// This invalidates all TLB entries associated with the given PDB address.
> + /// Must be called after modifying page table entries to ensure the GPU sees
> + /// the updated mappings.
If this must be called after every operation like that, I wonder if we
can change the design to require a guard like pattern something to
ensure flush is called. WDYT?
> + pub(crate) fn flush(&self, pdb_addr: VramAddress) -> Result {
Hopefully we don't need to be calling flush() from anywhere in the
entire crate. Can you tighten the visibility here and in other places?
Many things seem to be pub(crate) that don't need to be.
> + let _guard = self.lock.lock();
> +
> + let bar = self.bar.try_access().ok_or(ENODEV)?;
> +
> + // Write PDB address.
> + bar.write_reg(regs::NV_TLB_FLUSH_PDB_LO::from_pdb_addr(pdb_addr.raw_u64()));
> + bar.write_reg(regs::NV_TLB_FLUSH_PDB_HI::from_pdb_addr(pdb_addr.raw_u64()));
> +
> + // Trigger flush: invalidate all pages and enable.
> + bar.write_reg(
> + regs::NV_TLB_FLUSH_CTRL::zeroed()
> + .with_page_all(true)
> + .with_enable(true),
> + );
> +
> + // Poll for completion - enable bit clears when flush is done.
> + read_poll_timeout(
> + || Ok(bar.read(regs::NV_TLB_FLUSH_CTRL)),
> + |ctrl: ®s::NV_TLB_FLUSH_CTRL| !ctrl.enable(),
> + Delta::ZERO,
> + Delta::from_secs(2),
> + )?;
This has zero delay on the read_poll_timeout - what about adding a small
delay of a microsecond or so?
^ permalink raw reply
* Re: [PATCH v10 10/21] gpu: nova-core: mm: Add MMU v2 page table types
From: Eliot Courtney @ 2026-04-02 5:41 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-11-joelagnelf@nvidia.com>
On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
> Add page table entry and directory structures for MMU version 2
> used by Turing/Ampere/Ada GPUs.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/mm/pagetable.rs | 2 +
> drivers/gpu/nova-core/mm/pagetable/ver2.rs | 232 +++++++++++++++++++++
> 2 files changed, 234 insertions(+)
> create mode 100644 drivers/gpu/nova-core/mm/pagetable/ver2.rs
>
> diff --git a/drivers/gpu/nova-core/mm/pagetable.rs b/drivers/gpu/nova-core/mm/pagetable.rs
> index 50b76d5e5aaf..38d88f8f09a9 100644
> --- a/drivers/gpu/nova-core/mm/pagetable.rs
> +++ b/drivers/gpu/nova-core/mm/pagetable.rs
> @@ -8,6 +8,8 @@
>
> #![expect(dead_code)]
>
> +pub(crate) mod ver2;
> +
This looks like it has more visibility than necessary. And it seems
incorrect for anyone in the crate to care about MMU version details.
This can probably be just 'mod ver2'. There are a lot of other types /
functions in this series that could have tighter visibility. Could you
go through and see if you can reduce a bunch to private or pub(super)?
thanks!
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Eliot Courtney @ 2026-04-02 5:40 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-13-joelagnelf@nvidia.com>
On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
> Add unified Pte, Pde, and DualPde wrapper enums that abstract over
> MMU v2 and v3 page table entry formats. These enums allow the page
> table walker and VMM to work with both MMU versions.
>
> Each unified type:
> - Takes MmuVersion parameter in constructors
> - Wraps both ver2 and ver3 variants
> - Delegates method calls to the appropriate variant
>
> This enables version-agnostic page table operations while keeping
> version-specific implementation details encapsulated in the ver2
> and ver3 modules.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/mm/pagetable.rs | 330 ++++++++++++++++++++++++++
> 1 file changed, 330 insertions(+)
>
> diff --git a/drivers/gpu/nova-core/mm/pagetable.rs b/drivers/gpu/nova-core/mm/pagetable.rs
> index 6e01a1af5222..909df37c3ee8 100644
> --- a/drivers/gpu/nova-core/mm/pagetable.rs
> +++ b/drivers/gpu/nova-core/mm/pagetable.rs
> @@ -12,6 +12,13 @@
> pub(crate) mod ver3;
>
> use crate::gpu::Architecture;
> +use crate::mm::{
> + pramin,
> + Pfn,
> + VirtualAddress,
> + VramAddress, //
> +};
> +use kernel::prelude::*;
>
> /// Extracts the page table index at a given level from a virtual address.
> pub(crate) trait VaLevelIndex {
> @@ -84,6 +91,96 @@ pub(crate) const fn as_index(&self) -> u64 {
> }
> }
>
> +impl MmuVersion {
> + /// Get the `PDE` levels (excluding PTE level) for page table walking.
> + pub(crate) fn pde_levels(&self) -> &'static [PageTableLevel] {
> + match self {
> + Self::V2 => ver2::PDE_LEVELS,
> + Self::V3 => ver3::PDE_LEVELS,
> + }
> + }
> +
> + /// Get the PTE level for this MMU version.
> + pub(crate) fn pte_level(&self) -> PageTableLevel {
> + match self {
> + Self::V2 => ver2::PTE_LEVEL,
> + Self::V3 => ver3::PTE_LEVEL,
> + }
> + }
> +
> + /// Get the dual PDE level (128-bit entries) for this MMU version.
> + pub(crate) fn dual_pde_level(&self) -> PageTableLevel {
> + match self {
> + Self::V2 => ver2::DUAL_PDE_LEVEL,
> + Self::V3 => ver3::DUAL_PDE_LEVEL,
> + }
> + }
> +
> + /// Get the number of PDE levels for this MMU version.
> + pub(crate) fn pde_level_count(&self) -> usize {
> + self.pde_levels().len()
> + }
> +
> + /// Get the entry size in bytes for a given level.
> + pub(crate) fn entry_size(&self, level: PageTableLevel) -> usize {
> + if level == self.dual_pde_level() {
> + 16 // 128-bit dual PDE
> + } else {
> + 8 // 64-bit PDE/PTE
> + }
> + }
> +
> + /// Get the number of entries per page table page for a given level.
> + pub(crate) fn entries_per_page(&self, level: PageTableLevel) -> usize {
> + match self {
> + Self::V2 => match level {
> + // TODO: Calculate these values from the bitfield dynamically
> + // instead of hardcoding them.
> + PageTableLevel::Pdb => 4, // PD3 root: bits [48:47] = 2 bits
> + PageTableLevel::L3 => 256, // PD0 dual: bits [28:21] = 8 bits
> + _ => 512, // PD2, PD1, PT: 9 bits each
> + },
> + Self::V3 => match level {
> + PageTableLevel::Pdb => 2, // PDE4 root: bit [56] = 1 bit, 2 entries
> + PageTableLevel::L4 => 256, // PDE0 dual: bits [28:21] = 8 bits
> + _ => 512, // PDE3, PDE2, PDE1, PT: 9 bits each
> + },
> + }
> + }
> +
> + /// Extract the page table index at `level` from `va` for this MMU version.
> + pub(crate) fn level_index(&self, va: VirtualAddress, level: u64) -> u64 {
> + match self {
> + Self::V2 => ver2::VirtualAddressV2::new(va).level_index(level),
> + Self::V3 => ver3::VirtualAddressV3::new(va).level_index(level),
> + }
> + }
> +
> + /// Compute upper bound on page table pages needed for `num_virt_pages`.
> + ///
> + /// Walks from PTE level up through PDE levels, accumulating the tree.
> + pub(crate) fn pt_pages_upper_bound(&self, num_virt_pages: usize) -> usize {
> + let mut total = 0;
> +
> + // PTE pages at the leaf level.
> + let pte_epp = self.entries_per_page(self.pte_level());
> + let mut pages_at_level = num_virt_pages.div_ceil(pte_epp);
> + total += pages_at_level;
> +
> + // Walk PDE levels bottom-up (reverse of pde_levels()).
> + for &level in self.pde_levels().iter().rev() {
> + let epp = self.entries_per_page(level);
> +
> + // How many pages at this level do we need to point to
> + // the previous pages_at_level?
> + pages_at_level = pages_at_level.div_ceil(epp);
> + total += pages_at_level;
> + }
> +
> + total
> + }
> +}
> +
We have a lot of matches on the MMU version here (and below in Pte, Pde,
DualPde). What about making MmuVersion into a trait (e.g. Mmu) with
associated types for Pte, Pde, DualPde which can implement traits
defining their common operations too? Then you can parameterise
Vmm/PtWalk on this type.
^ permalink raw reply
* Re: [PATCH v10 03/21] gpu: nova-core: gsp: Expose total physical VRAM end from FB region info
From: Eliot Courtney @ 2026-04-02 5:37 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, Eliot Courtney, joel, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260331212048.2229260-4-joelagnelf@nvidia.com>
On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
> Add `total_fb_end()` to `GspStaticConfigInfo` that computes the
> exclusive end address of the highest valid FB region covering both
> usable and GSP-reserved areas.
>
> This allows callers to know the full physical VRAM extent, not just
> the allocatable portion.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/gsp/commands.rs | 6 ++++++
> drivers/gpu/nova-core/gsp/fw/commands.rs | 7 +++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/nova-core/gsp/commands.rs b/drivers/gpu/nova-core/gsp/commands.rs
> index 41742c1633c8..5e0649024637 100644
> --- a/drivers/gpu/nova-core/gsp/commands.rs
> +++ b/drivers/gpu/nova-core/gsp/commands.rs
> @@ -196,6 +196,9 @@ pub(crate) struct GetGspStaticInfoReply {
> /// Usable FB (VRAM) region for driver memory allocation.
> #[expect(dead_code)]
> pub(crate) usable_fb_region: Range<u64>,
> + /// End of VRAM.
> + #[expect(dead_code)]
> + pub(crate) total_fb_end: u64,
> }
>
> impl MessageFromGsp for GetGspStaticInfoReply {
> @@ -209,9 +212,12 @@ fn read(
> ) -> Result<Self, Self::InitError> {
> let (base, size) = msg.first_usable_fb_region().ok_or(ENODEV)?;
>
> + let total_fb_end = msg.total_fb_end().ok_or(ENODEV)?;
> +
> Ok(GetGspStaticInfoReply {
> gpu_name: msg.gpu_name_str(),
> usable_fb_region: base..base.saturating_add(size),
> + total_fb_end,
> })
> }
> }
> diff --git a/drivers/gpu/nova-core/gsp/fw/commands.rs b/drivers/gpu/nova-core/gsp/fw/commands.rs
> index 9fffa74d03f9..46932d5c8c1d 100644
> --- a/drivers/gpu/nova-core/gsp/fw/commands.rs
> +++ b/drivers/gpu/nova-core/gsp/fw/commands.rs
> @@ -163,6 +163,13 @@ pub(crate) fn first_usable_fb_region(&self) -> Option<(u64, u64)> {
> }
> })
> }
> +
> + /// Compute the end of physical VRAM from all FB regions.
> + pub(crate) fn total_fb_end(&self) -> Option<u64> {
> + self.fb_regions()
> + .map(|reg| reg.limit.saturating_add(1))
I think it would be better to used checked_add here.
> + .max()
> + }
> }
>
> // SAFETY: Padding is explicit and will not contain uninitialized data.
^ permalink raw reply
* Re: [PATCH v10 02/21] gpu: nova-core: gsp: Extract usable FB region from GSP
From: Joel Fernandes @ 2026-04-01 23:24 UTC (permalink / raw)
To: Eliot Courtney, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, alexeyi, joel, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
In-Reply-To: <DHHOCGNIYDW3.1P7YIMVLW93IY@nvidia.com>
On 4/1/2026 4:27 AM, Eliot Courtney wrote:
> On Wed Apr 1, 2026 at 6:20 AM JST, Joel Fernandes wrote:
>> Add first_usable_fb_region() to GspStaticConfigInfo to extract the first
>> usable FB region from GSP's fbRegionInfoParams. Usable regions are those
>> that are not reserved or protected.
>>
>> The extracted region is stored in GetGspStaticInfoReply and exposed as
>> usable_fb_region field for use by the memory subsystem.
>>
>> Cc: Nikola Djukic <ndjukic@nvidia.com>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> ---
>
> Please see my feedback from v9[1] which still applies.
>
> [1]: https://lore.kernel.org/all/DH1GK30TUB4V.2GR6ANXIZDFFQ@nvidia.com/
Yeah, I am seeing it now. Amidst making the earlier 7.1 merge window for
the DRM buddy and earlier patches in the series, I missed this. They seem
to be simple nits and I will address them in the next revision. thanks,
--
Joel Fernandes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox