| Message ID | 20220603092610.1909675-1-pbrobinson@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Raspberry PI 4 V3D enablement | expand |
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 > > [1] https://www.spinics.net/lists/arm-kernel/msg980342.html 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 >> >> [1] https://www.spinics.net/lists/arm-kernel/msg980342.html > > 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/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 >
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 > >> > >> [1] https://www.spinics.net/lists/arm-kernel/msg980342.html > > > > 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.
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
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 >