Message ID | 20240412132559.2365947-1-mcanal@igalia.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | ARM: dts: bcm2835: Enable 3D rendering through V3D | expand |
On 12/04/2024 15:25, Maíra Canal wrote: > RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to > the RPi. Currently, the downstream kernel uses an overlay to enable the > GPU and use GPU hardware acceleration. When deploying a mainline kernel > to the RPi 0-3, we end up without any GPU hardware acceleration > (essentially, we can't use the OpenGL driver). > > Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. > > Signed-off-by: Maíra Canal <mcanal@igalia.com> > --- > > I decided to add the status property to the `bcm2835-common.dtsi`, but > there are two other options: > > 1. To add the status property to the `bcm2835-rpi-common.dtsi` file > 2. To add the status property to each individual RPi model, e.g. > `bcm2837-rpi-3-b.dts`. > > Let me know which option is more suitable, and if `bcm2835-common.dtsi` > is not the best option, I can send a v2. > > Best Regards, > - Maíra > > arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > index 9261b67dbee1..851a6bce1939 100644 > --- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > +++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > @@ -139,6 +139,7 @@ v3d: v3d@7ec00000 { > compatible = "brcm,bcm2835-v3d"; > reg = <0x7ec00000 0x1000>; > interrupts = <1 10>; > + status = "okay"; Please point me where this is being disabled? Could not find. Anyway, enabling should be done in last place of override/extend, which provides additional properties. I believe it is being extend further, so that's not the place. Best regards, Krzysztof
Hi Maíra, [add Phil & Dave] Am 12.04.24 um 15:25 schrieb Maíra Canal: > RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to > the RPi. Currently, the downstream kernel uses an overlay to enable the > GPU and use GPU hardware acceleration. When deploying a mainline kernel > to the RPi 0-3, we end up without any GPU hardware acceleration > (essentially, we can't use the OpenGL driver). > > Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. thanks for trying to improve the combination Raspberry Pi OS + Mainline Kernel. I think i'm able to reproduce the issue with Raspberry Pi 3 B + on Buster. From the kernel side everything looks good: [ 11.054833] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [ 11.055118] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [ 11.055340] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) [ 11.055521] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 11.055695] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 11.055874] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 11.056020] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 11.063277] Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.raspberrypi,3-model-b-plus.hcd' Patch [ 11.070466] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 11.174803] Console: switching to colour frame buffer device 240x75 [ 11.205125] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device But in Raspberry Pi OS there is a systemd script which is trying to check for the V3D driver /usr/lib/systemd/scripts/gldriver_test.sh Within the first check "raspi-config nonint is_kms" is called, which always seems to fail. If i run strace on this command it seems to check for /proc/device-tree/soc/v3d@7ec00000/status which doesn't exists in the Mainline device tree. Maybe there is a chance to improve the userspace tool? > > Signed-off-by: Maíra Canal <mcanal@igalia.com> > --- > > I decided to add the status property to the `bcm2835-common.dtsi`, but > there are two other options: > > 1. To add the status property to the `bcm2835-rpi-common.dtsi` file > 2. To add the status property to each individual RPi model, e.g. > `bcm2837-rpi-3-b.dts`. > > Let me know which option is more suitable, and if `bcm2835-common.dtsi` > is not the best option, I can send a v2. > > Best Regards, > - Maíra > > arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > index 9261b67dbee1..851a6bce1939 100644 > --- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > +++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > @@ -139,6 +139,7 @@ v3d: v3d@7ec00000 { > compatible = "brcm,bcm2835-v3d"; > reg = <0x7ec00000 0x1000>; > interrupts = <1 10>; > + status = "okay"; > }; > > vc4: gpu {
Hello all, On Fri, 12 Apr 2024 at 18:17, Stefan Wahren <wahrenst@gmx.net> wrote: > > Hi Maíra, > > [add Phil & Dave] > > Am 12.04.24 um 15:25 schrieb Maíra Canal: > > RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to > > the RPi. Currently, the downstream kernel uses an overlay to enable the > > GPU and use GPU hardware acceleration. When deploying a mainline kernel > > to the RPi 0-3, we end up without any GPU hardware acceleration > > (essentially, we can't use the OpenGL driver). > > > > Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. > thanks for trying to improve the combination Raspberry Pi OS + Mainline > Kernel. I think i'm able to reproduce the issue with Raspberry Pi 3 B + > on Buster. Buster? We launched Buster with 4.19 and ended on 5.10. We've moved onto Bookworm now. A lot has changed in that time... > From the kernel side everything looks good: > > [ 11.054833] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) > [ 11.055118] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) > [ 11.055340] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) > [ 11.055521] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops > vc4_crtc_ops [vc4]) > [ 11.055695] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops > vc4_crtc_ops [vc4]) > [ 11.055874] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops > vc4_crtc_ops [vc4]) > [ 11.056020] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) > [ 11.063277] Bluetooth: hci0: BCM4345C0 > 'brcm/BCM4345C0.raspberrypi,3-model-b-plus.hcd' Patch > [ 11.070466] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 > [ 11.174803] Console: switching to colour frame buffer device 240x75 > [ 11.205125] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device > > But in Raspberry Pi OS there is a systemd script which is trying to > check for the V3D driver /usr/lib/systemd/scripts/gldriver_test.sh > Within the first check "raspi-config nonint is_kms" is called, which > always seems to fail. If i run strace on this command it seems to check > for /proc/device-tree/soc/v3d@7ec00000/status which doesn't exists in > the Mainline device tree. > > Maybe there is a chance to improve the userspace tool? ...such as the raspi-config tool, which now always succeeds for is_kms. Phil > > > > Signed-off-by: Maíra Canal <mcanal@igalia.com> > > --- > > > > I decided to add the status property to the `bcm2835-common.dtsi`, but > > there are two other options: > > > > 1. To add the status property to the `bcm2835-rpi-common.dtsi` file > > 2. To add the status property to each individual RPi model, e.g. > > `bcm2837-rpi-3-b.dts`. > > > > Let me know which option is more suitable, and if `bcm2835-common.dtsi` > > is not the best option, I can send a v2. > > > > Best Regards, > > - Maíra > > > > arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > > index 9261b67dbee1..851a6bce1939 100644 > > --- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > > +++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi > > @@ -139,6 +139,7 @@ v3d: v3d@7ec00000 { > > compatible = "brcm,bcm2835-v3d"; > > reg = <0x7ec00000 0x1000>; > > interrupts = <1 10>; > > + status = "okay"; > > }; > > > > vc4: gpu { >
Hi Phil, Am 14.04.24 um 20:43 schrieb Phil Elwell: > Hello all, > > On Fri, 12 Apr 2024 at 18:17, Stefan Wahren <wahrenst@gmx.net> wrote: >> Hi Maíra, >> >> [add Phil & Dave] >> >> Am 12.04.24 um 15:25 schrieb Maíra Canal: >>> RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to >>> the RPi. Currently, the downstream kernel uses an overlay to enable the >>> GPU and use GPU hardware acceleration. When deploying a mainline kernel >>> to the RPi 0-3, we end up without any GPU hardware acceleration >>> (essentially, we can't use the OpenGL driver). >>> >>> Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. >> thanks for trying to improve the combination Raspberry Pi OS + Mainline >> Kernel. I think i'm able to reproduce the issue with Raspberry Pi 3 B + >> on Buster. > Buster? We launched Buster with 4.19 and ended on 5.10. We've moved > onto Bookworm now. A lot has changed in that time... Sorry, i meant Bullseye but yes it's not up to date. Anyway i cannot see a problem with the devicetree.
Hi Phil, On 4/14/24 15:43, Phil Elwell wrote: > Hello all, > > On Fri, 12 Apr 2024 at 18:17, Stefan Wahren <wahrenst@gmx.net> wrote: >> >> Hi Maíra, >> >> [add Phil & Dave] >> >> Am 12.04.24 um 15:25 schrieb Maíra Canal: >>> RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to >>> the RPi. Currently, the downstream kernel uses an overlay to enable the >>> GPU and use GPU hardware acceleration. When deploying a mainline kernel >>> to the RPi 0-3, we end up without any GPU hardware acceleration >>> (essentially, we can't use the OpenGL driver). >>> >>> Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. >> thanks for trying to improve the combination Raspberry Pi OS + Mainline >> Kernel. I think i'm able to reproduce the issue with Raspberry Pi 3 B + >> on Buster. > > Buster? We launched Buster with 4.19 and ended on 5.10. We've moved > onto Bookworm now. A lot has changed in that time... > >> From the kernel side everything looks good: >> >> [ 11.054833] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) >> [ 11.055118] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) >> [ 11.055340] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) >> [ 11.055521] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops >> vc4_crtc_ops [vc4]) >> [ 11.055695] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops >> vc4_crtc_ops [vc4]) >> [ 11.055874] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops >> vc4_crtc_ops [vc4]) >> [ 11.056020] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) >> [ 11.063277] Bluetooth: hci0: BCM4345C0 >> 'brcm/BCM4345C0.raspberrypi,3-model-b-plus.hcd' Patch >> [ 11.070466] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 >> [ 11.174803] Console: switching to colour frame buffer device 240x75 >> [ 11.205125] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device >> >> But in Raspberry Pi OS there is a systemd script which is trying to >> check for the V3D driver /usr/lib/systemd/scripts/gldriver_test.sh >> Within the first check "raspi-config nonint is_kms" is called, which >> always seems to fail. If i run strace on this command it seems to check >> for /proc/device-tree/soc/v3d@7ec00000/status which doesn't exists in >> the Mainline device tree. >> >> Maybe there is a chance to improve the userspace tool? > > ...such as the raspi-config tool, which now always succeeds for is_kms. > I'm using Raspberry Pi OS Bulleye with the raspi-config tool on version 20231012~bulleye. I can still reproduce this issue when using a upstream kernel. I ran `sudo apt upgrade`, but a new version of the raspi-config tool didn't appeared. Best Regards, - Maíra > Phil > >>> >>> Signed-off-by: Maíra Canal <mcanal@igalia.com> >>> --- >>> >>> I decided to add the status property to the `bcm2835-common.dtsi`, but >>> there are two other options: >>> >>> 1. To add the status property to the `bcm2835-rpi-common.dtsi` file >>> 2. To add the status property to each individual RPi model, e.g. >>> `bcm2837-rpi-3-b.dts`. >>> >>> Let me know which option is more suitable, and if `bcm2835-common.dtsi` >>> is not the best option, I can send a v2. >>> >>> Best Regards, >>> - Maíra >>> >>> arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi >>> index 9261b67dbee1..851a6bce1939 100644 >>> --- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi >>> +++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi >>> @@ -139,6 +139,7 @@ v3d: v3d@7ec00000 { >>> compatible = "brcm,bcm2835-v3d"; >>> reg = <0x7ec00000 0x1000>; >>> interrupts = <1 10>; >>> + status = "okay"; >>> }; >>> >>> vc4: gpu { >>
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi index 9261b67dbee1..851a6bce1939 100644 --- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi +++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi @@ -139,6 +139,7 @@ v3d: v3d@7ec00000 { compatible = "brcm,bcm2835-v3d"; reg = <0x7ec00000 0x1000>; interrupts = <1 10>; + status = "okay"; }; vc4: gpu {
RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to the RPi. Currently, the downstream kernel uses an overlay to enable the GPU and use GPU hardware acceleration. When deploying a mainline kernel to the RPi 0-3, we end up without any GPU hardware acceleration (essentially, we can't use the OpenGL driver). Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. Signed-off-by: Maíra Canal <mcanal@igalia.com> --- I decided to add the status property to the `bcm2835-common.dtsi`, but there are two other options: 1. To add the status property to the `bcm2835-rpi-common.dtsi` file 2. To add the status property to each individual RPi model, e.g. `bcm2837-rpi-3-b.dts`. Let me know which option is more suitable, and if `bcm2835-common.dtsi` is not the best option, I can send a v2. Best Regards, - Maíra arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 + 1 file changed, 1 insertion(+)