On Wed, Jul 3, 2019 at 3:14 PM Stefan Wahren <stefan.wahren@xxxxxxxx> 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. > Since not all RPis are affected, it isn't clear to me what causes these > timeouts (timing, hardware tolerances, power supply, firmware version, > overclocking configuration). 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. > > > > Peter > > > > BTW what's the status of this slightly related patch going upstream > > (we did pull it in locally): > > https://patchwork.kernel.org/patch/10945031/ > > 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. > https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=watchdog-next&id=ff7d6b7a98c7d402a17085ae0c6d780ee3bae841 > > But i don't know why this branch isn't merged into linux-next. > > Best regards > Stefan > _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
