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

[Hans de Goede]

Hi,

On 6/30/20 11:06 AM, Daniel Vetter wrote:
> 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?

I guess that Thomas deliberately disabled the normal kms driver to test this.

Still we should make sure that this (Xorg on simpledrm) works, a user might
see this because of running an older kernel with a newer GPU, or when
using the nvidia binary and thus having nouveau disabled and then installing
a newer kernel which breaks the dkms nvidia module building because of API
changes.

Regards,

Hans