This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4.
I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing.
Changes since v5: - Update the DT compatible to match the others that were updated - Adjust the Kconfig help text - Add review tags
Changes since v4: - Fixes for device tree and bindings - Split out the power management changes into an independent set - Rebase to 5.18 - Individual changes in patches
[1] https://www.spinics.net/lists/arm-kernel/msg980342.html
Nicolas Saenz Julienne (1): arm64: config: Enable DRM_V3D
Peter Robinson (5): dt-bindings: gpu: v3d: Add BCM2711's compatible drm/v3d: Get rid of pm code drm/v3d: Add support for bcm2711 ARM: dts: bcm2711: Enable V3D ARM: configs: Enable DRM_V3D
.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 + arch/arm/boot/dts/bcm2711-rpi.dtsi | 4 ++++ arch/arm/boot/dts/bcm2711.dtsi | 11 +++++++++++ arch/arm/configs/bcm2835_defconfig | 1 + arch/arm/configs/multi_v7_defconfig | 1 + arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/v3d/Kconfig | 5 +++-- drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +----------------- drivers/gpu/drm/v3d/v3d_drv.c | 12 +----------- drivers/gpu/drm/v3d/v3d_gem.c | 12 +----------- 10 files changed, 25 insertions(+), 41 deletions(-)
BCM2711, Raspberry Pi 4's SoC, contains a V3D core. So add its specific compatible to the bindings.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Stefan Wahren stefan.wahren@i2se.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com Acked-by: Rob Herring robh@kernel.org --- Changes since v4: - Change compatible to align downstream and other HW, reorder to suit
Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 + 1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml index e6485f7b046f..217c42874f41 100644 --- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml @@ -16,6 +16,7 @@ properties:
compatible: enum: + - brcm,2711-v3d - brcm,7268-v3d - brcm,7278-v3d
Runtime PM doesn't seem to work correctly on this driver. On top of that, commit 8b6864e3e138 ("drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'") hints that it most likely never did as the driver's PM ops were not hooked-up.
So, in order to support regular operation with V3D on BCM2711 (Raspberry Pi 4), get rid of the PM code. PM will be reinstated once we figure out the underlying issues.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com --- Changes since v4: - Rebase
Changes since v3: - Minor updates for rebase
drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +----------------- drivers/gpu/drm/v3d/v3d_drv.c | 11 ----------- drivers/gpu/drm/v3d/v3d_gem.c | 12 +----------- 3 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c b/drivers/gpu/drm/v3d/v3d_debugfs.c index 29fd13109e43..efbde124c296 100644 --- a/drivers/gpu/drm/v3d/v3d_debugfs.c +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c @@ -4,7 +4,6 @@ #include <linux/circ_buf.h> #include <linux/ctype.h> #include <linux/debugfs.h> -#include <linux/pm_runtime.h> #include <linux/seq_file.h> #include <linux/string_helpers.h>
@@ -131,11 +130,7 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void *unused) struct drm_device *dev = node->minor->dev; struct v3d_dev *v3d = to_v3d_dev(dev); u32 ident0, ident1, ident2, ident3, cores; - int ret, core; - - ret = pm_runtime_get_sync(v3d->drm.dev); - if (ret < 0) - return ret; + int core;
ident0 = V3D_READ(V3D_HUB_IDENT0); ident1 = V3D_READ(V3D_HUB_IDENT1); @@ -188,9 +183,6 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void *unused) (misccfg & V3D_MISCCFG_OVRTMUOUT) != 0); }
- pm_runtime_mark_last_busy(v3d->drm.dev); - pm_runtime_put_autosuspend(v3d->drm.dev); - return 0; }
@@ -218,11 +210,6 @@ static int v3d_measure_clock(struct seq_file *m, void *unused) uint32_t cycles; int core = 0; int measure_ms = 1000; - int ret; - - ret = pm_runtime_get_sync(v3d->drm.dev); - if (ret < 0) - return ret;
if (v3d->ver >= 40) { V3D_CORE_WRITE(core, V3D_V4_PCTR_0_SRC_0_3, @@ -246,9 +233,6 @@ static int v3d_measure_clock(struct seq_file *m, void *unused) cycles / (measure_ms * 1000), (cycles / (measure_ms * 100)) % 10);
- pm_runtime_mark_last_busy(v3d->drm.dev); - pm_runtime_put_autosuspend(v3d->drm.dev); - return 0; }
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c index 1afcd54fbbd5..56d5f831e48b 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.c +++ b/drivers/gpu/drm/v3d/v3d_drv.c @@ -19,7 +19,6 @@ #include <linux/module.h> #include <linux/of_platform.h> #include <linux/platform_device.h> -#include <linux/pm_runtime.h> #include <linux/reset.h>
#include <drm/drm_drv.h> @@ -43,7 +42,6 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void *data, { struct v3d_dev *v3d = to_v3d_dev(dev); struct drm_v3d_get_param *args = data; - int ret; static const u32 reg_map[] = { [DRM_V3D_PARAM_V3D_UIFCFG] = V3D_HUB_UIFCFG, [DRM_V3D_PARAM_V3D_HUB_IDENT1] = V3D_HUB_IDENT1, @@ -69,17 +67,12 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void *data, if (args->value != 0) return -EINVAL;
- ret = pm_runtime_get_sync(v3d->drm.dev); - if (ret < 0) - return ret; if (args->param >= DRM_V3D_PARAM_V3D_CORE0_IDENT0 && args->param <= DRM_V3D_PARAM_V3D_CORE0_IDENT2) { args->value = V3D_CORE_READ(0, offset); } else { args->value = V3D_READ(offset); } - pm_runtime_mark_last_busy(v3d->drm.dev); - pm_runtime_put_autosuspend(v3d->drm.dev); return 0; }
@@ -280,10 +273,6 @@ static int v3d_platform_drm_probe(struct platform_device *pdev) return -ENOMEM; }
- pm_runtime_use_autosuspend(dev); - pm_runtime_set_autosuspend_delay(dev, 50); - pm_runtime_enable(dev); - ret = v3d_gem_init(drm); if (ret) goto dma_free; diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c index 92bc0faee84f..7026214a09f0 100644 --- a/drivers/gpu/drm/v3d/v3d_gem.c +++ b/drivers/gpu/drm/v3d/v3d_gem.c @@ -6,7 +6,6 @@ #include <linux/io.h> #include <linux/module.h> #include <linux/platform_device.h> -#include <linux/pm_runtime.h> #include <linux/reset.h> #include <linux/sched/signal.h> #include <linux/uaccess.h> @@ -367,9 +366,6 @@ v3d_job_free(struct kref *ref) dma_fence_put(job->irq_fence); dma_fence_put(job->done_fence);
- pm_runtime_mark_last_busy(job->v3d->drm.dev); - pm_runtime_put_autosuspend(job->v3d->drm.dev); - if (job->perfmon) v3d_perfmon_put(job->perfmon);
@@ -471,14 +467,10 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv, job->v3d = v3d; job->free = free;
- ret = pm_runtime_get_sync(v3d->drm.dev); - if (ret < 0) - goto fail; - ret = drm_sched_job_init(&job->base, &v3d_priv->sched_entity[queue], v3d_priv); if (ret) - goto fail_job; + goto fail;
if (has_multisync) { if (se->in_sync_count && se->wait_stage == queue) { @@ -509,8 +501,6 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
fail_deps: drm_sched_job_cleanup(&job->base); -fail_job: - pm_runtime_put_autosuspend(v3d->drm.dev); fail: kfree(*container); *container = NULL;
On 06/03, Peter Robinson wrote:
Runtime PM doesn't seem to work correctly on this driver. On top of that, commit 8b6864e3e138 ("drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'") hints that it most likely never did as the driver's PM ops were not hooked-up.
So, in order to support regular operation with V3D on BCM2711 (Raspberry Pi 4), get rid of the PM code. PM will be reinstated once we figure out the underlying issues.
I've spent some time trying to get PM working properly on RPi4, but I haven´t gotten good results yet, and all attempts ended up disabling the auto suspend option somehow. Keeping in mind how long this has been unresolved, I agree to clean it now as we continue to investigate the issue.
Acked-by: Melissa Wen mwen@igalia.com
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Changes since v4:
- Rebase
Changes since v3:
- Minor updates for rebase
drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +----------------- drivers/gpu/drm/v3d/v3d_drv.c | 11 ----------- drivers/gpu/drm/v3d/v3d_gem.c | 12 +----------- 3 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c b/drivers/gpu/drm/v3d/v3d_debugfs.c index 29fd13109e43..efbde124c296 100644 --- a/drivers/gpu/drm/v3d/v3d_debugfs.c +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c @@ -4,7 +4,6 @@ #include <linux/circ_buf.h> #include <linux/ctype.h> #include <linux/debugfs.h> -#include <linux/pm_runtime.h> #include <linux/seq_file.h> #include <linux/string_helpers.h>
@@ -131,11 +130,7 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void *unused) struct drm_device *dev = node->minor->dev; struct v3d_dev *v3d = to_v3d_dev(dev); u32 ident0, ident1, ident2, ident3, cores;
- int ret, core;
- ret = pm_runtime_get_sync(v3d->drm.dev);
- if (ret < 0)
return ret;
int core;
ident0 = V3D_READ(V3D_HUB_IDENT0); ident1 = V3D_READ(V3D_HUB_IDENT1);
@@ -188,9 +183,6 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void *unused) (misccfg & V3D_MISCCFG_OVRTMUOUT) != 0); }
- pm_runtime_mark_last_busy(v3d->drm.dev);
- pm_runtime_put_autosuspend(v3d->drm.dev);
- return 0;
}
@@ -218,11 +210,6 @@ static int v3d_measure_clock(struct seq_file *m, void *unused) uint32_t cycles; int core = 0; int measure_ms = 1000;
int ret;
ret = pm_runtime_get_sync(v3d->drm.dev);
if (ret < 0)
return ret;if (v3d->ver >= 40) { V3D_CORE_WRITE(core, V3D_V4_PCTR_0_SRC_0_3,
@@ -246,9 +233,6 @@ static int v3d_measure_clock(struct seq_file *m, void *unused) cycles / (measure_ms * 1000), (cycles / (measure_ms * 100)) % 10);
- pm_runtime_mark_last_busy(v3d->drm.dev);
- pm_runtime_put_autosuspend(v3d->drm.dev);
- return 0;
}
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c index 1afcd54fbbd5..56d5f831e48b 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.c +++ b/drivers/gpu/drm/v3d/v3d_drv.c @@ -19,7 +19,6 @@ #include <linux/module.h> #include <linux/of_platform.h> #include <linux/platform_device.h> -#include <linux/pm_runtime.h> #include <linux/reset.h>
#include <drm/drm_drv.h> @@ -43,7 +42,6 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void *data, { struct v3d_dev *v3d = to_v3d_dev(dev); struct drm_v3d_get_param *args = data;
- int ret; static const u32 reg_map[] = { [DRM_V3D_PARAM_V3D_UIFCFG] = V3D_HUB_UIFCFG, [DRM_V3D_PARAM_V3D_HUB_IDENT1] = V3D_HUB_IDENT1,
@@ -69,17 +67,12 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void *data, if (args->value != 0) return -EINVAL;
ret = pm_runtime_get_sync(v3d->drm.dev);if (ret < 0)return ret;pm_runtime_mark_last_busy(v3d->drm.dev);pm_runtime_put_autosuspend(v3d->drm.dev);@@ -280,10 +273,6 @@ static int v3d_platform_drm_probe(struct platform_device *pdev) return -ENOMEM; }
- pm_runtime_use_autosuspend(dev);
- pm_runtime_set_autosuspend_delay(dev, 50);
- pm_runtime_enable(dev);
- ret = v3d_gem_init(drm); if (ret) goto dma_free;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c index 92bc0faee84f..7026214a09f0 100644 --- a/drivers/gpu/drm/v3d/v3d_gem.c +++ b/drivers/gpu/drm/v3d/v3d_gem.c @@ -6,7 +6,6 @@ #include <linux/io.h> #include <linux/module.h> #include <linux/platform_device.h> -#include <linux/pm_runtime.h> #include <linux/reset.h> #include <linux/sched/signal.h> #include <linux/uaccess.h> @@ -367,9 +366,6 @@ v3d_job_free(struct kref *ref) dma_fence_put(job->irq_fence); dma_fence_put(job->done_fence);
- pm_runtime_mark_last_busy(job->v3d->drm.dev);
- pm_runtime_put_autosuspend(job->v3d->drm.dev);
- if (job->perfmon) v3d_perfmon_put(job->perfmon);
@@ -471,14 +467,10 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv, job->v3d = v3d; job->free = free;
- ret = pm_runtime_get_sync(v3d->drm.dev);
- if (ret < 0)
goto fail;- ret = drm_sched_job_init(&job->base, &v3d_priv->sched_entity[queue], v3d_priv); if (ret)
goto fail_job;
goto fail;if (has_multisync) { if (se->in_sync_count && se->wait_stage == queue) {
@@ -509,8 +501,6 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
fail_deps: drm_sched_job_cleanup(&job->base); -fail_job:
- pm_runtime_put_autosuspend(v3d->drm.dev);
fail: kfree(*container);
*container = NULL;
2.36.1
Add compatible string and Kconfig options and help for bcm2711.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Stefan Wahren stefan.wahren@i2se.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com --- Changes since v5: - Update help text to cover all supported SoCs
Changes since v4: - Change compatible to align downstream and other HW, reorder to suit
drivers/gpu/drm/v3d/Kconfig | 5 +++-- drivers/gpu/drm/v3d/v3d_drv.c | 1 + 2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig index e973ec487484..ce62c5908e1d 100644 --- a/drivers/gpu/drm/v3d/Kconfig +++ b/drivers/gpu/drm/v3d/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_V3D tristate "Broadcom V3D 3.x and newer" - depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST + depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || COMPILE_TEST depends on DRM depends on COMMON_CLK depends on MMU @@ -9,4 +9,5 @@ config DRM_V3D select DRM_GEM_SHMEM_HELPER help Choose this option if you have a system that has a Broadcom - V3D 3.x or newer GPU, such as BCM7268. + V3D 3.x or newer GPUs. SoCs supported include the BCM2711, + BCM7268 and BCM7278. diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c index 56d5f831e48b..8c7f910daa28 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.c +++ b/drivers/gpu/drm/v3d/v3d_drv.c @@ -191,6 +191,7 @@ static const struct drm_driver v3d_drm_driver = { };
static const struct of_device_id v3d_of_match[] = { + { .compatible = "brcm,2711-v3d" }, { .compatible = "brcm,7268-v3d" }, { .compatible = "brcm,7278-v3d" }, {},
This adds the entry for V3D for bcm2711 (used in the Raspberry Pi 4) and the associated firmware clock entry.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com --- Changes since v5: - Update the compatible to match the other updated ones
Changes since v4: - Move the firmware clock to bcm2711-rpi.dtsi
arch/arm/boot/dts/bcm2711-rpi.dtsi | 4 ++++ arch/arm/boot/dts/bcm2711.dtsi | 11 +++++++++++ 2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711-rpi.dtsi b/arch/arm/boot/dts/bcm2711-rpi.dtsi index ca266c5d9f9b..98817a6675b9 100644 --- a/arch/arm/boot/dts/bcm2711-rpi.dtsi +++ b/arch/arm/boot/dts/bcm2711-rpi.dtsi @@ -69,6 +69,10 @@ blconfig: nvram@0 { }; };
+&v3d { + clocks = <&firmware_clocks 5>; +}; + &vchiq { interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; }; diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi index 89af57482bc8..20e6771e8b1f 100644 --- a/arch/arm/boot/dts/bcm2711.dtsi +++ b/arch/arm/boot/dts/bcm2711.dtsi @@ -601,6 +601,17 @@ genet_mdio: mdio@e14 { #size-cells = <0x0>; }; }; + + v3d: gpu@7ec00000 { + compatible = "brcm,2711-v3d"; + reg = <0x0 0x7ec00000 0x4000>, + <0x0 0x7ec04000 0x4000>; + reg-names = "hub", "core0"; + + power-domains = <&pm BCM2835_POWER_DOMAIN_GRAFX_V3D>; + resets = <&pm BCM2835_RESET_V3D>; + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>; + }; }; };
On Fri, 3 Jun 2022 10:26:08 +0100, Peter Robinson pbrobinson@gmail.com wrote:
This adds the entry for V3D for bcm2711 (used in the Raspberry Pi 4) and the associated firmware clock entry.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks! -- Florian
BCM2711, the SoC used on the Raspberry Pi 4 has a different 3D render GPU IP than its predecessors. Enable it it on multi v7 and bcm2835 configs.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Stefan Wahren stefan.wahren@i2se.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com --- Changes since v4: - Added to bcm2835_defconfig
arch/arm/configs/bcm2835_defconfig | 1 + arch/arm/configs/multi_v7_defconfig | 1 + 2 files changed, 2 insertions(+)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig index a9ed79b7f871..9270512c14ea 100644 --- a/arch/arm/configs/bcm2835_defconfig +++ b/arch/arm/configs/bcm2835_defconfig @@ -106,6 +106,7 @@ CONFIG_REGULATOR_GPIO=y CONFIG_MEDIA_SUPPORT=y CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_DRM=y +CONFIG_DRM_V3D=y CONFIG_DRM_VC4=y CONFIG_FB_SIMPLE=y CONFIG_FRAMEBUFFER_CONSOLE=y diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index d6a6811f0539..e2db5cdc66b7 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -731,6 +731,7 @@ CONFIG_DRM_IMX_PARALLEL_DISPLAY=m CONFIG_DRM_IMX_TVE=m CONFIG_DRM_IMX_LDB=m CONFIG_DRM_IMX_HDMI=m +CONFIG_DRM_V3D=m CONFIG_DRM_VC4=m CONFIG_DRM_ETNAVIV=m CONFIG_DRM_MXSFB=m
On Fri, 3 Jun 2022 10:26:09 +0100, Peter Robinson pbrobinson@gmail.com wrote:
BCM2711, the SoC used on the Raspberry Pi 4 has a different 3D render GPU IP than its predecessors. Enable it it on multi v7 and bcm2835 configs.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Stefan Wahren stefan.wahren@i2se.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Applied to https://github.com/Broadcom/stblinux/commits/defconfig/next, thanks! -- Florian
From: Nicolas Saenz Julienne nsaenzjulienne@suse.de
BCM2711, the SoC used on the Raspberry Pi 4 has a different GPU than its predecessors. Enable it.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Stefan Wahren stefan.wahren@i2se.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 50aa3d75ab4f..446bac1ef774 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -738,6 +738,7 @@ CONFIG_DRM_I2C_ADV7511_AUDIO=y CONFIG_DRM_DW_HDMI_AHB_AUDIO=m CONFIG_DRM_DW_HDMI_CEC=m CONFIG_DRM_IMX_DCSS=m +CONFIG_DRM_V3D=m CONFIG_DRM_VC4=m CONFIG_DRM_ETNAVIV=m CONFIG_DRM_HISI_HIBMC=m
On Fri, 3 Jun 2022 10:26:10 +0100, Peter Robinson pbrobinson@gmail.com wrote:
From: Nicolas Saenz Julienne nsaenzjulienne@suse.de
BCM2711, the SoC used on the Raspberry Pi 4 has a different GPU than its predecessors. Enable it.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de Signed-off-by: Peter Robinson pbrobinson@gmail.com Reviewed-by: Stefan Wahren stefan.wahren@i2se.com Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Applied to https://github.com/Broadcom/stblinux/commits/devicetree-arm64/next, thanks! -- Florian
On 6/3/2022 11:26 AM, Peter Robinson wrote:
This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4.
I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing.
Changes since v5:
- Update the DT compatible to match the others that were updated
- Adjust the Kconfig help text
- Add review tags
Changes since v4:
- Fixes for device tree and bindings
- Split out the power management changes into an independent set
- Rebase to 5.18
- Individual changes in patches
I can take the last 3 patches through the Broadcom ARM SoC pull request, but the first three should probably go via the DRM tree unless you want me to merge them all?
Hello Florian,
On 6/8/22 11:26, Florian Fainelli wrote:
On 6/3/2022 11:26 AM, Peter Robinson wrote:
This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4.
I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing.
Changes since v5:
- Update the DT compatible to match the others that were updated
- Adjust the Kconfig help text
- Add review tags
Changes since v4:
- Fixes for device tree and bindings
- Split out the power management changes into an independent set
- Rebase to 5.18
- Individual changes in patches
I can take the last 3 patches through the Broadcom ARM SoC pull request, but the first three should probably go via the DRM tree unless you want me to merge them all?
I can merge the first 3 patches through the drm-misc tree. Can I get an ack from you for those ?
The changes are independent so there's no need for an immutable branch or any kind of cross tree coordination.
On 06/08, Javier Martinez Canillas wrote:
Hello Florian,
On 6/8/22 11:26, Florian Fainelli wrote:
On 6/3/2022 11:26 AM, Peter Robinson wrote:
This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4.
I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing.
Changes since v5:
- Update the DT compatible to match the others that were updated
- Adjust the Kconfig help text
- Add review tags
Changes since v4:
- Fixes for device tree and bindings
- Split out the power management changes into an independent set
- Rebase to 5.18
- Individual changes in patches
I can take the last 3 patches through the Broadcom ARM SoC pull request, but the first three should probably go via the DRM tree unless you want me to merge them all?
I can merge the first 3 patches through the drm-misc tree. Can I get an ack from you for those ?
The changes are independent so there's no need for an immutable branch or any kind of cross tree coordination.
Hi Javier,
I'm not sure if you're suggesting here to apply the entire series as it is now.
I'm not able to have a functional kernel from arm defconfig, only for arm64. I'd like to have this issue clarified before merge this serie. I tried multi_v7_defconfig on raspbian 32-bits and got a kernel panic. Things work better when using downstream bcm2711_defconfig.
If you have an idea of what is going on, please, let me know. I can try again and I'll be okay on merging it. Otherwise, let's wait for more inputs to have a better picture of the situation.
Thanks,
Melissa
-- Best regards,
Javier Martinez Canillas Linux Engineering Red Hat
Hello Melissa,
On 6/8/22 17:51, Melissa Wen wrote:
[snip]
I can take the last 3 patches through the Broadcom ARM SoC pull request, but the first three should probably go via the DRM tree unless you want me to merge them all?
I can merge the first 3 patches through the drm-misc tree. Can I get an ack from you for those ?
The changes are independent so there's no need for an immutable branch or any kind of cross tree coordination.
Hi Javier,
I'm not sure if you're suggesting here to apply the entire series as it is now.
No. I suggested that could just apply the first 3 patches that were related to DRM, not the last 3 three since Florian will pick those.
I'm not able to have a functional kernel from arm defconfig, only for arm64. I'd like to have this issue clarified before merge this serie. I tried multi_v7_defconfig on raspbian 32-bits and got a kernel panic. Things work better when using downstream bcm2711_defconfig.
If you have an idea of what is going on, please, let me know. I can try
Can you please share for info? For example your boot log when it panics, maybe that could shed some light on what's going on.
again and I'll be okay on merging it. Otherwise, let's wait for more inputs to have a better picture of the situation.
Of course I don't plan to push patches that are known to cause issues.
I mentioned that could help merging the DRM changes if needed before you sent your bug report.
On 06/08, Javier Martinez Canillas wrote:
Hello Melissa,
On 6/8/22 17:51, Melissa Wen wrote:
[snip]
I can take the last 3 patches through the Broadcom ARM SoC pull request, but the first three should probably go via the DRM tree unless you want me to merge them all?
I can merge the first 3 patches through the drm-misc tree. Can I get an ack from you for those ?
The changes are independent so there's no need for an immutable branch or any kind of cross tree coordination.
Hi Javier,
I'm not sure if you're suggesting here to apply the entire series as it is now.
No. I suggested that could just apply the first 3 patches that were related to DRM, not the last 3 three since Florian will pick those.
I'm not able to have a functional kernel from arm defconfig, only for arm64. I'd like to have this issue clarified before merge this serie. I tried multi_v7_defconfig on raspbian 32-bits and got a kernel panic. Things work better when using downstream bcm2711_defconfig.
If you have an idea of what is going on, please, let me know. I can try
Can you please share for info? For example your boot log when it panics, maybe that could shed some light on what's going on.
again and I'll be okay on merging it. Otherwise, let's wait for more inputs to have a better picture of the situation.
Of course I don't plan to push patches that are known to cause issues.
I mentioned that could help merging the DRM changes if needed before you sent your bug report.
Hi Javier,
Thanks for waiting a little.
Stefan guided me to the missing part and I'm okay on this serie.
If there's any r-b missing for drm/v3d, you can add mine: Reviewed-by: Melissa Wen mwen@igalia.com
But if you prefer that I applied them, just let me know.
Best Regards,
Melissa
-- Best regards,
Javier Martinez Canillas Linux Engineering Red Hat
Hello Melissa,
On 6/10/22 13:05, Melissa Wen wrote:
On 06/08, Javier Martinez Canillas wrote:
[snip]
Hi Javier,
Thanks for waiting a little.
Stefan guided me to the missing part and I'm okay on this serie.
No worries and thanks for the testing.
If there's any r-b missing for drm/v3d, you can add mine: Reviewed-by: Melissa Wen mwen@igalia.com
But if you prefer that I applied them, just let me know.
If you can apply them that's even better since you are more involved with this driver. I was just trying to be helpful and that's why I volunteered to push, to prevent this effort to get stalled :)
On 06/10, Javier Martinez Canillas wrote:
Hello Melissa,
On 6/10/22 13:05, Melissa Wen wrote:
On 06/08, Javier Martinez Canillas wrote:
[snip]
Hi Javier,
Thanks for waiting a little.
Stefan guided me to the missing part and I'm okay on this serie.
No worries and thanks for the testing.
If there's any r-b missing for drm/v3d, you can add mine: Reviewed-by: Melissa Wen mwen@igalia.com
But if you prefer that I applied them, just let me know.
If you can apply them that's even better since you are more involved with this driver. I was just trying to be helpful and that's why I volunteered to push, to prevent this effort to get stalled :)
Hi all,
I applied the first three patches to drm-misc-next yesterday.
Thanks,
Melissa
-- Best regards,
Javier Martinez Canillas Linux Engineering Red Hat
On 06/03, Peter Robinson wrote:
This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4.
Hi Peter,
I was able to check and run some tests on arm64, and it seems ok. But I was not successful on bringing it up for arm using multi_v7_defconfig + device_tree=bcm2711-rpi-4-b.dtb.
How can I check this path?
Btw, using the config from rpi downstream kernel works nicely for arm (on my side)
Best regards,
Melissa
I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing.
Changes since v5:
- Update the DT compatible to match the others that were updated
- Adjust the Kconfig help text
- Add review tags
Changes since v4:
- Fixes for device tree and bindings
- Split out the power management changes into an independent set
- Rebase to 5.18
- Individual changes in patches
[1] https://www.spinics.net/lists/arm-kernel/msg980342.html
Nicolas Saenz Julienne (1): arm64: config: Enable DRM_V3D
Peter Robinson (5): dt-bindings: gpu: v3d: Add BCM2711's compatible drm/v3d: Get rid of pm code drm/v3d: Add support for bcm2711 ARM: dts: bcm2711: Enable V3D ARM: configs: Enable DRM_V3D
.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 + arch/arm/boot/dts/bcm2711-rpi.dtsi | 4 ++++ arch/arm/boot/dts/bcm2711.dtsi | 11 +++++++++++ arch/arm/configs/bcm2835_defconfig | 1 + arch/arm/configs/multi_v7_defconfig | 1 + arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/v3d/Kconfig | 5 +++-- drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +----------------- drivers/gpu/drm/v3d/v3d_drv.c | 12 +----------- drivers/gpu/drm/v3d/v3d_gem.c | 12 +----------- 10 files changed, 25 insertions(+), 41 deletions(-)
-- 2.36.1
Hi Melissa,
Am 08.06.22 um 14:51 schrieb Melissa Wen:
On 06/03, Peter Robinson wrote:
This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4.
Hi Peter,
I was able to check and run some tests on arm64, and it seems ok. But I was not successful on bringing it up for arm using multi_v7_defconfig + device_tree=bcm2711-rpi-4-b.dtb.
for Raspberry Pi 4 you also need to enable CONFIG_ARM_LPAE, which is not enabled in multi_v7_defconfig.
Best regards
How can I check this path?
Btw, using the config from rpi downstream kernel works nicely for arm (on my side)
Best regards,
Melissa
I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing.
Changes since v5:
- Update the DT compatible to match the others that were updated
- Adjust the Kconfig help text
- Add review tags
Changes since v4:
- Fixes for device tree and bindings
- Split out the power management changes into an independent set
- Rebase to 5.18
- Individual changes in patches
[1] https://www.spinics.net/lists/arm-kernel/msg980342.html
Nicolas Saenz Julienne (1): arm64: config: Enable DRM_V3D
Peter Robinson (5): dt-bindings: gpu: v3d: Add BCM2711's compatible drm/v3d: Get rid of pm code drm/v3d: Add support for bcm2711 ARM: dts: bcm2711: Enable V3D ARM: configs: Enable DRM_V3D
.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 + arch/arm/boot/dts/bcm2711-rpi.dtsi | 4 ++++ arch/arm/boot/dts/bcm2711.dtsi | 11 +++++++++++ arch/arm/configs/bcm2835_defconfig | 1 + arch/arm/configs/multi_v7_defconfig | 1 + arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/v3d/Kconfig | 5 +++-- drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +----------------- drivers/gpu/drm/v3d/v3d_drv.c | 12 +----------- drivers/gpu/drm/v3d/v3d_gem.c | 12 +----------- 10 files changed, 25 insertions(+), 41 deletions(-)
-- 2.36.1
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 06/09, Stefan Wahren wrote:
Hi Melissa,
Am 08.06.22 um 14:51 schrieb Melissa Wen:
On 06/03, Peter Robinson wrote:
This is a follow up from my v4 patchset. The power management pieces have been split out to a separate independent set of patches by Stefan [1]. This version 5 of the DRM patches are independent and given the V3D driver has been upstream for some time the two patches to enable it in defconfigs can be taken at anytime independent of the enablement for the Raspberry Pi 4.
Hi Peter,
I was able to check and run some tests on arm64, and it seems ok. But I was not successful on bringing it up for arm using multi_v7_defconfig + device_tree=bcm2711-rpi-4-b.dtb.
for Raspberry Pi 4 you also need to enable CONFIG_ARM_LPAE, which is not enabled in multi_v7_defconfig.
Hi Stefan,
Thanks for pointing it out.
I've checked again and it's fine. I think some bits are missing (maybe from my side) to handle glx stuff on arm, but I can take a look later.
Thanks for this work!
Melissa
Best regards
How can I check this path?
Btw, using the config from rpi downstream kernel works nicely for arm (on my side)
Best regards,
Melissa
I've tested this using mesa 22.0.x and Wayland/Gnome on Fedora 36, it's more or less stable with basic testing.
Changes since v5:
- Update the DT compatible to match the others that were updated
- Adjust the Kconfig help text
- Add review tags
Changes since v4:
- Fixes for device tree and bindings
- Split out the power management changes into an independent set
- Rebase to 5.18
- Individual changes in patches
[1] https://www.spinics.net/lists/arm-kernel/msg980342.html
Nicolas Saenz Julienne (1): arm64: config: Enable DRM_V3D
Peter Robinson (5): dt-bindings: gpu: v3d: Add BCM2711's compatible drm/v3d: Get rid of pm code drm/v3d: Add support for bcm2711 ARM: dts: bcm2711: Enable V3D ARM: configs: Enable DRM_V3D
.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 + arch/arm/boot/dts/bcm2711-rpi.dtsi | 4 ++++ arch/arm/boot/dts/bcm2711.dtsi | 11 +++++++++++ arch/arm/configs/bcm2835_defconfig | 1 + arch/arm/configs/multi_v7_defconfig | 1 + arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/v3d/Kconfig | 5 +++-- drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +----------------- drivers/gpu/drm/v3d/v3d_drv.c | 12 +----------- drivers/gpu/drm/v3d/v3d_gem.c | 12 +----------- 10 files changed, 25 insertions(+), 41 deletions(-)
-- 2.36.1
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
dri-devel@lists.freedesktop.org
-
Florian Fainelli -
Javier Martinez Canillas -
Melissa Wen -
Peter Robinson -
Stefan Wahren