Hi Lucas,
Given that I'm not having a great success at reproducing the issue you mentioned, could you test the following patches to see if it improves things?
Thanks! Maxime
Maxime Ripard (2): ARM: dts: bcm2711: Fix the HVS size drm/vc4: hvs: Clear the HVS list at boot
arch/arm/boot/dts/bcm2711.dtsi | 1 + drivers/gpu/drm/vc4/vc4_drv.c | 1 + drivers/gpu/drm/vc4/vc4_drv.h | 1 + drivers/gpu/drm/vc4/vc4_hvs.c | 12 ++++++++++++ 4 files changed, 15 insertions(+)
The BCM2711 has a larger HVS size than the earlier SoCs.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- arch/arm/boot/dts/bcm2711.dtsi | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi index 4847dd305317..5254c63fbf8f 100644 --- a/arch/arm/boot/dts/bcm2711.dtsi +++ b/arch/arm/boot/dts/bcm2711.dtsi @@ -290,6 +290,7 @@ pixelvalve4: pixelvalve@7e216000 {
hvs: hvs@7e400000 { compatible = "brcm,bcm2711-hvs"; + reg = <0x7e400000 0x8000>; interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; };
The kernel boots with the display running and we make sure to shut down the scan out engines properly but we keep the display list for now. Let's make sure we start from a clean state.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + drivers/gpu/drm/vc4/vc4_drv.h | 1 + drivers/gpu/drm/vc4/vc4_hvs.c | 12 ++++++++++++ 3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index 2cd97a39c286..9fbf03872b24 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -289,6 +289,7 @@ static int vc4_drm_bind(struct device *dev)
drm_for_each_crtc(crtc, drm) vc4_crtc_disable_at_boot(crtc); + vc4_hvs_clear_dlist(drm);
ret = drm_dev_register(drm, 0); if (ret < 0) diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h index 051ad4e31e52..493a85c4d11a 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.h +++ b/drivers/gpu/drm/vc4/vc4_drv.h @@ -911,6 +911,7 @@ void vc4_irq_reset(struct drm_device *dev);
/* vc4_hvs.c */ extern struct platform_driver vc4_hvs_driver; +void vc4_hvs_clear_dlist(struct drm_device *dev); void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output); int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output); int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_atomic_state *state); diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c index 2b3a597fa65f..1fe40f3cbcfb 100644 --- a/drivers/gpu/drm/vc4/vc4_hvs.c +++ b/drivers/gpu/drm/vc4/vc4_hvs.c @@ -326,6 +326,18 @@ void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int chan) SCALER_DISPSTATX_EMPTY); }
+void vc4_hvs_clear_dlist(struct drm_device *dev) +{ + struct vc4_dev *vc4 = to_vc4_dev(dev); + void __iomem *dlist_start = vc4->hvs->dlist; + unsigned int i; + + for (i = 0; i < 0x4000; i += 4) + writel(SCALER_CTL0_END, dlist_start + i); + + vc4_hvs_dump_state(dev); +} + int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
Hi Maxime,
On 12/01/21 at 14:47 +0100, Maxime Ripard wrote:
Hi Lucas,
Given that I'm not having a great success at reproducing the issue you mentioned, could you test the following patches to see if it improves things?
Unfortunately I'm missing a cable and will only get it back during the week-end, so I cannot test before early next week. However I'm Ccing Ryutaroh Matsumoto who could also reproduce it. Maybe he is in a better position to test this (@Ryutaroh: I bounced the patches to you).
Lucas
Hi Lucas,
week-end, so I cannot test before early next week. However I'm Ccing Ryutaroh Matsumoto who could also reproduce it. Maybe he is in a better position to test this (@Ryutaroh: I bounced the patches to you).
Should I apply PATCH RFT 0--2/2 to https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.7.tar.xz or some branch of someone's git repo?
On my Raspberry Pi 4B 8GB model, all versioins up to upstream 5.10.6 fail to boot on USB MSD due to changes to the USB handling by raspi introduced in 5.10 series, and failed to boot from an SD card up to 5.10.3 or so. No working WiFi connections neither on my raspi 4b.
I am unsure if I can test the patch reliably. But I will try it within a few days.
Best regards, Ryutaroh
Hi Ryutaroh, Lucas,
On Wed, Jan 13, 2021 at 09:51:59AM +0900, Ryutaroh Matsumoto wrote:
Hi Lucas,
week-end, so I cannot test before early next week. However I'm Ccing Ryutaroh Matsumoto who could also reproduce it. Maybe he is in a better position to test this (@Ryutaroh: I bounced the patches to you).
Should I apply PATCH RFT 0--2/2 to https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.7.tar.xz or some branch of someone's git repo?
On my Raspberry Pi 4B 8GB model, all versioins up to upstream 5.10.6 fail to boot on USB MSD due to changes to the USB handling by raspi introduced in 5.10 series, and failed to boot from an SD card up to 5.10.3 or so. No working WiFi connections neither on my raspi 4b.
I am unsure if I can test the patch reliably. But I will try it within a few days.
We just had another lead on this one and that patch doesn't seem to prove useful to fix it, so it's probably better to hold off the testing at this point
Thanks! Maxime
dri-devel@lists.freedesktop.org
-
Lucas Nussbaum -
Maxime Ripard -
Ryutaroh Matsumoto