On Wed, Jul 3, 2019 at 3:14 PM Stefan Wahren <stefan.wahren(a)i2se.com> wrote:
On 03.07.19 14:10, Peter Robinson wrote:
> Hi Stefan,
>>> loads but I don't get an error, just:
>>> bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
>>> That's a minimal text only image, display attached but just at a linux
>>> console login.
>> Could you please so kind and make an ASCII table for the bad cases with
>> the following columns Raspberry Pi type, kernel, DTB, firmware and add
>> them to the github issue?
> Sorry, I've not had time to do all that testing across the matrix of
> devices, it will take some time and I have around 10 days of travel
> starting on Thursday.
> The first test I did do was one of my regular desktop testing devices
> which has consistently had the issue I did some testing. It's an
> original RPi 3B with Fedora 30 Workstation (GNOME).
> v5.2-rc7 - fails with the following errors, interesting no messages
> about vc4 driver at all.
> [ 6.791023] bcm2835-power bcm2835-power: Broadcom BCM2835 power
> domains driver
> [ 32.891912] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
> [ 32.937340] bcm2835-power bcm2835-power: Timeout waiting for grafx power OK
could you please provide the RPi firmware version from dmesg?
"2019-03-27 15:48" (git commit 9fd387c)
> I then did a build, same kernel as above but with the bcm2835-power
> driver disabled:
> # CONFIG_BCM2835_POWER is not set
> No mention of bcm2835-power (as expected), and just this error from vc4:
> [ 30.873633] vc4_v3d 3fc00000.v3d: ignoring dependency for device,
> assuming no driver
> Then with the same kernel as the last test (v5.2-rc7 bcm2835-power
> disabled) plus the following two DT patches reverted:
> e1dc2b2e1bef7237fd8fc055fe1ec2a6ff001f91 ARM: bcm283x: Switch V3D over
> to using the PM driver instead of firmware.
> 81fc035f07d230c0f687ef09d5ecf2c885dba8ae ARM: bcm283x: Extend the WDT
> DT node out to cover the whole PM block. (v4)
Yes, reverting those patches is the last option. But i only want go this
way, in case the new bcm2835 is really broken. Btw the RPi 4 relies on
I'm considering reverting them for our stable releases (so 5.1.x
kernel) so users can get back to working devices, and I can stop the
deluge of support queries, and then we can debug this on 5.2. Are you
OK with that?
If figured it would be required for RPi4, but that's a different DT
anyway, and a little while off.
Since not all RPis are affected, it isn't clear to me what causes
timeouts (timing, hardware tolerances, power supply, firmware version,
We've been on that one firmware for all of F-30, the upstream releases
slowed (no doubt due to an upstream focus on the RPi4) and there was
nothing really worth us moving to anything newer.
> Let me know what else I can assist with and I'll en-devour
to get it
> done before I leave for travel.
> BTW what's the status of this slightly related patch going upstream
> (we did pull it in locally):
Apologize, i missed to add a Fixes tag. Except from this the patch has
been applied and will be in Linux 5.3:
No issues, just wanted to make sure it wasn't lost.
> But i don't know why this branch isn't merged into linux-next.
> Best regards