Re: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem

From: Thomas Zimmermann
Date: Thu Jul 28 2022 - 14:13:24 EST


Hi

Am 28.07.22 um 17:16 schrieb Arnd Bergmann:
On Thu, Jul 28, 2022 at 4:57 PM Markuss Broks <markuss.broks@xxxxxxxxx> wrote:
On 7/28/22 17:48, Arnd Bergmann wrote:
On Thu, Jul 28, 2022 at 4:28 PM Markuss Broks <markuss.broks@xxxxxxxxx> wrote:

Add early console support for generic linear framebuffer devices.
This driver supports probing from cmdline early parameters
or from the device-tree using information in simple-framebuffer node.
The EFI functionality should be retained in whole.
The driver was disabled on ARM because of a bug in early_ioremap
implementation on ARM.

Signed-off-by: Markuss Broks <markuss.broks@xxxxxxxxx>
---
.../admin-guide/kernel-parameters.txt | 12 +-
MAINTAINERS | 5 +
drivers/firmware/efi/Kconfig | 6 +-
drivers/firmware/efi/Makefile | 1 -
drivers/firmware/efi/earlycon.c | 246 --------------
drivers/video/fbdev/Kconfig | 11 +
drivers/video/fbdev/Makefile | 1 +
drivers/video/fbdev/earlycon.c | 301 ++++++++++++++++++

It looks like this is not actually related to fbdev, and since drivers are
moving from fbdev/simplefb towards drm/simpledrm, maybe it would be
better to put this into either drivers/gpu/drm/tiny/ or possibly
drivers/video/console to let this be used without enabling fbdev?

Ideally this shouldn't depend on anything, because it isn't utilizing
any of fbdev code and won't be utilizing any of drm/console code. I
agree that either of those would be a better place for it, but which one
do you think would suit more for this driver?

I think ideally this would be integrated with simpledrm in the long run,
but I have no idea what that means in terms of future code changes.

Maybe Thomas Zimmermann has an idea here.

It's not a graphics driver, so it doesn't belong to fbdev or DRM. I'd put the code under drivers/video/console.

Direct integration with simpledrm (or any other firmware graphics driver) is probably not an option. Those drivers operate on platform devices, which aren't available when earlycon runs.

There's no management of framebuffer ownership AFAICT? For fbdev and DRM, we manage the ownership of the framebuffer memory. When a driver takes over the framebuffer, it first has to remove any driver previously owning that memory. That apparently hasn't been a need for early consoles so far (?) Maybe we should integrate them into the ownership management (see drivers/video/aperture.c).

Best regards
Thomas


Arnd

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Attachment: OpenPGP_signature
Description: OpenPGP digital signature