archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <>
To: Ard Biesheuvel <>
	Daniel Vetter <>,
	Peter Robinson <>,
	Thomas Zimmermann <>,
	David Airlie <>,
	Hans de Goede <>,
	Albert Ou <>, Borislav Petkov <>,
	Catalin Marinas <>,
	"H. Peter Anvin" <>, Ingo Molnar <>,
	Palmer Dabbelt <>,
	Paul Walmsley <>,
	Russell King <>,
	Thomas Gleixner <>,
	Will Deacon <>,,,,
Subject: Re: [PATCH 0/2] allow the sysfb support to be used in non-x86 arches
Date: Mon, 24 May 2021 12:52:50 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hello Ard,

On 5/24/21 12:24 PM, Ard Biesheuvel wrote:


>> 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

      reply	other threads:[~2021-05-24 21:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 19:29 [PATCH 0/2] allow the sysfb support to be used in non-x86 arches Javier Martinez Canillas
2021-05-24 10:24 ` Ard Biesheuvel
2021-05-24 10:52   ` Javier Martinez Canillas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).