[PATCH] Revert "ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware."
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net --- arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 ++++ arch/arm/boot/dts/bcm283x.dtsi | 4 +--- 2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi index 6c6a7f6..b909e3b 100644 --- a/arch/arm/boot/dts/bcm2835-rpi.dtsi +++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi @@ -67,6 +67,10 @@ power-domains = <&power RPI_POWER_DOMAIN_USB>; };
+&v3d { + power-domains = <&power RPI_POWER_DOMAIN_V3D>; +}; + &vec { power-domains = <&power RPI_POWER_DOMAIN_VEC>; status = "okay"; diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi index 2d191fc..b238567 100644 --- a/arch/arm/boot/dts/bcm283x.dtsi +++ b/arch/arm/boot/dts/bcm283x.dtsi @@ -3,7 +3,6 @@ #include <dt-bindings/clock/bcm2835-aux.h> #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> -#include <dt-bindings/soc/bcm2835-pm.h>
/* firmware-provided startup stubs live here, where the secondary CPUs are * spinning. @@ -121,7 +120,7 @@ #interrupt-cells = <2>; };
- pm: watchdog@7e100000 { + watchdog@7e100000 { compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt"; #power-domain-cells = <1>; #reset-cells = <1>; @@ -641,7 +640,6 @@ compatible = "brcm,bcm2835-v3d"; reg = <0x7ec00000 0x1000>; interrupts = <1 10>; - power-domains = <&pm BCM2835_POWER_DOMAIN_GRAFX_V3D>; };
vc4: gpu { -- 2.7.4
Stefan Wahren wahrenst@gmx.net writes:
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net
Acked-by: Eric Anholt eric@anholt.net
I wish someone with firmware source had the time to look into why using open source drivers to drive this hardware was failing, but I don't have that time or code any more.
On 9/8/19 8:44 AM, Stefan Wahren wrote:
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net
Do you want me to pick up this change directly, or would you want to issue a pull request for 5.4-rcX with other fixes?
Hi Florian,
Am 20.09.19 um 19:52 schrieb Florian Fainelli:
On 9/8/19 8:44 AM, Stefan Wahren wrote:
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net
Do you want me to pick up this change directly, or would you want to issue a pull request for 5.4-rcX with other fixes?
there aren't any other fixes, please pick up this directly.
Thanks
Stefan
On 9/8/2019 8:44 AM, Stefan Wahren wrote:
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net
Applied to devicetree/fixes, thanks!
Hi Florian,
Am 23.09.19 um 20:56 schrieb Florian Fainelli:
On 9/8/2019 8:44 AM, Stefan Wahren wrote:
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net
Applied to devicetree/fixes, thanks!
i noticed that X hangs with recent Raspbian and Linux 5.4-rc2 after this revert has been applied.
Is there a chance to drop the revert?
Stefan
On 10/9/19 2:33 PM, Stefan Wahren wrote:
Hi Florian,
Am 23.09.19 um 20:56 schrieb Florian Fainelli:
On 9/8/2019 8:44 AM, Stefan Wahren wrote:
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net
Applied to devicetree/fixes, thanks!
i noticed that X hangs with recent Raspbian and Linux 5.4-rc2 after this revert has been applied.
Is there a chance to drop the revert?
I have not sent anything yet as I wanted to get some testing done on other platforms, so yes, I can definitively drop that particular changes from devicetree/fixes and not send it for a 5.4-rc3 pull request. Does that work for you?
On 09.10.19 23:42, Florian Fainelli wrote:
On 10/9/19 2:33 PM, Stefan Wahren wrote:
Hi Florian,
Am 23.09.19 um 20:56 schrieb Florian Fainelli:
On 9/8/2019 8:44 AM, Stefan Wahren wrote:
Since release of the new BCM2835 PM driver there has been several reports of V3D probing issues. This is caused by timeouts during powering-up the GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting force_turbo=1 in the firmware configuration. Since there are no issues using the firmware PM driver with the same setup, there must be an issue in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause since June (mostly in the lack of documentation), so i decided to switch back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046 Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware.") Cc: stable@vger.kernel.org Signed-off-by: Stefan Wahren wahrenst@gmx.net
Applied to devicetree/fixes, thanks!
i noticed that X hangs with recent Raspbian and Linux 5.4-rc2 after this revert has been applied.
Is there a chance to drop the revert?
I have not sent anything yet as I wanted to get some testing done on other platforms, so yes, I can definitively drop that particular changes from devicetree/fixes and not send it for a 5.4-rc3 pull request. Does that work for you?
Yes, definitely
Thanks Stefan
dri-devel@lists.freedesktop.org
-
Eric Anholt -
Florian Fainelli -
Stefan Wahren -
Stefan Wahren