| Message ID | 20200625120011.16168-1-tzimmermann@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: Support simple-framebuffer devices and firmware fbs | expand |
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 >
On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede@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 > > >
Hi, On 6/30/20 11:06 AM, Daniel Vetter wrote: > On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede@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
Hi Hans Am 29.06.20 um 11:38 schrieb Hans de Goede: > 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. Xorg is an important use case, but simplekms does not "break userspace." If you're not using simplekms, nothing changes; if simplekms is replaced by the native driver, nothing changes. Simplekms works with Xorg of the device is auto-configured. Xorg is not able to auto-configure simplekms devices ATM. > > 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. Sure, but simplekms is just a driver. Shouldn't it default to N anyway? > > 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? I'll do if somehow possible. See my reply to Daniel for a description of the problem. > >> 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. Great. If it's that easy; even better. > > 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: The whole bootsplash thing is really a follow-up project. What I have in mind for the bootsplash is the ACPI BGRT logo restoration that is currently in efifb. Maybe other sources for boot logos could be considered as well. And if nothing else, it could show a penguin. As soon as plymouth is ready, it would take over the display and do its thing. Noralf made a prototype of an in-kernel bootsplash client that displays a colored rectangle. That's already half of the work, I guess. Best regards Thomas > > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Daniel, thanks for reviewing most of the patchset. Am 30.06.20 um 11:06 schrieb Daniel Vetter: > On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede@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 tested simplekms with PCI graphics cards. Xorg does it's own scanning of the busses. It supports a platform bus, where it finds the simple-framebuffer device that is driven by simplekms. Xorg also scans the PCI bus, where is finds the native PCI device; usually driven by the native driver. It's the same hardware, but on different busses. For each device, Xorg tries to configure a screen, the Xorg modeset driver tried to open the DRM device file and acquire DRM master status on it. This works for the first screen, but DRM master status can only be acquired once, so it fails for the second screen. Xorg then aborts and asks for manual configuration of the display device. This can be solved by setting the platform device's bus id in the xorg.conf device section. It just doesn't happen automatically. I found it hard to find a solution to this. Weston just opens a DRM device file and uses whatever it gets. Ideally, Xorg would do the same. That whole bus-scanning exercise gives it a wrong idea on which graphics devices are available. One idea for a fix is to compare the device I/O-memory ranges and filter out duplicates on the Xorg modeset driver. I don't know how reliable this works in practice or if their are false positives. A more fundamental solution is to introduce a DRM bus in Xorg that enumerates all available DRM device files. If there are any, no other busses would be scanned. I'm still looking for something better. Idea are highly welcome. Best regards Thomas > >>> 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 >>> >> > >
Hi, On 7/1/20 3:48 PM, Thomas Zimmermann wrote: > Hi Hans > > Am 29.06.20 um 11:38 schrieb Hans de Goede: >> 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. > > Xorg is an important use case, but simplekms does not "break userspace." > If you're not using simplekms, nothing changes; if simplekms is replaced > by the native driver, nothing changes. Simplekms works with Xorg of the > device is auto-configured. Xorg is not able to auto-configure simplekms > devices ATM. As I already mentioned in my replay to Daniel: If there is no native driver, or the native driver fails to load (e.g. nvidia binary driver dkms build fails with a nwer kernel) then having simplekms enables changes the user, experience from Xorg on fbdev, slow but usable to search for a solution to no GUI. I agree that we cannot solve this on the kernel side, but it is a real problem which we need to keep in mind. >> 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. > > Sure, but simplekms is just a driver. Shouldn't it default to N anyway? I guess so. >> 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? > > I'll do if somehow possible. See my reply to Daniel for a description of > the problem. Great. >>> 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. > > Great. If it's that easy; even better. > >> >> 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: > > The whole bootsplash thing is really a follow-up project. > > What I have in mind for the bootsplash is the ACPI BGRT logo restoration > that is currently in efifb. Maybe other sources for boot logos could be > considered as well. And if nothing else, it could show a penguin. As > soon as plymouth is ready, it would take over the display and do its thing. > > Noralf made a prototype of an in-kernel bootsplash client that displays > a colored rectangle. That's already half of the work, I guess. Ok, this sounds good. Regards, Hans
Hi, On 7/1/20 4:10 PM, Thomas Zimmermann wrote: > Hi Daniel, > > thanks for reviewing most of the patchset. > > Am 30.06.20 um 11:06 schrieb Daniel Vetter: >> On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede@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 tested simplekms with PCI graphics cards. > > Xorg does it's own scanning of the busses. It supports a platform bus, > where it finds the simple-framebuffer device that is driven by > simplekms. Xorg also scans the PCI bus, where is finds the native PCI > device; usually driven by the native driver. It's the same hardware, but > on different busses. > > For each device, Xorg tries to configure a screen, the Xorg modeset > driver tried to open the DRM device file and acquire DRM master status > on it. This works for the first screen, but DRM master status can only > be acquired once, so it fails for the second screen. Xorg then aborts > and asks for manual configuration of the display device. > > This can be solved by setting the platform device's bus id in the > xorg.conf device section. It just doesn't happen automatically. > > I found it hard to find a solution to this. Weston just opens a DRM > device file and uses whatever it gets. Ideally, Xorg would do the same. > That whole bus-scanning exercise gives it a wrong idea on which graphics > devices are available. > > One idea for a fix is to compare the device I/O-memory ranges and filter > out duplicates on the Xorg modeset driver. I don't know how reliable > this works in practice or if their are false positives. I think that this should work nicely, although I wonder how Xorg will get the memory-range for the simplefb platform device, it looks like it will need to parse /dev/iomem for this, or we need to add a new sysfs attr to the simplefb device for this. Adding the new sysfs attr has the added bonus that we only enable the duplicate based resource check for simplefb devices. Hmm, I think we can actually fix this quite simply, for the platform device, check the basename of where the /sys/bus/platform/devices/XXXX/driver symlink points to and if it is simplekms ignore it, assuming that there will be another PCI or platform device which is the actual GPU. I guess that might cause a problem where the output-device driven through simplekms is not visible to Xorg in any other way, but I don't think that that ever happens? And even if it does, then it is probably better to teach Xorg about it, since we likely want to replace simplekms with a more full-featured driver at some point anyways. Can you try commenting out the platform bus scanning code in Xorg's autoconfigure code and see if that fixes the no Xorg.conf case ? If it does the driver symlink trick will probably fix 99.9 % of all cases here, and we can worry about the others if we ever encounter them. > A more fundamental solution is to introduce a DRM bus in Xorg that > enumerates all available DRM device files. If there are any, no other > busses would be scanned. That would break the case where there are 2 cards and 1 has a kms driver and the other only supports fbdev. Admittedly this is a corner case, but I do believe that we cannot just go and break this. Regards, Hans
Hi Am 03.07.20 um 12:55 schrieb Hans de Goede: > Hi, > > On 7/1/20 4:10 PM, Thomas Zimmermann wrote: >> Hi Daniel, >> >> thanks for reviewing most of the patchset. >> >> Am 30.06.20 um 11:06 schrieb Daniel Vetter: >>> On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede@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 tested simplekms with PCI graphics cards. >> >> Xorg does it's own scanning of the busses. It supports a platform bus, >> where it finds the simple-framebuffer device that is driven by >> simplekms. Xorg also scans the PCI bus, where is finds the native PCI >> device; usually driven by the native driver. It's the same hardware, but >> on different busses. >> >> For each device, Xorg tries to configure a screen, the Xorg modeset >> driver tried to open the DRM device file and acquire DRM master status >> on it. This works for the first screen, but DRM master status can only >> be acquired once, so it fails for the second screen. Xorg then aborts >> and asks for manual configuration of the display device. >> >> This can be solved by setting the platform device's bus id in the >> xorg.conf device section. It just doesn't happen automatically. >> >> I found it hard to find a solution to this. Weston just opens a DRM >> device file and uses whatever it gets. Ideally, Xorg would do the same. >> That whole bus-scanning exercise gives it a wrong idea on which graphics >> devices are available. >> >> One idea for a fix is to compare the device I/O-memory ranges and filter >> out duplicates on the Xorg modeset driver. I don't know how reliable >> this works in practice or if their are false positives. > > I think that this should work nicely, although I wonder how Xorg will > get the memory-range for the simplefb platform device, it looks like > it will need to parse /dev/iomem for this, or we need to add a > new sysfs attr to the simplefb device for this. Adding the new sysfs > attr has the added bonus that we only enable the duplicate based > resource check for simplefb devices. > > Hmm, I think we can actually fix this quite simply, for the platform > device, check the basename of where the > /sys/bus/platform/devices/XXXX/driver symlink points to and if it > is simplekms ignore it, assuming that there will be another PCI > or platform device which is the actual GPU. That probably would not work. On aarch64, we (SUSE) utilize EFI via grub-privided efi stubs (as far as i understand). This allows us to use the kernel's efifb driver for boot-up graphics. But there's no PCI bus on most of these systems. I don't think Xorg could rely on that. > > I guess that might cause a problem where the output-device driven > through simplekms is not visible to Xorg in any other way, but > I don't think that that ever happens? And even if it does, then it > is probably better to teach Xorg about it, since we likely want to > replace simplekms with a more full-featured driver at some point > anyways. > > Can you try commenting out the platform bus scanning code in Xorg's > autoconfigure code and see if that fixes the no Xorg.conf case ? That works to some extent. Xorg drivers provide a bus-specific probe function. Returning false from the platform-probe function in the Xorg modesetting driver makes the PCI side work on top of simplekms. Returning false from the Xorg driver's PCI-probe function does not work however. It's some Xorg weirdness, I guess. What I'd want is to accept the platform device, but later fails for the PCI device. > > If it does the driver symlink trick will probably fix 99.9 % > of all cases here, and we can worry about the others if we > ever encounter them. > >> A more fundamental solution is to introduce a DRM bus in Xorg that >> enumerates all available DRM device files. If there are any, no other >> busses would be scanned. > > That would break the case where there are 2 cards and 1 has a kms > driver and the other only supports fbdev. Admittedly this is a > corner case, but I do believe that we cannot just go and break this. Yep, that was my concern. Best regards Thomas > > Regards, > > Hans >
On Fri, Jul 3, 2020 at 12:55 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 7/1/20 4:10 PM, Thomas Zimmermann wrote: > > Hi Daniel, > > > > thanks for reviewing most of the patchset. > > > > Am 30.06.20 um 11:06 schrieb Daniel Vetter: > >> On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede@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 tested simplekms with PCI graphics cards. > > > > Xorg does it's own scanning of the busses. It supports a platform bus, > > where it finds the simple-framebuffer device that is driven by > > simplekms. Xorg also scans the PCI bus, where is finds the native PCI > > device; usually driven by the native driver. It's the same hardware, but > > on different busses. > > > > For each device, Xorg tries to configure a screen, the Xorg modeset > > driver tried to open the DRM device file and acquire DRM master status > > on it. This works for the first screen, but DRM master status can only > > be acquired once, so it fails for the second screen. Xorg then aborts > > and asks for manual configuration of the display device. > > > > This can be solved by setting the platform device's bus id in the > > xorg.conf device section. It just doesn't happen automatically. > > > > I found it hard to find a solution to this. Weston just opens a DRM > > device file and uses whatever it gets. Ideally, Xorg would do the same. > > That whole bus-scanning exercise gives it a wrong idea on which graphics > > devices are available. > > > > One idea for a fix is to compare the device I/O-memory ranges and filter > > out duplicates on the Xorg modeset driver. I don't know how reliable > > this works in practice or if their are false positives. > > I think that this should work nicely, although I wonder how Xorg will > get the memory-range for the simplefb platform device, it looks like > it will need to parse /dev/iomem for this, or we need to add a > new sysfs attr to the simplefb device for this. Adding the new sysfs > attr has the added bonus that we only enable the duplicate based > resource check for simplefb devices. Uh why exactly does Xorg even need to do all this parsing? We're not in a ums world anymore ... Also, you'll never have a simplekms driver _and_ the real drm driver bound at the same time, that's a kernel bug. Really all this bus scanning is vestiges in Xorg from the old pre-kms days, and there's no point. Scan all drm device nodes (not physical devices) like anything remotely modern, and it's all good. Maybe that means Xorg needs a drm bus to fit into this world, and only if that gives you nothing, fall back to the historical real bus scanning. > Hmm, I think we can actually fix this quite simply, for the platform > device, check the basename of where the > /sys/bus/platform/devices/XXXX/driver symlink points to and if it > is simplekms ignore it, assuming that there will be another PCI > or platform device which is the actual GPU. Again, you're not going to have simplekms and the real driver bound at the same time. Kernel guarantees that. Userspace isn't in the business of second-guessing the kernel's device model, that only leads to pain like the one we have here, were Xorg can't both use platform and pci devices for some oddball reason :-/ > I guess that might cause a problem where the output-device driven > through simplekms is not visible to Xorg in any other way, but > I don't think that that ever happens? And even if it does, then it > is probably better to teach Xorg about it, since we likely want to > replace simplekms with a more full-featured driver at some point > anyways. > > Can you try commenting out the platform bus scanning code in Xorg's > autoconfigure code and see if that fixes the no Xorg.conf case ? > > If it does the driver symlink trick will probably fix 99.9 % > of all cases here, and we can worry about the others if we > ever encounter them. > > > A more fundamental solution is to introduce a DRM bus in Xorg that > > enumerates all available DRM device files. If there are any, no other > > busses would be scanned. > > That would break the case where there are 2 cards and 1 has a kms > driver and the other only supports fbdev. Admittedly this is a > corner case, but I do believe that we cannot just go and break this. Yeah but even for this case can't Xorg simply first scan drm drivers, and then fbdev drivers (excluding the drm ones, that's pretty easy to do since they're both bound to the same physical device in sysfs). Not magic guesses at how the platform model works. Also, we don't have to make this work with current Xorg code, since it's a new driver that distros need to enable explicitly. So fixing Xorg should be on the table. Or we just forget about Xorg, and tell distros that this only works if they have a reasonable wayland compositor that doesn't have an entire hand-rolled device model. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Hi, On 7/3/20 2:58 PM, Daniel Vetter wrote: > On Fri, Jul 3, 2020 at 12:55 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi, >> >> On 7/1/20 4:10 PM, Thomas Zimmermann wrote: >>> Hi Daniel, >>> >>> thanks for reviewing most of the patchset. >>> >>> Am 30.06.20 um 11:06 schrieb Daniel Vetter: >>>> On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede <hdegoede@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 tested simplekms with PCI graphics cards. >>> >>> Xorg does it's own scanning of the busses. It supports a platform bus, >>> where it finds the simple-framebuffer device that is driven by >>> simplekms. Xorg also scans the PCI bus, where is finds the native PCI >>> device; usually driven by the native driver. It's the same hardware, but >>> on different busses. >>> >>> For each device, Xorg tries to configure a screen, the Xorg modeset >>> driver tried to open the DRM device file and acquire DRM master status >>> on it. This works for the first screen, but DRM master status can only >>> be acquired once, so it fails for the second screen. Xorg then aborts >>> and asks for manual configuration of the display device. >>> >>> This can be solved by setting the platform device's bus id in the >>> xorg.conf device section. It just doesn't happen automatically. >>> >>> I found it hard to find a solution to this. Weston just opens a DRM >>> device file and uses whatever it gets. Ideally, Xorg would do the same. >>> That whole bus-scanning exercise gives it a wrong idea on which graphics >>> devices are available. >>> >>> One idea for a fix is to compare the device I/O-memory ranges and filter >>> out duplicates on the Xorg modeset driver. I don't know how reliable >>> this works in practice or if their are false positives. >> >> I think that this should work nicely, although I wonder how Xorg will >> get the memory-range for the simplefb platform device, it looks like >> it will need to parse /dev/iomem for this, or we need to add a >> new sysfs attr to the simplefb device for this. Adding the new sysfs >> attr has the added bonus that we only enable the duplicate based >> resource check for simplefb devices. > > Uh why exactly does Xorg even need to do all this parsing? We're not > in a ums world anymore ... > > Also, you'll never have a simplekms driver _and_ the real drm driver > bound at the same time, that's a kernel bug. > > Really all this bus scanning is vestiges in Xorg from the old pre-kms > days, and there's no point. Scan all drm device nodes (not physical > devices) like anything remotely modern, and it's all good. Maybe that > means Xorg needs a drm bus to fit into this world, and only if that > gives you nothing, fall back to the historical real bus scanning. > >> Hmm, I think we can actually fix this quite simply, for the platform >> device, check the basename of where the >> /sys/bus/platform/devices/XXXX/driver symlink points to and if it >> is simplekms ignore it, assuming that there will be another PCI >> or platform device which is the actual GPU. > > Again, you're not going to have simplekms and the real driver bound at > the same time. Kernel guarantees that. Userspace isn't in the business > of second-guessing the kernel's device model, that only leads to pain > like the one we have here, were Xorg can't both use platform and pci > devices for some oddball reason :-/ > >> I guess that might cause a problem where the output-device driven >> through simplekms is not visible to Xorg in any other way, but >> I don't think that that ever happens? And even if it does, then it >> is probably better to teach Xorg about it, since we likely want to >> replace simplekms with a more full-featured driver at some point >> anyways. >> >> Can you try commenting out the platform bus scanning code in Xorg's >> autoconfigure code and see if that fixes the no Xorg.conf case ? >> >> If it does the driver symlink trick will probably fix 99.9 % >> of all cases here, and we can worry about the others if we >> ever encounter them. >> >>> A more fundamental solution is to introduce a DRM bus in Xorg that >>> enumerates all available DRM device files. If there are any, no other >>> busses would be scanned. >> >> That would break the case where there are 2 cards and 1 has a kms >> driver and the other only supports fbdev. Admittedly this is a >> corner case, but I do believe that we cannot just go and break this. > > Yeah but even for this case can't Xorg simply first scan drm drivers, > and then fbdev drivers (excluding the drm ones, that's pretty easy to > do since they're both bound to the same physical device in sysfs). Not > magic guesses at how the platform model works. Right, I guess the Xorg scanning architecture here still comes from the era where we had userspace mode-setting. > Also, we don't have to make this work with current Xorg code, since > it's a new driver that distros need to enable explicitly. So fixing > Xorg should be on the table. Ack. > Or we just forget about Xorg, and tell distros that this only works if > they have a reasonable wayland compositor that doesn't have an entire > hand-rolled device model. Yeah I don't think that is going to fly. Regards, Hans