Hi,
The VC4 driver has had limited support to disable the HDMI controllers and pixelvalves at boot if the firmware has enabled them.
However, this proved to be limited, and a bit unreliable so a new firmware command has been introduced some time ago to make it free all its resources and disable any display output it might have enabled.
This series takes advantage of that command to call it once the transition from simplefb to the KMS driver has been done.
Let me know what you think, Maxime
---
Changes from v3: - Support nomodeset
Changes from v2: - Switch back to rpi_firmware_get / rpi_firmware_put - Moved the rpi_firmware pointer to a local variable
Changes from v1: - Use of_find_compatible_node instead of a phandle - Use devm_rpi_firmware_get
Maxime Ripard (4): firmware: raspberrypi: Add RPI_FIRMWARE_NOTIFY_DISPLAY_DONE drm/vc4: Support nomodeset drm/vc4: Remove conflicting framebuffers before callind bind_all drm/vc4: Notify the firmware when DRM is in charge
drivers/gpu/drm/vc4/vc4_drv.c | 50 ++++++++++++++++++---- include/soc/bcm2835/raspberrypi-firmware.h | 1 + 2 files changed, 42 insertions(+), 9 deletions(-)
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the firmware the kernel is in charge of the display now and the firmware can free whatever resources it was using.
Acked-by: Nicolas Saenz Julienne nsaenz@kernel.org Signed-off-by: Maxime Ripard maxime@cerno.tech --- include/soc/bcm2835/raspberrypi-firmware.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h index 73ad784fca96..811ea668c4a1 100644 --- a/include/soc/bcm2835/raspberrypi-firmware.h +++ b/include/soc/bcm2835/raspberrypi-firmware.h @@ -91,6 +91,7 @@ enum rpi_firmware_property_tag { RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049, RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050, RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058, + RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
/* Dispmanx TAGS */ RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
If we have nomodeset on the kernel command line we should have the firmware framebuffer driver kept as is and not try to load the full-blown KMS driver.
In this case, let's just register the v3d driver.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/gpu/drm/vc4/vc4_drv.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 16abc3a3d601..12694e2201e7 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -357,12 +357,22 @@ static int __init vc4_drm_register(void) { int ret;
- ret = platform_register_drivers(component_drivers, - ARRAY_SIZE(component_drivers)); - if (ret) - return ret; + if (!drm_firmware_drivers_only()) { + ret = platform_register_drivers(component_drivers, + ARRAY_SIZE(component_drivers)); + if (ret) + return ret;
- return platform_driver_register(&vc4_platform_driver); + ret = platform_driver_register(&vc4_platform_driver); + if (ret) + return ret; + } else { + ret = platform_driver_register(&vc4_v3d_driver); + if (ret) + return ret; + } + + return 0; }
static void __exit vc4_drm_unregister(void)
Hello Maxime
On Mon, Dec 13, 2021 at 5:26 PM Maxime Ripard maxime@cerno.tech wrote:
If we have nomodeset on the kernel command line we should have the firmware framebuffer driver kept as is and not try to load the full-blown KMS driver.
Patch looks good to me. I just have a question, but I'm OK with either way.
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
In this case, let's just register the v3d driver.
I wonder if the v3d driver should be registered if nomodeset is present. Most (if not all?) drivers that currently check for this parameter disable both KMS and DRM. So even when it seems to imply that's about kernel mode settings, it is also used to disable DRM.
This semantic was never documented and I attempted to do that in commit b22a15a5aca3 ("Documentation/admin-guide: Document nomodeset kernel parameter"). After feedback from folks in the list, the text ended as follows:
``` Disable kernel modesetting. DRM drivers will not perform display-mode changes or accelerated rendering. Only the system framebuffer will be available for use if this was set-up by the firmware or boot loader.
Useful as fallback, or for testing and debugging. ```
So maybe vc4_drm_register() should just return -EINVAL if (drm_firmware_drivers_only()) like the other drivers do?
Best regards, Javier
Hi
Am 14.12.21 um 09:30 schrieb Javier Martinez Canillas:
Hello Maxime
On Mon, Dec 13, 2021 at 5:26 PM Maxime Ripard maxime@cerno.tech wrote:
If we have nomodeset on the kernel command line we should have the firmware framebuffer driver kept as is and not try to load the full-blown KMS driver.
Patch looks good to me. I just have a question, but I'm OK with either way.
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
In this case, let's just register the v3d driver.
I wonder if the v3d driver should be registered if nomodeset is present. Most (if not all?) drivers that currently check for this parameter disable both KMS and DRM. So even when it seems to imply that's about kernel mode settings, it is also used to disable DRM.
This semantic was never documented and I attempted to do that in commit b22a15a5aca3 ("Documentation/admin-guide: Document nomodeset kernel parameter"). After feedback from folks in the list, the text ended as follows:
Disable kernel modesetting. DRM drivers will not perform display-mode changes or accelerated rendering. Only the system framebuffer will be available for use if this was set-up by the firmware or boot loader. Useful as fallback, or for testing and debugging.So maybe vc4_drm_register() should just return -EINVAL if (drm_firmware_drivers_only()) like the other drivers do?
I second this comment. The intention of this test is to disable HW-native drivers if something goes wrong with the display.
The function's name drm_firmware_drivers_only() reflects that. The parameter is called nomodeset for historical reasons and it's probably a terrible name.
So I think the code should call drm_firmware_drivers_only() at the top and return an error is it's true. That's what we will do for other drivers as well. Maybe rather return -ENODEV; EINVAL mean 'invalid argument'.
Best regards Thomas
Best regards, Javier
The bind hooks will modify their controller registers, so simplefb is going to be unusable anyway. Let's avoid any transient state where it could still be in the system but no longer functionnal.
Acked-by: Nicolas Saenz Julienne nsaenz@kernel.org Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/gpu/drm/vc4/vc4_drv.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 12694e2201e7..c0d7e510694f 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -251,6 +251,10 @@ static int vc4_drm_bind(struct device *dev) if (ret) return ret;
+ ret = drm_aperture_remove_framebuffers(false, &vc4_drm_driver); + if (ret) + return ret; + ret = component_bind_all(dev, drm); if (ret) return ret; @@ -259,10 +263,6 @@ static int vc4_drm_bind(struct device *dev) if (ret) goto unbind_all;
- ret = drm_aperture_remove_framebuffers(false, &vc4_drm_driver); - if (ret) - goto unbind_all; - ret = vc4_kms_load(drm); if (ret < 0) goto unbind_all;
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has been made, simplefb has been unregistered and the KMS driver is entirely in charge of the display.
Thus, we can notify the firmware it can free whatever resource it was using to maintain simplefb functional.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/gpu/drm/vc4/vc4_drv.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index c0d7e510694f..e4bb37a191f6 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -37,6 +37,8 @@ #include <drm/drm_fb_helper.h> #include <drm/drm_vblank.h>
+#include <soc/bcm2835/raspberrypi-firmware.h> + #include "uapi/drm/vc4_drm.h"
#include "vc4_drv.h" @@ -215,6 +217,7 @@ static void vc4_match_add_drivers(struct device *dev, static int vc4_drm_bind(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); + struct rpi_firmware *firmware = NULL; struct drm_device *drm; struct vc4_dev *vc4; struct device_node *node; @@ -251,10 +254,29 @@ static int vc4_drm_bind(struct device *dev) if (ret) return ret;
+ node = of_find_compatible_node(NULL, NULL, "raspberrypi,bcm2835-firmware"); + if (node) { + firmware = rpi_firmware_get(node); + of_node_put(node); + + if (!firmware) + return -EPROBE_DEFER; + } + ret = drm_aperture_remove_framebuffers(false, &vc4_drm_driver); if (ret) return ret;
+ if (firmware) { + ret = rpi_firmware_property(firmware, + RPI_FIRMWARE_NOTIFY_DISPLAY_DONE, + NULL, 0); + if (ret) + drm_warn(drm, "Couldn't stop firmware display driver: %d\n", ret); + + rpi_firmware_put(firmware); + } + ret = component_bind_all(dev, drm); if (ret) return ret;
dri-devel@lists.freedesktop.org
-
Javier Martinez Canillas -
Maxime Ripard -
Thomas Zimmermann