Message ID | 20210521192907.3040644-1-javierm@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | allow the sysfb support to be used in non-x86 arches | expand |
Hello Javier, On Fri, 21 May 2021 at 21:29, Javier Martinez Canillas <javierm@redhat.com> wrote: > > The x86 architecture platform has a Generic System Framebuffers (sysfb) > support, that register a system frambuffer platform devices. It either > registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > VGA/EFI FB devices for the vgafb/efifb drivers. > > Besides this, the EFI initialization code used by other architectures such > as aarch64 and riscv, has similar logic but only register an EFI FB device. > > 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 the latter. This 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. > > Since this touches both arch/{x86,arm,arm64,riscv} and drivers/firmware, I > don't know how it should be merged. But I didn't find a way to split these. > We could merge this via the EFI tree without too much risk of conflicts, I think. However, I'd like to see a better explanation of why this is an improvement. The diffstat does not show a huge net win, and it does not enable anything we didn't already have before, right? > > Javier Martinez Canillas (2): > drivers/firmware: move x86 Generic System Framebuffers support > drivers/firmware: consolidate EFI framebuffer setup for all arches > > arch/arm/Kconfig | 1 + > arch/arm/include/asm/efi.h | 5 +- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/efi.h | 5 +- > arch/riscv/Kconfig | 1 + > arch/riscv/include/asm/efi.h | 5 +- > arch/x86/Kconfig | 27 +----- > arch/x86/kernel/Makefile | 3 - > drivers/firmware/Kconfig | 30 +++++++ > drivers/firmware/Makefile | 2 + > drivers/firmware/efi/Makefile | 2 + > drivers/firmware/efi/efi-init.c | 90 ------------------- > .../firmware/efi}/sysfb_efi.c | 79 +++++++++++++++- > {arch/x86/kernel => drivers/firmware}/sysfb.c | 42 +++++---- > .../firmware}/sysfb_simplefb.c | 31 ++++--- > .../x86/include/asm => include/linux}/sysfb.h | 34 +++---- > 16 files changed, 182 insertions(+), 176 deletions(-) > rename {arch/x86/kernel => drivers/firmware/efi}/sysfb_efi.c (84%) > rename {arch/x86/kernel => drivers/firmware}/sysfb.c (70%) > rename {arch/x86/kernel => drivers/firmware}/sysfb_simplefb.c (82%) > rename {arch/x86/include/asm => include/linux}/sysfb.h (68%) > > -- > 2.31.1 >
Hello Ard, On 5/24/21 12:24 PM, Ard Biesheuvel wrote: [snip] >> Since this touches both arch/{x86,arm,arm64,riscv} and drivers/firmware, I >> don't know how it should be merged. But I didn't find a way to split these. >> > > We could merge this via the EFI tree without too much risk of > conflicts, I think. > Great, thanks. > However, I'd like to see a better explanation of why this is an improvement. > The diffstat does not show a huge net win, and it does not enable > anything we didn't already have before, right? > > I mentioned a little in the cover letter but you are correct that wasn't that clear. My motivation was to use the simpledrm driver instead of efifb for the early console, so I could boot without using fbdev at all. The register_gop_device() in drivers/firmware/efi/efi-init.c only register an "efi-frambuffer" platform device, which means that it will only allow to use the efifb driver for the early framebuffer on EFI systems. The "simple-framebuffer" platform device is only registered by OF if there's a DT node with this compatible string, but it won't be registered for EFI. So the simplefb or newly added simpledrm driver won't be matched and probed with the current EFI support in aarch64 or riscv. In contrast, the x86 code does register a "simple-framebuffer" device that uses the GOP framebuffer. One option is to add the same logic in register_gop_device(), but that would require even more code duplication. Another option would be to make the simple drivers to match against "efi-framebuffer", but that would be an ugly solution. But even without taking the lack of "simple-framebuffer" into account, I wonder what would be the benefit of keeping two code paths that do basically the same. Best regards,