[RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs

Tue Jun 30 09:06:37 UTC 2020

On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede at redhat.com> wrote:
>
> Hi,
>
> On 6/25/20 2:00 PM, Thomas Zimmermann wrote:
> > This patchset adds support for simple-framebuffer platform devices and
> > a handover mechanism for native drivers to take-over control of the
> > hardware.
> >
> > The new driver, called simplekms, binds to a simple-frambuffer platform
> > device. The kernel's boot code creates such devices for firmware-provided
> > framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot
> > loader sets up the framebuffers. Description via device tree is also an
> > option.
> >
> > Simplekms is small enough to be linked into the kernel. The driver's main
> > purpose is to provide graphical output during the early phases of the boot
> > process, before the native DRM drivers are available. Native drivers are
> > typically loaded from an initrd ram disk. Occationally simplekms can also
> > serve as interim solution on graphics hardware without native DRM driver.
>
> Cool, thank you for doing this, this is a very welcome change,
> but ... (see below).
>
> > So far distributions rely on fbdev drivers, such as efifb, vesafb or
> > simplefb, for early-boot graphical output. However fbdev is deprecated and
> > the drivers do not provide DRM interfaces for modern userspace.
> >
> > Patches 1 and 2 prepare the DRM format helpers for simplekms.
> >
> > Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers
> > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During
> > pageflips, SHMEM buffers are copied into the framebuffer memory, similar
> > to cirrus or mgag200. The code in patches 6 and 7 handles clocks and
> > regulators. It's based on the simplefb drivers, but has been modified for
> > DRM.
> >
> > Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's
> > framebuffer's I/O-memory range and provides a callback function to be
> > removed by a native driver. The native driver will remove simplekms before
> > taking over the hardware. The removal is integrated into existing helpers,
> > so drivers use it automatically.
> >
> > I tested simplekms with x86 EFI and VESA framebuffers, which both work
> > reliably. The fbdev console and Weston work automatically. Xorg requires
> > manual configuration of the device. Xorgs current modesetting driver does
> > not work with both, platform and PCI device, for the same physical
> > hardware. Once configured, X11 works.
>
> Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go
> around and break userspace. OTOH this does seem like an userspace issue
> and not something which we can (or should try to) fix in the kernel.
>
> I guess the solution will have to be to have this default to N for now
> in Kconfig and clearly mention in the Kconfig help text that this needs
> a fixed Xorg modesetting driver before it can be enabled.
>
> Any chance you have time to work on fixing the Xorg modesetting driver
> so that this will just work with the standard Xorg autoconfiguration
> stuff?

Hm, why do we even have both platform and pci drivers visible at the
same time? I thought the point of this is that simplekms is built-in,
then initrd loads the real drm driver, and by the time Xorg is
running, simplekms should be long gone.

Maybe a few more details of what's going wrong and why to help unconfuse me?

> > One cosmetical issue is that simplekms's device file is card0 and the
> > native driver's device file is card1. After simplekms has been kicked out,
> > only card1 is left. This does not seem to be a practical problem however.
> >
> > TODO/IDEAS:
> >
> >       * provide deferred takeover
>
> I assume you mean akin to CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER ?
> I don't think you need to do anything for that, as long as you just
> leave the fb contents intact until requested to change it.

Yeah I think fastboot support is a requirement here, otherwise all the
deferred fb takeover should already happen automatically I think.

Also fastboot = flickerfree, depending whether you care more about
"fewer modesets to save time" or "less flickering because it's ugly"
:-)

Cheers, Daniel

> Right now with flickerfree boot we have fbcon on top of efifb and
> efifb does not do anything special wrt
> CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> ATM it does draw/restore the ACPI BGRT logo since since some firmwares
> don't draw that themselves, but that is not necessary in most cases
> and other then that all the deferred takeover magic is in the fbcon
> code, it does not bind to the fbdev (and thus does not draw to it)
> until the first time the kernel tries to output text to the console,
> together with the "quiet" kernel commandline argument that ensures
> that the fb is kept unmodified until e.g. a panic happens.
>
> With simplekms we would replace "fbcon on top of efifb" with
> "fbcon on top of emulated-fbdev on top of simplekms" so as long
> as the emulated-fbdev and simplekms code defer from say clearing
> the screen to black, but keep it as is. Then the fb contents
> should be preserved until fbcon decides to takeover the fbdev
> and draw to it.
>
> >       * provide bootsplash DRM client
>
> Hmm, I guess this might be interesting for simple cases, but
> although I would love to kill plymouth (I've become one of the
> upstream maintainers for it) I'm afraid it is not that easy,
> it does a bunch of stuff which will be tricky to do in the kernel:
>
> 1) Ask the user for diskcrypt passwords:
> https://ic.pics.livejournal.com/hansdegoede/13347631/1496/1496_900.png
>
> 2) Show a nice splash + progressbar when installing updates in
> offline updates mode:
> https://ic.pics.livejournal.com/hansdegoede/13347631/899/899_900.png
>
> Still this would be nice for the non diskcrypt case I guess, then
> we could not use plymouth during normal boot and only use it
> for offline updates and it would also be nice for various embedded
> cases.
>
> Regards,
>
> Hans
>
>
>
>
>
> >       * make simplekms usable with ARM-EFI fbs
> >
> > Thomas Zimmermann (9):
> >    drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()
> >    drm/format-helper: Add blitter functions
> >    drm: Add simplekms driver
> >    drm/simplekms: Add fbdev emulation
> >    drm/simplekms: Initialize framebuffer data from device-tree node
> >    drm/simplekms: Acquire clocks from DT device node
> >    drm/simplekms: Acquire regulators from DT device node
> >    drm: Add infrastructure for platform devices
> >    drm/simplekms: Acquire memory aperture for framebuffer
> >
> >   MAINTAINERS                            |   6 +
> >   drivers/gpu/drm/Kconfig                |   6 +
> >   drivers/gpu/drm/Makefile               |   1 +
> >   drivers/gpu/drm/drm_format_helper.c    |  96 ++-
> >   drivers/gpu/drm/drm_platform.c         | 118 ++++
> >   drivers/gpu/drm/mgag200/mgag200_mode.c |   2 +-
> >   drivers/gpu/drm/tiny/Kconfig           |  17 +
> >   drivers/gpu/drm/tiny/Makefile          |   1 +
> >   drivers/gpu/drm/tiny/cirrus.c          |   2 +-
> >   drivers/gpu/drm/tiny/simplekms.c       | 906 +++++++++++++++++++++++++
> >   include/drm/drm_fb_helper.h            |  18 +-
> >   include/drm/drm_format_helper.h        |  10 +-
> >   include/drm/drm_platform.h             |  42 ++
> >   13 files changed, 1217 insertions(+), 8 deletions(-)
> >   create mode 100644 drivers/gpu/drm/drm_platform.c
> >   create mode 100644 drivers/gpu/drm/tiny/simplekms.c
> >   create mode 100644 include/drm/drm_platform.h
> >
> > --
> > 2.27.0
> >
>

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch