* [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms
@ 2021-06-25 13:09 Javier Martinez Canillas
2021-06-25 13:09 ` [PATCH v3 1/2] drivers/firmware: move x86 Generic System Framebuffers support Javier Martinez Canillas
2021-07-13 16:59 ` [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms Javier Martinez Canillas
0 siblings, 2 replies; 14+ messages in thread
From: Javier Martinez Canillas @ 2021-06-25 13:09 UTC (permalink / raw)
To: linux-kernel
Cc: Thomas Zimmermann, Palmer Dabbelt, Russell King, linux-efi,
Thomas Gleixner, Hans de Goede, x86, Ingo Molnar, Will Deacon,
Paul Walmsley, linux-riscv, Borislav Petkov, Albert Ou,
Peter Robinson, dri-devel, linux-arm-kernel, David Airlie,
Greg Kroah-Hartman, Daniel Vetter, Ard Biesheuvel,
Catalin Marinas, Atish Patra, Javier Martinez Canillas
The simplefb and simpledrm drivers match against a "simple-framebuffer"
device, but for aarch64 this is only registered when using Device Trees
and there's a node with a "simple-framebuffer" compatible string.
There is no code to register a "simple-framebuffer" platform device when
using EFI instead. In fact, the only platform device that's registered in
this case is an "efi-framebuffer", which means that the efifb driver is
the only driver supported to have an early console with EFI on aarch64.
The x86 architecture platform has a Generic System Framebuffers (sysfb)
support, that register a system frambuffer platform device. It either
registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy
VGA/EFI FB devices for the vgafb/efifb drivers.
The sysfb is generic enough to be reused by other architectures and can be
moved out of the arch/x86 directory to drivers/firmware, allowing the EFI
logic used by non-x86 architectures to be folded into sysfb as well.
Patch #1 in this series do the former while patch #2 do the latter. It has
been tested on x86_64 and aarch64 machines using the efifb, simplefb and
simpledrm drivers. But more testing will be highly appreciated, to make
sure that no regressions are being introduced by these changes.
The series touches different subystems and will need coordination between
maintainers but the patches have already been acked by the x86 folks. Ard
Biesheuvel said that these could be merged through the EFI tree if needed.
Best regards,
Javier
Changes in v3:
- Add Borislav and Greg Acked-by tags.
- Also update the SYSFB_SIMPLEFB symbol name in drivers/gpu/drm/tiny/Kconfig.
- We have a a max 100 char limit now, use it to avoid multi-line statements.
- Figure out the platform device name before allocating the platform device.
Changes in v2:
- Use default y and depends on X86 instead doing a select in arch/x86/Kconfig.
- Also enable the SYSFB Kconfig option when COMPILE_TEST.
- Improve commit message to explain why is useful for other arches to use this.
- Use "depends on" for the supported architectures instead of selecting it.
- Improve commit message to explain the benefits of reusing sysfb for !X86.
Javier Martinez Canillas (2):
drivers/firmware: move x86 Generic System Framebuffers support
drivers/firmware: consolidate EFI framebuffer setup for all arches
arch/arm/include/asm/efi.h | 5 +-
arch/arm64/include/asm/efi.h | 5 +-
arch/riscv/include/asm/efi.h | 5 +-
arch/x86/Kconfig | 26 ------
arch/x86/kernel/Makefile | 3 -
drivers/firmware/Kconfig | 32 +++++++
drivers/firmware/Makefile | 2 +
drivers/firmware/efi/Makefile | 2 +
drivers/firmware/efi/efi-init.c | 90 -------------------
.../firmware/efi}/sysfb_efi.c | 78 +++++++++++++++-
{arch/x86/kernel => drivers/firmware}/sysfb.c | 37 +++++---
.../firmware}/sysfb_simplefb.c | 33 ++++---
drivers/gpu/drm/tiny/Kconfig | 4 +-
.../x86/include/asm => include/linux}/sysfb.h | 32 +++----
14 files changed, 180 insertions(+), 174 deletions(-)
rename {arch/x86/kernel => drivers/firmware/efi}/sysfb_efi.c (84%)
rename {arch/x86/kernel => drivers/firmware}/sysfb.c (75%)
rename {arch/x86/kernel => drivers/firmware}/sysfb_simplefb.c (81%)
rename {arch/x86/include/asm => include/linux}/sysfb.h (70%)
--
2.31.1
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH v3 1/2] drivers/firmware: move x86 Generic System Framebuffers support 2021-06-25 13:09 [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms Javier Martinez Canillas @ 2021-06-25 13:09 ` Javier Martinez Canillas 2021-07-13 16:59 ` [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms Javier Martinez Canillas 1 sibling, 0 replies; 14+ messages in thread From: Javier Martinez Canillas @ 2021-06-25 13:09 UTC (permalink / raw) To: linux-kernel Cc: Thomas Zimmermann, Palmer Dabbelt, Russell King, linux-efi, Thomas Gleixner, Hans de Goede, x86, Ingo Molnar, Will Deacon, Paul Walmsley, linux-riscv, Borislav Petkov, Albert Ou, Peter Robinson, dri-devel, linux-arm-kernel, David Airlie, Greg Kroah-Hartman, Daniel Vetter, Ard Biesheuvel, Catalin Marinas, Atish Patra, Javier Martinez Canillas 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 <javierm@redhat.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Changes in v3: - Add Borislav and Greg Acked-by tags. Changes in v2: - Use default y and depends on X86 instead doing a select in arch/x86/Kconfig. - Also enable the SYSFB Kconfig option when COMPILE_TEST. - Improve commit message to explain why is useful for other arches to use this. arch/x86/Kconfig | 26 --------------- arch/x86/kernel/Makefile | 3 -- drivers/firmware/Kconfig | 32 +++++++++++++++++++ drivers/firmware/Makefile | 2 ++ drivers/firmware/efi/Makefile | 2 ++ .../firmware/efi}/sysfb_efi.c | 2 +- {arch/x86/kernel => drivers/firmware}/sysfb.c | 2 +- .../firmware}/sysfb_simplefb.c | 2 +- .../x86/include/asm => include/linux}/sysfb.h | 6 ++-- 9 files changed, 42 insertions(+), 35 deletions(-) rename {arch/x86/kernel => drivers/firmware/efi}/sysfb_efi.c (99%) rename {arch/x86/kernel => drivers/firmware}/sysfb.c (98%) rename {arch/x86/kernel => drivers/firmware}/sysfb_simplefb.c (99%) rename {arch/x86/include/asm => include/linux}/sysfb.h (95%) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 0ae3eccfec52..f169a30db768 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2766,32 +2766,6 @@ config AMD_NB def_bool y depends on CPU_SUP_AMD && PCI -config X86_SYSFB - bool "Mark VGA/VBE/EFI FB as generic system framebuffer" - help - Firmwares often provide initial graphics framebuffers so the BIOS, - bootloader or kernel can show basic video-output during boot for - user-guidance and debugging. Historically, x86 used the VESA BIOS - Extensions and EFI-framebuffers for this, which are mostly limited - to x86. - This option, if enabled, marks VGA/VBE/EFI framebuffers as generic - framebuffers so the new generic system-framebuffer drivers can be - used on x86. If the framebuffer is not compatible with the generic - modes, it is advertised as fallback platform framebuffer so legacy - drivers like efifb, vesafb and uvesafb can pick it up. - If this option is not selected, all system framebuffers are always - marked as fallback platform framebuffers as usual. - - Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will - not be able to pick up generic system framebuffers if this option - is selected. You are highly encouraged to enable simplefb as - replacement if you select this option. simplefb can correctly deal - with generic system framebuffers. But you should still keep vesafb - and others enabled as fallback if a system framebuffer is - incompatible with simplefb. - - If unsure, say Y. - endmenu diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 0f66682ac02a..4114ea47def2 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -135,9 +135,6 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o obj-$(CONFIG_SWIOTLB) += pci-swiotlb.o obj-$(CONFIG_OF) += devicetree.o obj-$(CONFIG_UPROBES) += uprobes.o -obj-y += sysfb.o -obj-$(CONFIG_X86_SYSFB) += sysfb_simplefb.o -obj-$(CONFIG_EFI) += sysfb_efi.o obj-$(CONFIG_PERF_EVENTS) += perf_regs.o obj-$(CONFIG_TRACING) += tracepoint.o diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 1db738d5b301..5991071e9d7f 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -251,6 +251,38 @@ config QCOM_SCM_DOWNLOAD_MODE_DEFAULT Say Y here to enable "download mode" by default. +config SYSFB + bool + default y + depends on X86 || COMPILE_TEST + +config X86_SYSFB + bool "Mark VGA/VBE/EFI FB as generic system framebuffer" + depends on SYSFB + help + Firmwares often provide initial graphics framebuffers so the BIOS, + bootloader or kernel can show basic video-output during boot for + user-guidance and debugging. Historically, x86 used the VESA BIOS + Extensions and EFI-framebuffers for this, which are mostly limited + to x86. + This option, if enabled, marks VGA/VBE/EFI framebuffers as generic + framebuffers so the new generic system-framebuffer drivers can be + used on x86. If the framebuffer is not compatible with the generic + modes, it is advertised as fallback platform framebuffer so legacy + drivers like efifb, vesafb and uvesafb can pick it up. + If this option is not selected, all system framebuffers are always + marked as fallback platform framebuffers as usual. + + Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will + not be able to pick up generic system framebuffers if this option + is selected. You are highly encouraged to enable simplefb as + replacement if you select this option. simplefb can correctly deal + with generic system framebuffers. But you should still keep vesafb + and others enabled as fallback if a system framebuffer is + incompatible with simplefb. + + If unsure, say Y. + config TI_SCI_PROTOCOL tristate "TI System Control Interface (TISCI) Message Protocol" depends on TI_MESSAGE_MANAGER diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index 546ac8e7f6d0..946dda07443d 100644 --- a/drivers/firmware/Makefile +++ b/drivers/firmware/Makefile @@ -18,6 +18,8 @@ obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o obj-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o +obj-$(CONFIG_SYSFB) += sysfb.o +obj-$(CONFIG_X86_SYSFB) += sysfb_simplefb.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 diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile index 467e94259679..c02ff25dd477 100644 --- a/drivers/firmware/efi/Makefile +++ b/drivers/firmware/efi/Makefile @@ -36,6 +36,8 @@ obj-$(CONFIG_LOAD_UEFI_KEYS) += mokvar-table.o fake_map-y += fake_mem.o fake_map-$(CONFIG_X86) += x86_fake_mem.o +obj-$(CONFIG_SYSFB) += sysfb_efi.o + arm-obj-$(CONFIG_EFI) := efi-init.o arm-runtime.o obj-$(CONFIG_ARM) += $(arm-obj-y) obj-$(CONFIG_ARM64) += $(arm-obj-y) diff --git a/arch/x86/kernel/sysfb_efi.c b/drivers/firmware/efi/sysfb_efi.c similarity index 99% rename from arch/x86/kernel/sysfb_efi.c rename to drivers/firmware/efi/sysfb_efi.c index 8a56a6d80098..9f035b15501c 100644 --- a/arch/x86/kernel/sysfb_efi.c +++ b/drivers/firmware/efi/sysfb_efi.c @@ -21,10 +21,10 @@ #include <linux/mm.h> #include <linux/pci.h> #include <linux/screen_info.h> +#include <linux/sysfb.h> #include <video/vga.h> #include <asm/efi.h> -#include <asm/sysfb.h> enum { OVERRIDE_NONE = 0x0, diff --git a/arch/x86/kernel/sysfb.c b/drivers/firmware/sysfb.c similarity index 98% rename from arch/x86/kernel/sysfb.c rename to drivers/firmware/sysfb.c index 014ebd8ca869..1337515963d5 100644 --- a/arch/x86/kernel/sysfb.c +++ b/drivers/firmware/sysfb.c @@ -32,7 +32,7 @@ #include <linux/platform_data/simplefb.h> #include <linux/platform_device.h> #include <linux/screen_info.h> -#include <asm/sysfb.h> +#include <linux/sysfb.h> static __init int sysfb_init(void) { diff --git a/arch/x86/kernel/sysfb_simplefb.c b/drivers/firmware/sysfb_simplefb.c similarity index 99% rename from arch/x86/kernel/sysfb_simplefb.c rename to drivers/firmware/sysfb_simplefb.c index 298fc1edd9c9..df892444ea17 100644 --- a/arch/x86/kernel/sysfb_simplefb.c +++ b/drivers/firmware/sysfb_simplefb.c @@ -18,7 +18,7 @@ #include <linux/platform_data/simplefb.h> #include <linux/platform_device.h> #include <linux/screen_info.h> -#include <asm/sysfb.h> +#include <linux/sysfb.h> static const char simplefb_resname[] = "BOOTFB"; static const struct simplefb_format formats[] = SIMPLEFB_FORMATS; diff --git a/arch/x86/include/asm/sysfb.h b/include/linux/sysfb.h similarity index 95% rename from arch/x86/include/asm/sysfb.h rename to include/linux/sysfb.h index 9834eef7f034..3e5355769dc3 100644 --- a/arch/x86/include/asm/sysfb.h +++ b/include/linux/sysfb.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-or-later */ -#ifndef _ARCH_X86_KERNEL_SYSFB_H -#define _ARCH_X86_KERNEL_SYSFB_H +#ifndef _LINUX_SYSFB_H +#define _LINUX_SYSFB_H /* * Generic System Framebuffers on x86 @@ -91,4 +91,4 @@ static inline int create_simplefb(const struct screen_info *si, #endif /* CONFIG_X86_SYSFB */ -#endif /* _ARCH_X86_KERNEL_SYSFB_H */ +#endif /* _LINUX_SYSFB_H */ -- 2.31.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms 2021-06-25 13:09 [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms Javier Martinez Canillas 2021-06-25 13:09 ` [PATCH v3 1/2] drivers/firmware: move x86 Generic System Framebuffers support Javier Martinez Canillas @ 2021-07-13 16:59 ` Javier Martinez Canillas 2021-07-15 8:11 ` [PATCH v3 0/2] allow simple{fb, drm} " Thomas Zimmermann 1 sibling, 1 reply; 14+ messages in thread From: Javier Martinez Canillas @ 2021-07-13 16:59 UTC (permalink / raw) To: linux-kernel Cc: Thomas Zimmermann, Palmer Dabbelt, Russell King, linux-efi, Thomas Gleixner, Hans de Goede, x86, Ingo Molnar, Will Deacon, Paul Walmsley, linux-riscv, Borislav Petkov, Albert Ou, Peter Robinson, dri-devel, linux-arm-kernel, David Airlie, Greg Kroah-Hartman, Daniel Vetter, Ard Biesheuvel, Catalin Marinas, Atish Patra On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > The simplefb and simpledrm drivers match against a "simple-framebuffer" > device, but for aarch64 this is only registered when using Device Trees > and there's a node with a "simple-framebuffer" compatible string. > > There is no code to register a "simple-framebuffer" platform device when > using EFI instead. In fact, the only platform device that's registered in > this case is an "efi-framebuffer", which means that the efifb driver is > the only driver supported to have an early console with EFI on aarch64. > > The x86 architecture platform has a Generic System Framebuffers (sysfb) > support, that register a system frambuffer platform device. It either > registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > VGA/EFI FB devices for the vgafb/efifb drivers. > > The sysfb is generic enough to be reused by other architectures and can be > moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > logic used by non-x86 architectures to be folded into sysfb as well. > Any more comments on this series? It would be nice for this to land so the simpledrm driver could be used on aarch64 EFI systems as well. The patches have already been acked by x86 and DRM folks. Best regards, -- Javier Martinez Canillas Linux Engineering ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-13 16:59 ` [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms Javier Martinez Canillas @ 2021-07-15 8:11 ` Thomas Zimmermann 2021-07-19 2:59 ` Dave Airlie 0 siblings, 1 reply; 14+ messages in thread From: Thomas Zimmermann @ 2021-07-15 8:11 UTC (permalink / raw) To: Javier Martinez Canillas, linux-kernel Cc: linux-efi, David Airlie, Catalin Marinas, dri-devel, Atish Patra, linux-riscv, Will Deacon, Ard Biesheuvel, x86, Russell King, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, Palmer Dabbelt [-- Attachment #1.1: Type: text/plain, Size: 1720 bytes --] Hi Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: >> The simplefb and simpledrm drivers match against a "simple-framebuffer" >> device, but for aarch64 this is only registered when using Device Trees >> and there's a node with a "simple-framebuffer" compatible string. >> >> There is no code to register a "simple-framebuffer" platform device when >> using EFI instead. In fact, the only platform device that's registered in >> this case is an "efi-framebuffer", which means that the efifb driver is >> the only driver supported to have an early console with EFI on aarch64. >> >> The x86 architecture platform has a Generic System Framebuffers (sysfb) >> support, that register a system frambuffer platform device. It either >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy >> VGA/EFI FB devices for the vgafb/efifb drivers. >> >> The sysfb is generic enough to be reused by other architectures and can be >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI >> logic used by non-x86 architectures to be folded into sysfb as well. >> > > Any more comments on this series? It would be nice for this to land so the > simpledrm driver could be used on aarch64 EFI systems as well. > > The patches have already been acked by x86 and DRM folks. Time to get this merged, I'd say. People are asking for these patches already. Best regards Thomas > > Best regards, > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-15 8:11 ` [PATCH v3 0/2] allow simple{fb, drm} " Thomas Zimmermann @ 2021-07-19 2:59 ` Dave Airlie 2021-07-19 7:10 ` Ard Biesheuvel 0 siblings, 1 reply; 14+ messages in thread From: Dave Airlie @ 2021-07-19 2:59 UTC (permalink / raw) To: Thomas Zimmermann Cc: Javier Martinez Canillas, LKML, linux-arm-kernel, linux-efi, Hans de Goede, David Airlie, Catalin Marinas, the arch/x86 maintainers, Russell King, dri-devel, Atish Patra, Greg Kroah-Hartman, Ingo Molnar, Thomas Gleixner, Peter Robinson, Paul Walmsley, Palmer Dabbelt, linux-riscv, Borislav Petkov, Will Deacon, Ard Biesheuvel, Albert Ou On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > >> The simplefb and simpledrm drivers match against a "simple-framebuffer" > >> device, but for aarch64 this is only registered when using Device Trees > >> and there's a node with a "simple-framebuffer" compatible string. > >> > >> There is no code to register a "simple-framebuffer" platform device when > >> using EFI instead. In fact, the only platform device that's registered in > >> this case is an "efi-framebuffer", which means that the efifb driver is > >> the only driver supported to have an early console with EFI on aarch64. > >> > >> The x86 architecture platform has a Generic System Framebuffers (sysfb) > >> support, that register a system frambuffer platform device. It either > >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > >> VGA/EFI FB devices for the vgafb/efifb drivers. > >> > >> The sysfb is generic enough to be reused by other architectures and can be > >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > >> logic used by non-x86 architectures to be folded into sysfb as well. > >> > > > > Any more comments on this series? It would be nice for this to land so the > > simpledrm driver could be used on aarch64 EFI systems as well. > > > > The patches have already been acked by x86 and DRM folks. > > Time to get this merged, I'd say. People are asking for these patches > already. Can we just merge via drm-misc and make sure the acks are present and I'll deal with the fallout if any. Dave. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-19 2:59 ` Dave Airlie @ 2021-07-19 7:10 ` Ard Biesheuvel 2021-07-20 13:01 ` Daniel Vetter 0 siblings, 1 reply; 14+ messages in thread From: Ard Biesheuvel @ 2021-07-19 7:10 UTC (permalink / raw) To: Dave Airlie Cc: Thomas Zimmermann, Javier Martinez Canillas, LKML, linux-arm-kernel, linux-efi, Hans de Goede, David Airlie, Catalin Marinas, the arch/x86 maintainers, Russell King, dri-devel, Atish Patra, Greg Kroah-Hartman, Ingo Molnar, Thomas Gleixner, Peter Robinson, Paul Walmsley, Palmer Dabbelt, linux-riscv, Borislav Petkov, Will Deacon, Albert Ou On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: > > On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi > > > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > > >> The simplefb and simpledrm drivers match against a "simple-framebuffer" > > >> device, but for aarch64 this is only registered when using Device Trees > > >> and there's a node with a "simple-framebuffer" compatible string. > > >> > > >> There is no code to register a "simple-framebuffer" platform device when > > >> using EFI instead. In fact, the only platform device that's registered in > > >> this case is an "efi-framebuffer", which means that the efifb driver is > > >> the only driver supported to have an early console with EFI on aarch64. > > >> > > >> The x86 architecture platform has a Generic System Framebuffers (sysfb) > > >> support, that register a system frambuffer platform device. It either > > >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > > >> VGA/EFI FB devices for the vgafb/efifb drivers. > > >> > > >> The sysfb is generic enough to be reused by other architectures and can be > > >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > > >> logic used by non-x86 architectures to be folded into sysfb as well. > > >> > > > > > > Any more comments on this series? It would be nice for this to land so the > > > simpledrm driver could be used on aarch64 EFI systems as well. > > > > > > The patches have already been acked by x86 and DRM folks. > > > > Time to get this merged, I'd say. People are asking for these patches > > already. > > Can we just merge via drm-misc and make sure the acks are present and > I'll deal with the fallout if any. > Fine with me. Could you stick it on a separate branch so I can double check whether there are any issues wrt the EFI tree? Thanks, Ard. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-19 7:10 ` Ard Biesheuvel @ 2021-07-20 13:01 ` Daniel Vetter 2021-07-20 13:42 ` Javier Martinez Canillas 0 siblings, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2021-07-20 13:01 UTC (permalink / raw) To: Ard Biesheuvel Cc: Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Javier Martinez Canillas, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt, Thomas Zimmermann On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: > On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: > > > > On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > > > Hi > > > > > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > > > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > > > >> The simplefb and simpledrm drivers match against a "simple-framebuffer" > > > >> device, but for aarch64 this is only registered when using Device Trees > > > >> and there's a node with a "simple-framebuffer" compatible string. > > > >> > > > >> There is no code to register a "simple-framebuffer" platform device when > > > >> using EFI instead. In fact, the only platform device that's registered in > > > >> this case is an "efi-framebuffer", which means that the efifb driver is > > > >> the only driver supported to have an early console with EFI on aarch64. > > > >> > > > >> The x86 architecture platform has a Generic System Framebuffers (sysfb) > > > >> support, that register a system frambuffer platform device. It either > > > >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > > > >> VGA/EFI FB devices for the vgafb/efifb drivers. > > > >> > > > >> The sysfb is generic enough to be reused by other architectures and can be > > > >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > > > >> logic used by non-x86 architectures to be folded into sysfb as well. > > > >> > > > > > > > > Any more comments on this series? It would be nice for this to land so the > > > > simpledrm driver could be used on aarch64 EFI systems as well. > > > > > > > > The patches have already been acked by x86 and DRM folks. > > > > > > Time to get this merged, I'd say. People are asking for these patches > > > already. > > > > Can we just merge via drm-misc and make sure the acks are present and > > I'll deal with the fallout if any. > > > > Fine with me. Could you stick it on a separate branch so I can double > check whether there are any issues wrt the EFI tree? It'll pop up in linux-next for integration testing or you can pick up the patch here for test-merge if you want. And since Dave has given a blanket cheque for handling fallout he'll deal with the need for fixups too if there's any. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-20 13:01 ` Daniel Vetter @ 2021-07-20 13:42 ` Javier Martinez Canillas 2021-07-20 13:59 ` Daniel Vetter 0 siblings, 1 reply; 14+ messages in thread From: Javier Martinez Canillas @ 2021-07-20 13:42 UTC (permalink / raw) To: Ard Biesheuvel, Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt, Thomas Zimmermann On 7/20/21 3:01 PM, Daniel Vetter wrote: > On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: >> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: [snip] >>> >>> Can we just merge via drm-misc and make sure the acks are present and >>> I'll deal with the fallout if any. >>> >> >> Fine with me. Could you stick it on a separate branch so I can double >> check whether there are any issues wrt the EFI tree? > > It'll pop up in linux-next for integration testing or you can pick up the > patch here for test-merge if you want. > Thanks a lot Dave and Daniel! > And since Dave has given a blanket cheque for handling fallout he'll deal > with the need for fixups too if there's any. I also plan to look at any regression that might had been introduced by these. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-20 13:42 ` Javier Martinez Canillas @ 2021-07-20 13:59 ` Daniel Vetter 2021-07-20 18:38 ` Thomas Zimmermann 0 siblings, 1 reply; 14+ messages in thread From: Daniel Vetter @ 2021-07-20 13:59 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Ard Biesheuvel, Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt, Thomas Zimmermann On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote: > On 7/20/21 3:01 PM, Daniel Vetter wrote: > > On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: > >> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: > > [snip] > > >>> > >>> Can we just merge via drm-misc and make sure the acks are present and > >>> I'll deal with the fallout if any. > >>> > >> > >> Fine with me. Could you stick it on a separate branch so I can double > >> check whether there are any issues wrt the EFI tree? > > > > It'll pop up in linux-next for integration testing or you can pick up the > > patch here for test-merge if you want. > > > > Thanks a lot Dave and Daniel! Oh I haven't merged them, I'm assuming Thomas will do that. Just figured I'll throw my ack on top: Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > And since Dave has given a blanket cheque for handling fallout he'll deal > > with the need for fixups too if there's any. > > I also plan to look at any regression that might had been introduced by these. > > Best regards, > -- > Javier Martinez Canillas > Linux Engineering > Red Hat > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-20 13:59 ` Daniel Vetter @ 2021-07-20 18:38 ` Thomas Zimmermann 2021-07-21 5:09 ` Javier Martinez Canillas 0 siblings, 1 reply; 14+ messages in thread From: Thomas Zimmermann @ 2021-07-20 18:38 UTC (permalink / raw) To: Javier Martinez Canillas, Ard Biesheuvel, Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt [-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --] Hi Am 20.07.21 um 15:59 schrieb Daniel Vetter: > On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote: >> On 7/20/21 3:01 PM, Daniel Vetter wrote: >>> On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: >>>> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: >> >> [snip] >> >>>>> >>>>> Can we just merge via drm-misc and make sure the acks are present and >>>>> I'll deal with the fallout if any. >>>>> >>>> >>>> Fine with me. Could you stick it on a separate branch so I can double >>>> check whether there are any issues wrt the EFI tree? >>> >>> It'll pop up in linux-next for integration testing or you can pick up the >>> patch here for test-merge if you want. >>> >> >> Thanks a lot Dave and Daniel! > > Oh I haven't merged them, I'm assuming Thomas will do that. Just figured Can I simply put the patches in to drm-misc-next? There was some talk about a topic branch? Best regards Thomas > I'll throw my ack on top: > > Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> > >>> And since Dave has given a blanket cheque for handling fallout he'll deal >>> with the need for fixups too if there's any. >> >> I also plan to look at any regression that might had been introduced by these. >> >> Best regards, >> -- >> Javier Martinez Canillas >> Linux Engineering >> Red Hat >> > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-20 18:38 ` Thomas Zimmermann @ 2021-07-21 5:09 ` Javier Martinez Canillas 2021-07-21 10:07 ` Thomas Zimmermann 0 siblings, 1 reply; 14+ messages in thread From: Javier Martinez Canillas @ 2021-07-21 5:09 UTC (permalink / raw) To: Thomas Zimmermann, Ard Biesheuvel, Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt Hello Thomas, On 7/20/21 8:38 PM, Thomas Zimmermann wrote: > Am 20.07.21 um 15:59 schrieb Daniel Vetter: >> On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote: >>> On 7/20/21 3:01 PM, Daniel Vetter wrote: >>>> On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: >>>>> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: [snip] >>>>>> Can we just merge via drm-misc and make sure the acks are present and >>>>>> I'll deal with the fallout if any. >>>>>> >>>>> >>>>> Fine with me. Could you stick it on a separate branch so I can double >>>>> check whether there are any issues wrt the EFI tree? >>>> >>>> It'll pop up in linux-next for integration testing or you can pick up the >>>> patch here for test-merge if you want. >>>> This is what Daniel said... >>> >>> Thanks a lot Dave and Daniel! >> >> Oh I haven't merged them, I'm assuming Thomas will do that. Just figured > > Can I simply put the patches in to drm-misc-next? There was some talk > about a topic branch? > ... which AFAIU means that there's no need for a topic branch, since the patches will be present in linux-next. And the EFI folks can use that to check if there are any integration issues or regressions caused by these. > Best regards > Thomas > Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-21 5:09 ` Javier Martinez Canillas @ 2021-07-21 10:07 ` Thomas Zimmermann 2021-07-21 10:15 ` Javier Martinez Canillas 0 siblings, 1 reply; 14+ messages in thread From: Thomas Zimmermann @ 2021-07-21 10:07 UTC (permalink / raw) To: Javier Martinez Canillas, Ard Biesheuvel, Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt [-- Attachment #1.1: Type: text/plain, Size: 727 bytes --] Hi Am 21.07.21 um 07:09 schrieb Javier Martinez Canillas: ... >> >> Can I simply put the patches in to drm-misc-next? There was some talk >> about a topic branch? >> > > ... which AFAIU means that there's no need for a topic branch, since the > patches will be present in linux-next. And the EFI folks can use that to > check if there are any integration issues or regressions caused by these. Merged into drm-misc-next. Best regards Thomas > >> Best regards >> Thomas >> > > Best regards, > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-21 10:07 ` Thomas Zimmermann @ 2021-07-21 10:15 ` Javier Martinez Canillas 2021-07-21 11:23 ` Daniel Vetter 0 siblings, 1 reply; 14+ messages in thread From: Javier Martinez Canillas @ 2021-07-21 10:15 UTC (permalink / raw) To: Thomas Zimmermann, Ard Biesheuvel, Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt On 7/21/21 12:07 PM, Thomas Zimmermann wrote: > Hi > > Am 21.07.21 um 07:09 schrieb Javier Martinez Canillas: > ... >>> >>> Can I simply put the patches in to drm-misc-next? There was some talk >>> about a topic branch? >>> >> >> ... which AFAIU means that there's no need for a topic branch, since the >> patches will be present in linux-next. And the EFI folks can use that to >> check if there are any integration issues or regressions caused by these. > > Merged into drm-misc-next. > Thanks a lot Thomas for all your help! Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms 2021-07-21 10:15 ` Javier Martinez Canillas @ 2021-07-21 11:23 ` Daniel Vetter 0 siblings, 0 replies; 14+ messages in thread From: Daniel Vetter @ 2021-07-21 11:23 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Thomas Zimmermann, Ard Biesheuvel, Dave Airlie, linux-efi, David Airlie, Catalin Marinas, dri-devel, Russell King, Atish Patra, linux-riscv, Will Deacon, the arch/x86 maintainers, Ingo Molnar, Peter Robinson, Borislav Petkov, Albert Ou, Hans de Goede, Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman, LKML, Palmer Dabbelt On Wed, Jul 21, 2021 at 12:15:12PM +0200, Javier Martinez Canillas wrote: > On 7/21/21 12:07 PM, Thomas Zimmermann wrote: > > Hi > > > > Am 21.07.21 um 07:09 schrieb Javier Martinez Canillas: > > ... > >>> > >>> Can I simply put the patches in to drm-misc-next? There was some talk > >>> about a topic branch? > >>> > >> > >> ... which AFAIU means that there's no need for a topic branch, since the > >> patches will be present in linux-next. And the EFI folks can use that to > >> check if there are any integration issues or regressions caused by these. > > > > Merged into drm-misc-next. > > > > Thanks a lot Thomas for all your help! Yeah topic branch makes sense when we have further work that will build on top of a patch sets in at latest _two_ different subsystems, and it doesn't make sense to just merge it all in one place (because too much work, or a refactoring that's too invasive and will cause random conflicts with subsequent work in the same subsystem, or ...). Otherwise just acks and then merge in one place. We shouldn't do bureaucratics like topic branches if there's not an actual need for them. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-07-21 11:39 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-25 13:09 [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms Javier Martinez Canillas
2021-06-25 13:09 ` [PATCH v3 1/2] drivers/firmware: move x86 Generic System Framebuffers support Javier Martinez Canillas
2021-07-13 16:59 ` [PATCH v3 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms Javier Martinez Canillas
2021-07-15 8:11 ` [PATCH v3 0/2] allow simple{fb, drm} " Thomas Zimmermann
2021-07-19 2:59 ` Dave Airlie
2021-07-19 7:10 ` Ard Biesheuvel
2021-07-20 13:01 ` Daniel Vetter
2021-07-20 13:42 ` Javier Martinez Canillas
2021-07-20 13:59 ` Daniel Vetter
2021-07-20 18:38 ` Thomas Zimmermann
2021-07-21 5:09 ` Javier Martinez Canillas
2021-07-21 10:07 ` Thomas Zimmermann
2021-07-21 10:15 ` Javier Martinez Canillas
2021-07-21 11:23 ` Daniel Vetter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).