2019-05-27 06:55:01 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2022-07-09 18:30:19 +00:00
|
|
|
#ifndef _LINUX_SYSFB_H
|
|
|
|
#define _LINUX_SYSFB_H
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Generic System Framebuffers on x86
|
|
|
|
* Copyright (c) 2012-2013 David Herrmann <dh.herrmann@gmail.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/platform_data/simplefb.h>
|
|
|
|
#include <linux/screen_info.h>
|
|
|
|
|
2013-08-02 12:05:23 +00:00
|
|
|
enum {
|
|
|
|
M_I17, /* 17-Inch iMac */
|
|
|
|
M_I20, /* 20-Inch iMac */
|
|
|
|
M_I20_SR, /* 20-Inch iMac (Santa Rosa) */
|
|
|
|
M_I24, /* 24-Inch iMac */
|
|
|
|
M_I24_8_1, /* 24-Inch iMac, 8,1th gen */
|
|
|
|
M_I24_10_1, /* 24-Inch iMac, 10,1th gen */
|
|
|
|
M_I27_11_1, /* 27-Inch iMac, 11,1th gen */
|
|
|
|
M_MINI, /* Mac Mini */
|
|
|
|
M_MINI_3_1, /* Mac Mini, 3,1th gen */
|
|
|
|
M_MINI_4_1, /* Mac Mini, 4,1th gen */
|
|
|
|
M_MB, /* MacBook */
|
|
|
|
M_MB_2, /* MacBook, 2nd rev. */
|
|
|
|
M_MB_3, /* MacBook, 3rd rev. */
|
|
|
|
M_MB_5_1, /* MacBook, 5th rev. */
|
|
|
|
M_MB_6_1, /* MacBook, 6th rev. */
|
|
|
|
M_MB_7_1, /* MacBook, 7th rev. */
|
|
|
|
M_MB_SR, /* MacBook, 2nd gen, (Santa Rosa) */
|
|
|
|
M_MBA, /* MacBook Air */
|
|
|
|
M_MBA_3, /* Macbook Air, 3rd rev */
|
|
|
|
M_MBP, /* MacBook Pro */
|
|
|
|
M_MBP_2, /* MacBook Pro 2nd gen */
|
|
|
|
M_MBP_2_2, /* MacBook Pro 2,2nd gen */
|
|
|
|
M_MBP_SR, /* MacBook Pro (Santa Rosa) */
|
|
|
|
M_MBP_4, /* MacBook Pro, 4th gen */
|
|
|
|
M_MBP_5_1, /* MacBook Pro, 5,1th gen */
|
|
|
|
M_MBP_5_2, /* MacBook Pro, 5,2th gen */
|
|
|
|
M_MBP_5_3, /* MacBook Pro, 5,3rd gen */
|
|
|
|
M_MBP_6_1, /* MacBook Pro, 6,1th gen */
|
|
|
|
M_MBP_6_2, /* MacBook Pro, 6,2th gen */
|
|
|
|
M_MBP_7_1, /* MacBook Pro, 7,1th gen */
|
|
|
|
M_MBP_8_2, /* MacBook Pro, 8,2nd gen */
|
|
|
|
M_UNKNOWN /* placeholder */
|
|
|
|
};
|
|
|
|
|
|
|
|
struct efifb_dmi_info {
|
|
|
|
char *optname;
|
|
|
|
unsigned long base;
|
|
|
|
int stride;
|
|
|
|
int width;
|
|
|
|
int height;
|
|
|
|
int flags;
|
|
|
|
};
|
|
|
|
|
2022-11-14 13:30:00 +00:00
|
|
|
#ifdef CONFIG_SYSFB
|
|
|
|
|
2024-11-07 11:07:36 +00:00
|
|
|
void sysfb_disable(struct device *dev);
|
2022-11-14 13:30:00 +00:00
|
|
|
|
|
|
|
#else /* CONFIG_SYSFB */
|
|
|
|
|
2024-11-07 11:07:36 +00:00
|
|
|
static inline void sysfb_disable(struct device *dev)
|
2022-11-14 13:30:00 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_SYSFB */
|
|
|
|
|
2013-08-02 12:05:23 +00:00
|
|
|
#ifdef CONFIG_EFI
|
|
|
|
|
|
|
|
extern struct efifb_dmi_info efifb_dmi_list[];
|
2023-09-29 10:58:28 +00:00
|
|
|
void sysfb_apply_efi_quirks(void);
|
|
|
|
void sysfb_set_efifb_fwnode(struct platform_device *pd);
|
2013-08-02 12:05:23 +00:00
|
|
|
|
|
|
|
#else /* CONFIG_EFI */
|
|
|
|
|
2023-09-29 10:58:28 +00:00
|
|
|
static inline void sysfb_apply_efi_quirks(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void sysfb_set_efifb_fwnode(struct platform_device *pd)
|
2013-08-02 12:05:23 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_EFI */
|
|
|
|
|
drivers/firmware: consolidate EFI framebuffer setup for all arches
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071830
Depends: https://bugzilla.redhat.com/show_bug.cgi?id=2071840
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. At this stage, this
has been tested by ensuring we can survive the CI/CD loop -- i.e.,
that we have not broken anything else, and a simple boot test. When
sufficient drivers have been brought in for i.MX8M, we will be able
to run further tests.
commit 8633ef82f101c040427b57d4df7b706261420b94
Author: Javier Martinez Canillas <javierm@redhat.com>
Date: Fri Jun 25 15:13:59 2021 +0200
drivers/firmware: consolidate EFI framebuffer setup for all arches
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 <javierm@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com
(cherry picked from commit 8633ef82f101c040427b57d4df7b706261420b94)
Conflicts:
drivers/gpu/drm/tiny/Kconfig:
495a018a8f19c6e953a1b39ad3859d97e2af92d1 (Merge DRM changes from upstream
v5.14..v5.15) included what should have been applied with this patch so it
was no longer needed
Signed-off-by: Al Stone <ahs3@redhat.com>
2022-07-09 18:30:20 +00:00
|
|
|
#ifdef CONFIG_SYSFB_SIMPLEFB
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
|
drivers/firmware: consolidate EFI framebuffer setup for all arches
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071830
Depends: https://bugzilla.redhat.com/show_bug.cgi?id=2071840
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. At this stage, this
has been tested by ensuring we can survive the CI/CD loop -- i.e.,
that we have not broken anything else, and a simple boot test. When
sufficient drivers have been brought in for i.MX8M, we will be able
to run further tests.
commit 8633ef82f101c040427b57d4df7b706261420b94
Author: Javier Martinez Canillas <javierm@redhat.com>
Date: Fri Jun 25 15:13:59 2021 +0200
drivers/firmware: consolidate EFI framebuffer setup for all arches
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 <javierm@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com
(cherry picked from commit 8633ef82f101c040427b57d4df7b706261420b94)
Conflicts:
drivers/gpu/drm/tiny/Kconfig:
495a018a8f19c6e953a1b39ad3859d97e2af92d1 (Merge DRM changes from upstream
v5.14..v5.15) included what should have been applied with this patch so it
was no longer needed
Signed-off-by: Al Stone <ahs3@redhat.com>
2022-07-09 18:30:20 +00:00
|
|
|
bool sysfb_parse_mode(const struct screen_info *si,
|
|
|
|
struct simplefb_platform_data *mode);
|
2022-11-14 13:29:54 +00:00
|
|
|
struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
|
2024-11-07 10:45:14 +00:00
|
|
|
const struct simplefb_platform_data *mode,
|
|
|
|
struct device *parent);
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
|
drivers/firmware: consolidate EFI framebuffer setup for all arches
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071830
Depends: https://bugzilla.redhat.com/show_bug.cgi?id=2071840
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. At this stage, this
has been tested by ensuring we can survive the CI/CD loop -- i.e.,
that we have not broken anything else, and a simple boot test. When
sufficient drivers have been brought in for i.MX8M, we will be able
to run further tests.
commit 8633ef82f101c040427b57d4df7b706261420b94
Author: Javier Martinez Canillas <javierm@redhat.com>
Date: Fri Jun 25 15:13:59 2021 +0200
drivers/firmware: consolidate EFI framebuffer setup for all arches
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 <javierm@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com
(cherry picked from commit 8633ef82f101c040427b57d4df7b706261420b94)
Conflicts:
drivers/gpu/drm/tiny/Kconfig:
495a018a8f19c6e953a1b39ad3859d97e2af92d1 (Merge DRM changes from upstream
v5.14..v5.15) included what should have been applied with this patch so it
was no longer needed
Signed-off-by: Al Stone <ahs3@redhat.com>
2022-07-09 18:30:20 +00:00
|
|
|
#else /* CONFIG_SYSFB_SIMPLE */
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
|
drivers/firmware: consolidate EFI framebuffer setup for all arches
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071830
Depends: https://bugzilla.redhat.com/show_bug.cgi?id=2071840
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. At this stage, this
has been tested by ensuring we can survive the CI/CD loop -- i.e.,
that we have not broken anything else, and a simple boot test. When
sufficient drivers have been brought in for i.MX8M, we will be able
to run further tests.
commit 8633ef82f101c040427b57d4df7b706261420b94
Author: Javier Martinez Canillas <javierm@redhat.com>
Date: Fri Jun 25 15:13:59 2021 +0200
drivers/firmware: consolidate EFI framebuffer setup for all arches
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 <javierm@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com
(cherry picked from commit 8633ef82f101c040427b57d4df7b706261420b94)
Conflicts:
drivers/gpu/drm/tiny/Kconfig:
495a018a8f19c6e953a1b39ad3859d97e2af92d1 (Merge DRM changes from upstream
v5.14..v5.15) included what should have been applied with this patch so it
was no longer needed
Signed-off-by: Al Stone <ahs3@redhat.com>
2022-07-09 18:30:20 +00:00
|
|
|
static inline bool sysfb_parse_mode(const struct screen_info *si,
|
|
|
|
struct simplefb_platform_data *mode)
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-11-14 13:29:54 +00:00
|
|
|
static inline struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
|
2024-11-07 10:45:14 +00:00
|
|
|
const struct simplefb_platform_data *mode,
|
|
|
|
struct device *parent)
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
{
|
2022-11-14 13:29:54 +00:00
|
|
|
return ERR_PTR(-EINVAL);
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
}
|
|
|
|
|
drivers/firmware: consolidate EFI framebuffer setup for all arches
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071830
Depends: https://bugzilla.redhat.com/show_bug.cgi?id=2071840
Tested: This is one of a series of patch sets to enable Arm SystemReady IR
support in the kernel for NXP i.MX8 platforms. At this stage, this
has been tested by ensuring we can survive the CI/CD loop -- i.e.,
that we have not broken anything else, and a simple boot test. When
sufficient drivers have been brought in for i.MX8M, we will be able
to run further tests.
commit 8633ef82f101c040427b57d4df7b706261420b94
Author: Javier Martinez Canillas <javierm@redhat.com>
Date: Fri Jun 25 15:13:59 2021 +0200
drivers/firmware: consolidate EFI framebuffer setup for all arches
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 <javierm@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com
(cherry picked from commit 8633ef82f101c040427b57d4df7b706261420b94)
Conflicts:
drivers/gpu/drm/tiny/Kconfig:
495a018a8f19c6e953a1b39ad3859d97e2af92d1 (Merge DRM changes from upstream
v5.14..v5.15) included what should have been applied with this patch so it
was no longer needed
Signed-off-by: Al Stone <ahs3@redhat.com>
2022-07-09 18:30:20 +00:00
|
|
|
#endif /* CONFIG_SYSFB_SIMPLE */
|
x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
x86 causes troubles when loading multiple fbdev drivers. The global
"struct screen_info" does not provide any state-tracking about which
drivers use the FBs. request_mem_region() theoretically works, but
unfortunately vesafb/efifb ignore it due to quirks for broken boards.
Avoid this by creating a platform framebuffer devices with a pointer
to the "struct screen_info" as platform-data. Drivers can now create
platform-drivers and the driver-core will refuse multiple drivers being
active simultaneously.
We keep the screen_info available for backwards-compatibility. Drivers
can be converted in follow-up patches.
Different devices are created for VGA/VESA/EFI FBs to allow multiple
drivers to be loaded on distro kernels. We create:
- "vesa-framebuffer" for VBE/VESA graphics FBs
- "efi-framebuffer" for EFI FBs
- "platform-framebuffer" for everything else
This allows to load vesafb, efifb and others simultaneously and each
picks up only the supported FB types.
Apart from platform-framebuffer devices, this also introduces a
compatibility option for "simple-framebuffer" drivers which recently got
introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
try to match the screen_info against a simple-framebuffer supported
format. If we succeed, we create a "simple-framebuffer" device instead
of a platform-framebuffer.
This allows to reuse the simplefb.c driver across architectures and also
to introduce a SimpleDRM driver. There is no need to have vesafb.c,
efifb.c, simplefb.c and more just to have architecture specific quirks
in their setup-routines.
Instead, we now move the architecture specific quirks into x86-setup and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.com
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 12:05:22 +00:00
|
|
|
|
2022-07-09 18:30:19 +00:00
|
|
|
#endif /* _LINUX_SYSFB_H */
|