Hi,
On 03.07.19 17:11, Peter Robinson wrote:
On Wed, Jul 3, 2019 at 3:14 PM Stefan Wahren
<stefan.wahren(a)i2se.com> wrote:
> Hi Peter,
>
> 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
> this driver.
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.
there is small progress on this issue. I was able to reproduce this
issue on my RPi 3B+. More details here [1]. So from my POV this is
definitely a driver issue.
Since Eric doesn't work for Broadcom anymore and the Raspberry Pi
Trading isn't able to provide more information about this, i plan to revert
e1dc2b2e1bef7237fd8fc055fe1ec2a6ff001f91 ARM: bcm283x: Switch V3D over
to using the PM driver instead of firmware.
with the release of Linux 5.4-rc1.
Best regards
Stefan
[1] -
https://github.com/raspberrypi/linux/issues/3046