[PATCH RESEND v4 v4 0/4] drm/vc4: Use the firmware to stop the display pipeline

[PATCH RESEND v4 v4 0/4] drm/vc4: Use the firmware to stop the display pipeline

[Maxime Ripard]

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(-)

-- 
2.33.1

[PATCH RESEND v4 v4 1/4] firmware: raspberrypi: Add RPI_FIRMWARE_NOTIFY_DISPLAY_DONE

[Maxime Ripard]

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,
-- 
2.33.1

[PATCH RESEND v4 v4 2/4] drm/vc4: Support nomodeset

[Maxime Ripard]

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)
-- 
2.33.1

[PATCH RESEND v4 v4 3/4] drm/vc4: Remove conflicting framebuffers before callind bind_all

[Maxime Ripard]

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;
-- 
2.33.1

[PATCH RESEND v4 v4 4/4] drm/vc4: Notify the firmware when DRM is in charge

[Maxime Ripard]

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;
-- 
2.33.1

Re: [PATCH RESEND v4 v4 2/4] drm/vc4: Support nomodeset

[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?

Best regards,
Javier

Re: [PATCH RESEND v4 v4 2/4] drm/vc4: Support nomodeset

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2246 bytes --]

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
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]