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?
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. 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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
