aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware/sysfb.c
AgeCommit message (Collapse)AuthorFilesLines
2024-09-26firmware/sysfb: Disable sysfb for firmware buffers with unknown parentThomas Zimmermann1-1/+3
The sysfb framebuffer handling only operates on graphics devices that provide the system's firmware framebuffer. If that device is not known, assume that any graphics device has been initialized by firmware. Fixes a problem on i915 where sysfb does not release the firmware framebuffer after the native graphics driver loaded. Reported-by: Borah, Chaitanya Kumar <[email protected]> Closes: https://lore.kernel.org/dri-devel/SJ1PR11MB6129EFB8CE63D1EF6D932F94B96F2@SJ1PR11MB6129.namprd11.prod.outlook.com/ Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160 Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: b49420d6a1ae ("video/aperture: optionally match the device in sysfb_disable()") Cc: Javier Martinez Canillas <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Helge Deller <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Cc: Linux regression tracking (Thorsten Leemhuis) <[email protected]> Cc: <[email protected]> # v6.11+ Acked-by: Alex Deucher <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-26video/aperture: optionally match the device in sysfb_disable()Alex Deucher1-6/+13
In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible: 1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so sysfb_disable() is not called, but the device resources are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. NULL pointer dereference via sysfb_disable() since the resources have already been freed by aperture_detach_platform_device() when it was called by the other device. Fix this by passing a device pointer to sysfb_disable() and checking the device to determine if we should execute it or not. v2: Fix build when CONFIG_SCREEN_INFO is not set v3: Move device check into the mutex Drop primary variable in aperture_remove_conflicting_pci_devices() Drop __init on pci sysfb_pci_dev_is_enabled() Fixes: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device") Cc: Javier Martinez Canillas <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Helge Deller <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-28firmware: sysfb: Fix reference count of sysfb parent deviceThomas Zimmermann1-4/+8
Retrieving the system framebuffer's parent device in sysfb_init() increments the parent device's reference count. Hence release the reference before leaving the init function. Adding the sysfb platform device acquires and additional reference for the parent. This keeps the parent device around while the system framebuffer is in use. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device") Cc: Thomas Zimmermann <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: Helge Deller <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Sui Jingfeng <[email protected]> Cc: <[email protected]> # v6.9+ Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-27firmware/sysfb: fix an error code in sysfb_init()Dan Carpenter1-1/+3
This error path accidentally returns success when it should preserve the error code from sysfb_parent_dev(). Fixes: 4e754597d603 ("firmware/sysfb: Create firmware device only for enabled PCI devices") Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-14firmware/sysfb: Update screen_info for relocated EFI framebuffersThomas Zimmermann1-0/+2
On ARM PCI systems, the PCI hierarchy might be reconfigured during boot and the firmware framebuffer might move as a result of that. The values in screen_info will then be invalid. Work around this problem by tracking the framebuffer's initial location before it get relocated; then fix the screen_info state between reloaction and creating the firmware framebuffer's device. This functionality has been lifted from efifb. See the commit message of commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer") for more information. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-14firmware/sysfb: Create firmware device only for enabled PCI devicesThomas Zimmermann1-2/+30
Test if the firmware framebuffer's parent PCI device, if any, has been enabled. If not, the firmware framebuffer is most likely not working. Hence, do not create a device for the firmware framebuffer on disabled PCI devices. So far, efifb tracked the status of the PCI parent device internally and did not bind if it was disabled. This patch implements the functionality for all PCI-based firmware framebuffers. v3: * make commit message more precise (Sui) v2: * rework sysfb_pci_dev_is_enabled() (Javier) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-14firmware/sysfb: Set firmware-framebuffer parent deviceThomas Zimmermann1-1/+20
Set the firmware framebuffer's parent device, which usually is the graphics hardware's physical device. Integrates the framebuffer in the Linux device hierarchy and lets Linux handle dependencies among devices. For example, the graphics hardware won't be suspended while the firmware device is still active. v4: * fix build for CONFIG_SYSFB_SIMPLEFB=n, again v3: * fix build for CONFIG_SYSFB_SIMPLEFB=n (Sui) * test result of screen_info_pci_dev() for errors (Sui) v2: * detect parent device in sysfb_parent_dev() Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-01-24Revert "drivers/firmware: Move sysfb_init() from device_initcall to ↵Thomas Zimmermann1-1/+1
subsys_initcall_sync" This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4. Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync") messes up initialization order of the graphics drivers and leads to blank displays on some systems. So revert the commit. To make the display drivers fully independent from initialization order requires to track framebuffer memory by device and independently from the loaded drivers. The kernel currently lacks the infrastructure to do so. Reported-by: Jaak Ristioja <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/T/#t Reported-by: Huacai Chen <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10133 Signed-off-by: Thomas Zimmermann <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: Thorsten Leemhuis <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] # v6.5+ Reviewed-by: Javier Martinez Canillas <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-05-15drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_syncHuacai Chen1-1/+1
Consider a configuration like this: 1, efifb (or simpledrm) is built-in; 2, a native display driver (such as radeon) is also built-in. As Javier said, this is not a common configuration (the native display driver is usually built as a module), but it can happen and cause some trouble. In this case, since efifb, radeon and sysfb are all in device_initcall() level, the order in practise is like this: efifb registered at first, but no "efi-framebuffer" device yet. radeon registered later, and /dev/fb0 created. sysfb_init() comes at last, it registers "efi-framebuffer" and then causes an error message "efifb: a framebuffer is already registered". Make sysfb_init() to be subsys_ initcall_sync() can avoid this. And Javier Martinez Canillas is trying to make a more general solution in commit 873eb3b11860 ("fbdev: Disable sysfb device registration when removing conflicting FBs"). However, this patch still makes sense because it can make the screen display as early as possible (We cannot move to subsys_initcall, since sysfb_init() should be executed after PCI enumeration). Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-18efi: sysfb_efi: Fix DMI quirks not working for simpledrmHans de Goede1-1/+3
Commit 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") moved the sysfb_apply_efi_quirks() call in sysfb_init() from before the [sysfb_]parse_mode() call to after it. But sysfb_apply_efi_quirks() modifies the global screen_info struct which [sysfb_]parse_mode() parses, so doing it later is too late. This has broken all DMI based quirks for correcting wrong firmware efifb settings when simpledrm is used. To fix this move the sysfb_apply_efi_quirks() call back to its old place and split the new setup of the efifb_fwnode (which requires the platform_device) into its own function and call that at the place of the moved sysfb_apply_efi_quirks(pd) calls. Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") Cc: [email protected] Cc: Javier Martinez Canillas <[email protected]> Cc: Thomas Zimmermann <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2022-07-19fbdev/vga16fb: Create EGA/VGA devices in sysfb codeThomas Zimmermann1-0/+4
Move the device-creation from vga16fb to sysfb code. The driver's videomode checks are independent from device creation, so move them into vga16fb's probe function. This will allow to create the module init/exit code automatically. The vga16fb driver requires a screen_info for type VIDEO_TYPE_VGAC or VIDEO_TYPE_EGAC. Such code is nowhere present in the kernel, except for some MIPS systems. It's not clear if the vga16fb driver actually works in practice. v2: * keep driver name to "vga16fb" (Javier) * give rational for moving mode checks (Javier) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-06-09firmware: sysfb: Add sysfb_disable() helper functionJavier Martinez Canillas1-6/+48
This can be used by subsystems to unregister a platform device registered by sysfb and also to disable future platform device registration in sysfb. Suggested-by: Daniel Vetter <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-06-09firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointerJavier Martinez Canillas1-2/+2
This function just returned 0 on success or an errno code on error, but it could be useful for sysfb_init() callers to have a pointer to the device. Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-21drivers/firmware: consolidate EFI framebuffer setup for all archesJavier Martinez Canillas1-11/+24
The register_gop_device() function registers an "efi-framebuffer" platform device to match against the efifb driver, to have an early framebuffer for EFI platforms. But there is already support to do exactly the same by the Generic System Framebuffers (sysfb) driver. This used to be only for X86 but it has been moved to drivers/firmware and could be reused by other architectures. Also, besides supporting registering an "efi-framebuffer", this driver can register a "simple-framebuffer" allowing to use the siple{fb,drm} drivers on non-X86 EFI platforms. For example, on aarch64 these drivers can only be used with DT and doesn't have code to register a "simple-frambuffer" platform device when booting with EFI. For these reasons, let's remove the register_gop_device() duplicated code and instead move the platform specific logic that's there to sysfb driver. Signed-off-by: Javier Martinez Canillas <[email protected]> Acked-by: Borislav Petkov <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-21drivers/firmware: move x86 Generic System Framebuffers supportJavier Martinez Canillas1-0/+70
The x86 architecture has generic support to register a system framebuffer platform device. It either registers a "simple-framebuffer" if the config option CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device. But the code is generic enough to be reused by other architectures and can be moved out of the arch/x86 directory. This will allow to also support the simple{fb,drm} drivers on non-x86 EFI platforms, such as aarch64 where these drivers are only supported with DT. Signed-off-by: Javier Martinez Canillas <[email protected]> Acked-by: Borislav Petkov <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]