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