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
