[PATCH 0/2] allow the sysfb support to be used in non-x86 arches

[PATCH 0/2] allow the sysfb support to be used in non-x86 arches

[Javier Martinez Canillas]

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.

Best regards,
Javier


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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] allow the sysfb support to be used in non-x86 arches

[Ard Biesheuvel]

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
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] allow the sysfb support to be used in non-x86 arches

[Javier Martinez Canillas]

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,
-- 
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel