| Message ID | 20200303173217.3987-1-nsaenzjulienne@suse.de (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 3ac395a5b3f3b678663fbb58381fdae2b1b57588 |
| Headers | show |
| Series | ARM: dts: bcm283x: Use firmware PM driver for V3D | expand |
Hi Nicolas, Am 03.03.20 um 18:32 schrieb Nicolas Saenz Julienne: > The register based driver turned out to be unstable, specially on RPi3a+ > but not limited to it. While a fix is being worked on, we roll back to > using firmware based scheme. > > Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware") > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > --- > > See https://github.com/raspberrypi/linux/issues/3046 for more reference. > Note: I tested this on RPi3b, RPi3a+ and RPi2b. as i already wrote this prevent X to start on current Raspbian on my Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful here. I will take a look at the debug UART. Maybe there are more helpful information. Regards Stefan > > arch/arm/boot/dts/bcm2835-common.dtsi | 1 - > arch/arm/boot/dts/bcm2835-rpi-common.dtsi | 12 ++++++++++++ > arch/arm/boot/dts/bcm2835.dtsi | 1 + > arch/arm/boot/dts/bcm2836.dtsi | 1 + > arch/arm/boot/dts/bcm2837.dtsi | 1 + > 5 files changed, 15 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/bcm2835-rpi-common.dtsi > > diff --git a/arch/arm/boot/dts/bcm2835-common.dtsi b/arch/arm/boot/dts/bcm2835-common.dtsi > index 2b1d9d4c0cde..4119271c979d 100644 > --- a/arch/arm/boot/dts/bcm2835-common.dtsi > +++ b/arch/arm/boot/dts/bcm2835-common.dtsi > @@ -130,7 +130,6 @@ v3d: v3d@7ec00000 { > compatible = "brcm,bcm2835-v3d"; > reg = <0x7ec00000 0x1000>; > interrupts = <1 10>; > - power-domains = <&pm BCM2835_POWER_DOMAIN_GRAFX_V3D>; > }; > > vc4: gpu { > diff --git a/arch/arm/boot/dts/bcm2835-rpi-common.dtsi b/arch/arm/boot/dts/bcm2835-rpi-common.dtsi > new file mode 100644 > index 000000000000..b78a57534611 > --- /dev/null > +++ b/arch/arm/boot/dts/bcm2835-rpi-common.dtsi > @@ -0,0 +1,12 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * This include file covers the common peripherals and configuration between > + * bcm2835, bcm2836 and bcm2837 implementations that interact with RPi's > + * firmware interface. > + */ > + > +#include <dt-bindings/power/raspberrypi-power.h> > + > +&v3d { > + power-domains = <&power RPI_POWER_DOMAIN_V3D>; > +}; > diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi > index 53bf4579cc22..0549686134ea 100644 > --- a/arch/arm/boot/dts/bcm2835.dtsi > +++ b/arch/arm/boot/dts/bcm2835.dtsi > @@ -1,6 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0 > #include "bcm283x.dtsi" > #include "bcm2835-common.dtsi" > +#include "bcm2835-rpi-common.dtsi" > > / { > compatible = "brcm,bcm2835"; > diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi > index 82d6c4662ae4..b390006aef79 100644 > --- a/arch/arm/boot/dts/bcm2836.dtsi > +++ b/arch/arm/boot/dts/bcm2836.dtsi > @@ -1,6 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0 > #include "bcm283x.dtsi" > #include "bcm2835-common.dtsi" > +#include "bcm2835-rpi-common.dtsi" > > / { > compatible = "brcm,bcm2836"; > diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi > index 9e95fee78e19..0199ec98cd61 100644 > --- a/arch/arm/boot/dts/bcm2837.dtsi > +++ b/arch/arm/boot/dts/bcm2837.dtsi > @@ -1,5 +1,6 @@ > #include "bcm283x.dtsi" > #include "bcm2835-common.dtsi" > +#include "bcm2835-rpi-common.dtsi" > > / { > compatible = "brcm,bcm2837";
On Tue, 2020-03-03 at 19:17 +0100, Stefan Wahren wrote: > Hi Nicolas, > > Am 03.03.20 um 18:32 schrieb Nicolas Saenz Julienne: > > The register based driver turned out to be unstable, specially on RPi3a+ > > but not limited to it. While a fix is being worked on, we roll back to > > using firmware based scheme. > > > > Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver > > instead of firmware") > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > > --- > > > > See https://github.com/raspberrypi/linux/issues/3046 for more reference. > > Note: I tested this on RPi3b, RPi3a+ and RPi2b. > > as i already wrote this prevent X to start on current Raspbian on my > Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful here. > > I will take a look at the debug UART. Maybe there are more helpful > information. It seems we're seeing different things, I tested this on raspbian (multi_v7_defconfig) and on arm64. I'll try again from scratch tomorrow.
Am 03.03.20 um 19:37 schrieb Nicolas Saenz Julienne: > On Tue, 2020-03-03 at 19:17 +0100, Stefan Wahren wrote: >> Hi Nicolas, >> >> Am 03.03.20 um 18:32 schrieb Nicolas Saenz Julienne: >>> The register based driver turned out to be unstable, specially on RPi3a+ >>> but not limited to it. While a fix is being worked on, we roll back to >>> using firmware based scheme. >>> >>> Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver >>> instead of firmware") >>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>> --- >>> >>> See https://github.com/raspberrypi/linux/issues/3046 for more reference. >>> Note: I tested this on RPi3b, RPi3a+ and RPi2b. >> as i already wrote this prevent X to start on current Raspbian on my >> Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful here. >> >> I will take a look at the debug UART. Maybe there are more helpful >> information. > It seems we're seeing different things, I tested this on raspbian > (multi_v7_defconfig) and on arm64. I'll try again from scratch tomorrow. My modifications to the Raspbian image (from 13.2.2020) are little: - specify devicetree to config.txt - change console to ttyS1 and remove "silent" in cmdline.txt - rename all original kernel7*.img - copy dtb and kernel7.img to boot partition - copy kernel modules to root partition The debug UART works fine, maybe the dmesg gives us a hint: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.6.0-rc2-next-20200220-00004-gaf4f0f5 (stefan@Latitude-E4310) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #16 SMP Tue Mar 3 19:03:36 CET 2020 [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model A Plus Rev 1.0 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.000000] Reserved memory: created CMA memory pool at 0x17800000, size 64 MiB [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] On node 0 totalpages: 114688 [ 0.000000] DMA zone: 896 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 114688 pages, LIFO batch:31 [ 0.000000] percpu: Embedded 20 pages/cpu s49292 r8192 d24436 u81920 [ 0.000000] pcpu-alloc: s49292 r8192 d24436 u81920 alloc=20*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 113792 [ 0.000000] Kernel command line: video=HDMI-A-1:1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0 dma.dmachans=0x7f35 bcm2709.boardrev=0x9020e0 bcm2709.serial=0x48390b9c bcm2709.uart_clock=48000000 bcm2709.disk_led_gpio=29 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:39:0B:9C vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyS1,115200 console=tty1 root=PARTUUID=ea7d04d6-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait splash plymouth.ignore-serial-consoles [ 0.000000] Kernel parameter elevator= does not have any effect anymore. Please use sysfs to set IO scheduler for individual devices. [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 364964K/458752K available (13312K kernel code, 1812K rwdata, 5368K rodata, 2048K init, 407K bss, 28252K reserved, 65536K cma-reserved, 0K highmem) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] rcu: Hierarchical RCU implementation. [ 0.000000] rcu: RCU event tracing is enabled. [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] [Firmware Bug]: Bootloader left irq enabled: bank 1 irq 9 [ 0.000000] random: get_random_bytes called from start_kernel+0x588/0x71c with crng_init=0 [ 0.000009] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns [ 0.000029] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns [ 0.000086] bcm2835: system timer (irq = 27) [ 0.002377] arch_timer: cp15 timer(s) running at 19.20MHz (phys). [ 0.002393] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [ 0.002409] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [ 0.002421] Switching to timer-based delay loop, resolution 52ns [ 0.002836] Console: colour dummy device 80x30 [ 0.003448] printk: console [tty1] enabled [ 0.003516] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000) [ 0.003552] pid_max: default: 32768 minimum: 301 [ 0.003732] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.003762] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.004585] CPU: Testing write buffer coherency: ok [ 0.004991] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.005529] Setting up static identity map for 0x300000 - 0x3000ac [ 0.006338] rcu: Hierarchical SRCU implementation. [ 0.008341] EFI services will not be available. [ 0.008560] smp: Bringing up secondary CPUs ... [ 0.009292] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.010177] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.010936] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.011054] smp: Brought up 1 node, 4 CPUs [ 0.011120] SMP: Total of 4 processors activated (153.60 BogoMIPS). [ 0.011138] CPU: All CPU(s) started in HYP mode. [ 0.011153] CPU: Virtualization extensions available. [ 0.011727] devtmpfs: initialized [ 0.019108] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4 [ 0.019442] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.019484] futex hash table entries: 1024 (order: 4, 65536 bytes, linear) [ 0.022057] pinctrl core: initialized pinctrl subsystem [ 0.023686] thermal_sys: Registered thermal governor 'step_wise' [ 0.023975] DMI not present or invalid. [ 0.024461] NET: Registered protocol family 16 [ 0.027847] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.031365] cpuidle: using governor menu [ 0.032542] No ATAGs? [ 0.032667] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. [ 0.032704] hw-breakpoint: maximum watchpoint size is 8 bytes. [ 0.035015] Serial: AMBA PL011 UART driver [ 0.067972] AT91: Could not find identification node [ 0.069885] iommu: Default domain type: Translated [ 0.070176] vgaarb: loaded [ 0.071021] SCSI subsystem initialized [ 0.071228] libata version 3.00 loaded. [ 0.071500] usbcore: registered new interface driver usbfs [ 0.071562] usbcore: registered new interface driver hub [ 0.071626] usbcore: registered new device driver usb [ 0.072750] pps_core: LinuxPPS API ver. 1 registered [ 0.072769] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 0.072815] PTP clock support registered [ 0.072984] EDAC MC: Ver: 3.0.0 [ 0.076379] clocksource: Switched to clocksource arch_sys_counter [ 1.682452] simple-framebuffer 1e330000.framebuffer: framebuffer at 0x1e330000, 0x8ca000 bytes, mapped to 0x(ptrval) [ 1.682503] simple-framebuffer 1e330000.framebuffer: format=a8r8g8b8, mode=1920x1200x32, linelength=7680 [ 1.740046] Console: switching to colour frame buffer device 240x75 [ 1.796947] simple-framebuffer 1e330000.framebuffer: fb0: simplefb registered! [ 1.804958] NET: Registered protocol family 2 [ 1.805820] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear) [ 1.806182] TCP established hash table entries: 4096 (order: 2, 16384 bytes, linear) [ 1.806581] TCP bind hash table entries: 4096 (order: 3, 32768 bytes, linear) [ 1.806954] TCP: Hash tables configured (established 4096 bind 4096) [ 1.807318] UDP hash table entries: 256 (order: 1, 8192 bytes, linear) [ 1.807601] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear) [ 1.808047] NET: Registered protocol family 1 [ 1.808753] RPC: Registered named UNIX socket transport module. [ 1.808992] RPC: Registered udp transport module. [ 1.809180] RPC: Registered tcp transport module. [ 1.809369] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 1.809629] PCI: CLS 0 bytes, default 64 [ 1.812464] Initialise system trusted keyrings [ 1.812816] workingset: timestamp_bits=30 max_order=17 bucket_order=0 [ 1.821177] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 1.822224] NFS: Registering the id_resolver key type [ 1.822454] Key type id_resolver registered [ 1.822626] Key type id_legacy registered [ 1.822800] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 1.823098] ntfs: driver 2.1.32 [Flags: R/O]. [ 1.823732] Key type asymmetric registered [ 1.823906] Asymmetric key parser 'x509' registered [ 1.824140] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247) [ 1.824434] io scheduler mq-deadline registered [ 1.824617] io scheduler kyber registered [ 1.847075] bcm2835-dma 3f007000.dma: WARN: Device release is not defined so it is not safe to unbind this driver while in use [ 1.902312] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled [ 1.905672] printk: console [ttyS1] disabled [ 1.905933] 3f215040.serial: ttyS1 at MMIO 0x3f215040 (irq = 53, base_baud = 31250000) is a 16550 [ 2.662737] printk: console [ttyS1] enabled [ 2.668957] SuperH (H)SCI(F) driver initialized [ 2.674563] msm_serial: driver initialized [ 2.679048] STMicroelectronics ASC driver initialized [ 2.685391] STM32 USART driver initialized [ 2.691094] bcm2835-rng 3f104000.rng: hwrng registered [ 2.709412] brd: module loaded [ 2.721290] loop: module loaded [ 2.726215] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver [ 2.743178] libphy: Fixed MDIO Bus: probed [ 2.748861] CAN device driver interface [ 2.753703] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded [ 2.760642] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k [ 2.766796] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [ 2.786603] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k [ 2.807399] igb: Copyright (c) 2007-2014 Intel Corporation. [ 2.830193] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver [ 2.851561] usbcore: registered new interface driver pegasus [ 2.871202] usbcore: registered new interface driver asix [ 2.890391] usbcore: registered new interface driver ax88179_178a [ 2.910173] usbcore: registered new interface driver cdc_ether [ 2.929649] usbcore: registered new interface driver smsc75xx [ 2.948874] usbcore: registered new interface driver smsc95xx [ 2.967876] usbcore: registered new interface driver net1080 [ 2.986629] usbcore: registered new interface driver cdc_subset [ 3.005558] usbcore: registered new interface driver zaurus [ 3.024053] usbcore: registered new interface driver cdc_ncm [ 3.044556] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.063973] ehci-pci: EHCI PCI platform driver [ 3.081315] ehci-platform: EHCI generic platform driver [ 3.099569] ehci-orion: EHCI orion driver [ 3.116630] SPEAr-ehci: EHCI SPEAr driver [ 3.133657] ehci-st: EHCI STMicroelectronics driver [ 3.151594] ehci-exynos: EHCI Exynos driver [ 3.168746] ehci-atmel: EHCI Atmel driver [ 3.185575] tegra-ehci: Tegra EHCI driver [ 3.202397] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.221473] ohci-pci: OHCI PCI platform driver [ 3.238731] ohci-platform: OHCI generic platform driver [ 3.256812] SPEAr-ohci: OHCI SPEAr driver [ 3.273478] ohci-st: OHCI STMicroelectronics driver [ 3.290953] ohci-atmel: OHCI Atmel driver [ 3.307905] usbcore: registered new interface driver usb-storage [ 3.331014] i2c /dev entries driver [ 3.348370] i2c-bcm2835 3f805000.i2c: Could not read clock-frequency property [ 3.377645] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer [ 3.399701] sdhci: Secure Digital Host Controller Interface driver [ 3.418153] sdhci: Copyright(c) Pierre Ossman [ 3.436204] Synopsys Designware Multimedia Card Interface Driver [ 3.551786] sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1) [ 3.570306] sdhci-pltfm: SDHCI platform and OF driver helper [ 3.621524] mmc1: SDHCI controller on 3f300000.sdhci [3f300000.sdhci] using PIO [ 3.642980] ledtrig-cpu: registered to indicate activity on CPUs [ 3.662187] usbcore: registered new interface driver usbhid [ 3.680057] usbhid: USB HID core driver [ 3.697071] bcm2835-mbox 3f00b880.mailbox: mailbox enabled [ 3.717577] drop_monitor: Initializing network drop monitor service [ 3.737308] NET: Registered protocol family 10 [ 3.755206] Segment Routing with IPv6 [ 3.771314] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver [ 3.790332] NET: Registered protocol family 17 [ 3.807142] can: controller area network core (rev 20170425 abi 9) [ 3.825888] NET: Registered protocol family 29 [ 3.842831] can: raw protocol (rev 20170425) [ 3.859515] can: broadcast manager protocol (rev 20170425 t) [ 3.877613] can: netlink gateway (rev 20190810) max_hops=1 [ 3.896084] Key type dns_resolver registered [ 3.913830] Registering SWP/SWPB emulation handler [ 3.931416] Loading compiled-in X.509 certificates [ 3.939999] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2 [ 3.962680] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 3.970925] serial serial0: tty port ttyAMA0 registered [ 3.990335] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 4.024105] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-02-12 12:38 [ 4.025835] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 4.064042] raspberrypi-clk raspberrypi-clk: CPU frequency range: min 600000000, max 1400000000 [ 4.065631] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) [ 4.111093] mmc0: host does not support reading read-only switch, assuming write-enable [ 4.132615] mmc0: new high speed SDHC card at address e624 [ 4.146821] mmcblk0: mmc0:e624 SL16G 14.8 GiB [ 4.161171] dwc2 3f980000.usb: 3f980000.usb supply vusb_d not found, using dummy regulator [ 4.165053] mmcblk0: p1 p2 [ 4.176077] dwc2 3f980000.usb: 3f980000.usb supply vusb_a not found, using dummy regulator [ 4.225282] random: fast init done [ 4.243026] mmc1: new high speed SDIO card at address 0001 [ 4.257552] dwc2 3f980000.usb: DWC OTG Controller [ 4.268828] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1 [ 4.282498] dwc2 3f980000.usb: irq 33, io mem 0x3f980000 [ 4.294826] hub 1-0:1.0: USB hub found [ 4.305479] hub 1-0:1.0: 1 port detected [ 4.320665] hctosys: unable to open rtc device (rtc0) [ 4.336481] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem [ 4.350689] EXT4-fs (mmcblk0p2): write access will be enabled during recovery [ 4.662181] EXT4-fs (mmcblk0p2): recovery complete [ 4.684707] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) [ 4.700021] VFS: Mounted root (ext4 filesystem) readonly on device 179:2. [ 4.717256] devtmpfs: mounted [ 4.729196] Freeing unused kernel memory: 2048K [ 4.740743] Run /sbin/init as init process [ 4.751629] with arguments: [ 4.751631] /sbin/init [ 4.751633] splash [ 4.751634] with environment: [ 4.751637] HOME=/ [ 4.751638] TERM=linux [ 4.776391] usb 1-1: new high-speed USB device number 2 using dwc2 [ 4.817354] hub 1-1:1.0: USB hub found [ 4.833504] hub 1-1:1.0: 4 ports detected [ 5.256406] usb 1-1.1: new low-speed USB device number 3 using dwc2 [ 5.365324] systemd[1]: System time before build time, advancing clock. [ 5.448029] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) [ 5.490506] systemd[1]: Detected architecture arm. [ 5.508899] input: Logitech USB Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1:1.0/0003:046D:C31C.0001/input/input0 [ 5.559836] systemd[1]: Set hostname to <raspberrypi>. [ 5.596959] hid-generic 0003:046D:C31C.0001: input: USB HID v1.10 Keyboard [Logitech USB Keyboard] on usb-3f980000.usb-1.1/input0 [ 5.630041] input: Logitech USB Keyboard Consumer Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1:1.1/0003:046D:C31C.0002/input/input1 [ 5.716627] input: Logitech USB Keyboard System Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1:1.1/0003:046D:C31C.0002/input/input2 [ 5.738426] hid-generic 0003:046D:C31C.0002: input: USB HID v1.10 Device [Logitech USB Keyboard] on usb-3f980000.usb-1.1/input1 [ 5.856540] systemd[1]: File /lib/systemd/system/systemd-journald.service:12 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling. [ 5.885933] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.) [ 5.956406] usb 1-1.3: new low-speed USB device number 4 using dwc2 [ 6.214508] input: Logitech USB Optical Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046D:C077.0003/input/input3 [ 6.215790] random: crng init done [ 6.237381] hid-generic 0003:046D:C077.0003: input: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-3f980000.usb-1.3/input0 [ 6.288006] systemd[1]: Listening on Journal Socket (/dev/log). [ 6.314818] systemd[1]: Listening on udev Kernel Socket. [ 6.339003] systemd[1]: Listening on Journal Socket. [ 6.364011] systemd[1]: Mounting Kernel Debug File System... [ 6.393160] systemd[1]: Starting Restore / save the current clock... [ 7.193819] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) [ 7.278860] systemd-journald[132]: Received request to flush runtime journal from PID 1 [ 8.077816] usb_phy_generic phy: phy supply vcc not found, using dummy regulator [ 8.180532] Bluetooth: Core ver 2.22 [ 8.180588] NET: Registered protocol family 31 [ 8.180591] Bluetooth: HCI device and connection manager initialized [ 8.180608] Bluetooth: HCI socket layer initialized [ 8.180617] Bluetooth: L2CAP socket layer initialized [ 8.180630] Bluetooth: SCO socket layer initialized [ 8.235425] Bluetooth: HCI UART driver ver 2.3 [ 8.235437] Bluetooth: HCI UART protocol H4 registered [ 8.235806] Bluetooth: HCI UART protocol Broadcom registered [ 8.235954] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator [ 8.236013] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator [ 8.236061] hci_uart_bcm serial0-0: No reset resource, using default baud rate [ 8.346843] uart-pl011 3f201000.serial: no DMA platform data [ 8.390845] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 8.450496] debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' already present! [ 8.451520] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok [ 8.451541] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name! [ 8.465617] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [ 8.466033] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [ 8.466159] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) [ 8.466292] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4]) [ 8.466649] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 8.466889] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 8.467154] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 8.467262] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 8.467272] checking generic (1e330000 8ca000) vs hw (0 ffffffff) [ 8.467278] fb0: switching to vc4drmfb from simple [ 8.473639] Console: switching to colour dummy device 80x30 [ 8.473714] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 8.473718] [drm] Driver supports precise vblank timestamp query. [ 8.476777] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 8.534359] Console: switching to colour frame buffer device 90x30 [ 8.550245] vc4-drm soc:gpu: fb0: vc4drmfb frame buffer device [ 8.601137] Bluetooth: hci0: BCM: chip id 107 [ 8.603287] Bluetooth: hci0: BCM: features 0x2f [ 8.634065] Bluetooth: hci0: BCM4345C0 [ 8.634081] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000 [ 8.786208] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 8.847887] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 8.877556] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,3-model-a-plus.txt failed with error -2 [ 9.021080] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 9.046953] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04 [ 12.541155] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SS [ 14.418586] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0290 [ 18.463530] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Hi Stefan, On Tue, 2020-03-03 at 20:24 +0100, Stefan Wahren wrote: > > > > Note: I tested this on RPi3b, RPi3a+ and RPi2b. > > > as i already wrote this prevent X to start on current Raspbian on my > > > Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful here. > > > > > > I will take a look at the debug UART. Maybe there are more helpful > > > information. > > It seems we're seeing different things, I tested this on raspbian > > (multi_v7_defconfig) and on arm64. I'll try again from scratch tomorrow. > > My modifications to the Raspbian image (from 13.2.2020) are little: > > - specify devicetree to config.txt > - change console to ttyS1 and remove "silent" in cmdline.txt > - rename all original kernel7*.img > - copy dtb and kernel7.img to boot partition > - copy kernel modules to root partition Would you mind retesting with the latest linux-next? I validated an image based on 5.6.0-rc4-next-20200305-00001-g285a7a64cd56 and a fresh raspbian download on RPi3a+ without X issues. > The debug UART works fine, maybe the dmesg gives us a hint: [...] > [ 8.451520] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi > mapping ok > [ 8.451541] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name! > [ 8.465617] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops > [vc4]) > [ 8.466033] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) > [ 8.466159] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) > [ 8.466292] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4]) > [ 8.466649] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops > vc4_crtc_ops [vc4]) > [ 8.466889] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops > vc4_crtc_ops [vc4]) > [ 8.467154] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops > vc4_crtc_ops [vc4]) > [ 8.467262] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) > [ 8.467272] checking generic (1e330000 8ca000) vs hw (0 ffffffff) > [ 8.467278] fb0: switching to vc4drmfb from simple > [ 8.473639] Console: switching to colour dummy device 80x30 > [ 8.473714] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 8.473718] [drm] Driver supports precise vblank timestamp query. > [ 8.476777] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 > [ 8.534359] Console: switching to colour frame buffer device 90x30 > [ 8.550245] vc4-drm soc:gpu: fb0: vc4drmfb frame buffer device I get the exact same results as you here. Regards, Nicolas
Hi Nicolas, Am 05.03.20 um 11:44 schrieb Nicolas Saenz Julienne: > Hi Stefan, > > On Tue, 2020-03-03 at 20:24 +0100, Stefan Wahren wrote: >>>>> Note: I tested this on RPi3b, RPi3a+ and RPi2b. >>>> as i already wrote this prevent X to start on current Raspbian on my >>>> Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful here. >>>> >>>> I will take a look at the debug UART. Maybe there are more helpful >>>> information. >>> It seems we're seeing different things, I tested this on raspbian >>> (multi_v7_defconfig) and on arm64. I'll try again from scratch tomorrow. >> My modifications to the Raspbian image (from 13.2.2020) are little: >> >> - specify devicetree to config.txt >> - change console to ttyS1 and remove "silent" in cmdline.txt >> - rename all original kernel7*.img >> - copy dtb and kernel7.img to boot partition >> - copy kernel modules to root partition > Would you mind retesting with the latest linux-next? I validated an image based > on 5.6.0-rc4-next-20200305-00001-g285a7a64cd56 and a fresh raspbian download on > RPi3a+ without X issues. i retested with todays linux-next and the issue persists on my RPi 3A+ / HP ZR2440w with this patch applied. I will try more hardware combinations tomorrow to see, this issue is more board or display related. Best regards Stefan
Hi Nicolas, On 06.03.20 21:33, Stefan Wahren wrote: > Hi Nicolas, > > Am 05.03.20 um 11:44 schrieb Nicolas Saenz Julienne: >> Hi Stefan, >> >> On Tue, 2020-03-03 at 20:24 +0100, Stefan Wahren wrote: >>>>>> Note: I tested this on RPi3b, RPi3a+ and RPi2b. >>>>> as i already wrote this prevent X to start on current Raspbian on my >>>>> Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful here. >>>>> >>>>> I will take a look at the debug UART. Maybe there are more helpful >>>>> information. >>>> It seems we're seeing different things, I tested this on raspbian >>>> (multi_v7_defconfig) and on arm64. I'll try again from scratch tomorrow. >>> My modifications to the Raspbian image (from 13.2.2020) are little: >>> >>> - specify devicetree to config.txt >>> - change console to ttyS1 and remove "silent" in cmdline.txt >>> - rename all original kernel7*.img >>> - copy dtb and kernel7.img to boot partition >>> - copy kernel modules to root partition >> Would you mind retesting with the latest linux-next? I validated an image based >> on 5.6.0-rc4-next-20200305-00001-g285a7a64cd56 and a fresh raspbian download on >> RPi3a+ without X issues. > i retested with todays linux-next and the issue persists on my RPi 3A+ / > HP ZR2440w with this patch applied. I tested my display with a RPI 3B, 3B+ and a Zero W. All of them had the same issue. Btw i used this display the last years for testing the Raspberry Pi. After that i connected the RPI 3B to my TV screen and it works with the patch applied. > > I will try more hardware combinations tomorrow to see, this issue is > more board or display related. > > Best regards > Stefan > >
Hi Stefan, On Mon, 2020-03-09 at 16:41 +0100, Stefan Wahren wrote: > Hi Nicolas, > > On 06.03.20 21:33, Stefan Wahren wrote: > > Hi Nicolas, > > > > Am 05.03.20 um 11:44 schrieb Nicolas Saenz Julienne: > > > Hi Stefan, > > > > > > On Tue, 2020-03-03 at 20:24 +0100, Stefan Wahren wrote: > > > > > > > Note: I tested this on RPi3b, RPi3a+ and RPi2b. > > > > > > as i already wrote this prevent X to start on current Raspbian on my > > > > > > Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful > > > > > > here. > > > > > > > > > > > > I will take a look at the debug UART. Maybe there are more helpful > > > > > > information. > > > > > It seems we're seeing different things, I tested this on raspbian > > > > > (multi_v7_defconfig) and on arm64. I'll try again from scratch > > > > > tomorrow. > > > > My modifications to the Raspbian image (from 13.2.2020) are little: > > > > > > > > - specify devicetree to config.txt > > > > - change console to ttyS1 and remove "silent" in cmdline.txt > > > > - rename all original kernel7*.img > > > > - copy dtb and kernel7.img to boot partition > > > > - copy kernel modules to root partition > > > Would you mind retesting with the latest linux-next? I validated an image > > > based > > > on 5.6.0-rc4-next-20200305-00001-g285a7a64cd56 and a fresh raspbian > > > download on > > > RPi3a+ without X issues. > > i retested with todays linux-next and the issue persists on my RPi 3A+ / > > HP ZR2440w with this patch applied. > > I tested my display with a RPI 3B, 3B+ and a Zero W. All of them had the > same issue. Btw i used this display the last years for testing the > Raspberry Pi. > > After that i connected the RPI 3B to my TV screen and it works with the > patch applied. Thanks for taking the time on this. I guess all we have left is looking deeper into it. I'll add it to my backlog for now. Regards, Nicolas
Hi Nicolas, Am 09.03.20 um 20:22 schrieb Nicolas Saenz Julienne: > Hi Stefan, > > On Mon, 2020-03-09 at 16:41 +0100, Stefan Wahren wrote: >> Hi Nicolas, >> >> On 06.03.20 21:33, Stefan Wahren wrote: >>> Hi Nicolas, >>> >>> Am 05.03.20 um 11:44 schrieb Nicolas Saenz Julienne: >>>> Hi Stefan, >>>> >>>> On Tue, 2020-03-03 at 20:24 +0100, Stefan Wahren wrote: >>>>>>>> Note: I tested this on RPi3b, RPi3a+ and RPi2b. >>>>>>> as i already wrote this prevent X to start on current Raspbian on my >>>>>>> Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful >>>>>>> here. >>>>>>> >>>>>>> I will take a look at the debug UART. Maybe there are more helpful >>>>>>> information. >>>>>> It seems we're seeing different things, I tested this on raspbian >>>>>> (multi_v7_defconfig) and on arm64. I'll try again from scratch >>>>>> tomorrow. >>>>> My modifications to the Raspbian image (from 13.2.2020) are little: >>>>> >>>>> - specify devicetree to config.txt >>>>> - change console to ttyS1 and remove "silent" in cmdline.txt >>>>> - rename all original kernel7*.img >>>>> - copy dtb and kernel7.img to boot partition >>>>> - copy kernel modules to root partition >>>> Would you mind retesting with the latest linux-next? I validated an image >>>> based >>>> on 5.6.0-rc4-next-20200305-00001-g285a7a64cd56 and a fresh raspbian >>>> download on >>>> RPi3a+ without X issues. >>> i retested with todays linux-next and the issue persists on my RPi 3A+ / >>> HP ZR2440w with this patch applied. >> I tested my display with a RPI 3B, 3B+ and a Zero W. All of them had the >> same issue. Btw i used this display the last years for testing the >> Raspberry Pi. >> >> After that i connected the RPI 3B to my TV screen and it works with the >> patch applied. > Thanks for taking the time on this. I guess all we have left is looking deeper > into it. I'll add it to my backlog for now. i've a small progress on this issue. Without this patch applied the simple framebuffer driver seems to win against vc4 ( = "good case" ): [ 13.400] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 13.402] (II) no primary bus or device found [ 13.402] (II) LoadModule: "glx" [ 13.405] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 13.465] (II) Module glx: vendor="X.Org Foundation" [ 13.465] compiled for 1.20.4, module version = 1.0.0 [ 13.465] ABI class: X.Org Server Extension, version 10.0 [ 13.465] (II) LoadModule: "fbturbo" [ 13.466] (II) Loading /usr/lib/xorg/modules/drivers/fbturbo_drv.so [ 13.470] (II) Module fbturbo: vendor="X.Org Foundation" [ 13.470] compiled for 1.20.3, module version = 0.5.1 [ 13.470] Module class: X.Org Video Driver [ 13.470] ABI class: X.Org Video Driver, version 24.0 [ 13.470] (II) FBTURBO: driver for framebuffer: fbturbo [ 13.517] (WW) Falling back to old probe method for fbturbo [ 13.518] (II) Loading sub module "fbdevhw" [ 13.518] (II) LoadModule: "fbdevhw" [ 13.518] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 13.523] (II) Module fbdevhw: vendor="X.Org Foundation" [ 13.523] compiled for 1.20.4, module version = 0.0.2 [ 13.523] ABI class: X.Org Video Driver, version 24.0 [ 13.524] (II) FBTURBO(0): using /dev/fb0 [ 13.524] (II) FBTURBO(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 13.524] (==) FBTURBO(0): Depth 24, (==) framebuffer bpp 32 [ 13.524] (==) FBTURBO(0): RGB weight 888 [ 13.524] (==) FBTURBO(0): Default visual is TrueColor [ 13.524] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0) [ 13.524] (II) FBTURBO(0): hardware: simple (video memory: 9000kB) With the patch applied vc4 wins, but mode setting seems to fail: [ 13.596] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 13.599] (II) xfree86: Adding drm device (/dev/dri/card0) [ 13.606] (II) no primary bus or device found [ 13.607] falling back to /sys/devices/platform/soc/soc:gpu/drm/card0 [ 13.607] (II) LoadModule: "glx" [ 13.613] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 13.674] (II) Module glx: vendor="X.Org Foundation" [ 13.674] compiled for 1.20.4, module version = 1.0.0 [ 13.674] ABI class: X.Org Server Extension, version 10.0 [ 13.674] (II) LoadModule: "fbturbo" [ 13.675] (II) Loading /usr/lib/xorg/modules/drivers/fbturbo_drv.so [ 13.679] (II) Module fbturbo: vendor="X.Org Foundation" [ 13.679] compiled for 1.20.3, module version = 0.5.1 [ 13.679] Module class: X.Org Video Driver [ 13.679] ABI class: X.Org Video Driver, version 24.0 [ 13.679] (II) FBTURBO: driver for framebuffer: fbturbo [ 13.689] (WW) Falling back to old probe method for fbturbo [ 13.689] (II) Loading sub module "fbdevhw" [ 13.689] (II) LoadModule: "fbdevhw" [ 13.690] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 13.692] (II) Module fbdevhw: vendor="X.Org Foundation" [ 13.692] compiled for 1.20.4, module version = 0.0.2 [ 13.693] ABI class: X.Org Video Driver, version 24.0 [ 13.693] (II) FBTURBO(0): using /dev/fb0 [ 13.693] (II) FBTURBO(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 16/16 [ 13.693] (==) FBTURBO(0): Depth 16, (==) framebuffer bpp 16 [ 13.693] (==) FBTURBO(0): RGB weight 565 [ 13.693] (==) FBTURBO(0): Default visual is TrueColor [ 13.693] (==) FBTURBO(0): Using gamma correction (1.0, 1.0, 1.0) [ 13.693] (II) FBTURBO(0): hardware: vc4drmfb (video memory: 675kB) could you please confirm which driver is actually working on X with this patch applied in your case? Regards Stefan > > Regards, > Nicolas >
Hi Nicolas, [adjust audience] Am 13.03.20 um 14:59 schrieb Stefan Wahren: > Hi Nicolas, > > Am 09.03.20 um 20:22 schrieb Nicolas Saenz Julienne: >> Hi Stefan, >> >> On Mon, 2020-03-09 at 16:41 +0100, Stefan Wahren wrote: >>> Hi Nicolas, >>> >>> On 06.03.20 21:33, Stefan Wahren wrote: >>>> Hi Nicolas, >>>> >>>> Am 05.03.20 um 11:44 schrieb Nicolas Saenz Julienne: >>>>> Hi Stefan, >>>>> >>>>> On Tue, 2020-03-03 at 20:24 +0100, Stefan Wahren wrote: >>>>>>>>> Note: I tested this on RPi3b, RPi3a+ and RPi2b. >>>>>>>> as i already wrote this prevent X to start on current Raspbian on my >>>>>>>> Raspberry Pi 3A+ (multi_v7_defconfig, no u-boot). We must be careful >>>>>>>> here. >>>>>>>> >>>>>>>> I will take a look at the debug UART. Maybe there are more helpful >>>>>>>> information. >>>>>>> It seems we're seeing different things, I tested this on raspbian >>>>>>> (multi_v7_defconfig) and on arm64. I'll try again from scratch >>>>>>> tomorrow. >>>>>> My modifications to the Raspbian image (from 13.2.2020) are little: >>>>>> >>>>>> - specify devicetree to config.txt >>>>>> - change console to ttyS1 and remove "silent" in cmdline.txt >>>>>> - rename all original kernel7*.img >>>>>> - copy dtb and kernel7.img to boot partition >>>>>> - copy kernel modules to root partition >>>>> Would you mind retesting with the latest linux-next? I validated an image >>>>> based >>>>> on 5.6.0-rc4-next-20200305-00001-g285a7a64cd56 and a fresh raspbian >>>>> download on >>>>> RPi3a+ without X issues. >>>> i retested with todays linux-next and the issue persists on my RPi 3A+ / >>>> HP ZR2440w with this patch applied. >>> I tested my display with a RPI 3B, 3B+ and a Zero W. All of them had the >>> same issue. Btw i used this display the last years for testing the >>> Raspberry Pi. >>> >>> After that i connected the RPI 3B to my TV screen and it works with the >>> patch applied. >> Thanks for taking the time on this. I guess all we have left is looking deeper >> into it. I'll add it to my backlog for now. i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM emulated driver was responsible for a working X on my Raspberry Pi 3 with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X didn't start anymore (display freeze). So i start bisecting and this was the commit where the freezing started: e08ab74bd4 drm/modes: Rewrite the command line parser After this i enabled drm debug and saw that suggest mode 1920x1200 by the firmware is rejected by the driver because the pixel clock would be too high (154 MHz, max = 148.5). This wasn't a problem before since the firmware provided video cmdline parameter wasn't parseable: [drm] parse error at position 69 in video mode '1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0' After mentioned commit the display just freezes (no try to use 1920x1080, no error message). For comparison i switched to the vendor tree with firmware kms driver and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz. So this patch works for me: --- drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index cea18dc..647803e 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -681,11 +681,12 @@ static enum drm_mode_status vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, const struct drm_display_mode *mode) { - /* HSM clock must be 108% of the pixel clock. Additionally, - * the AXI clock needs to be at least 25% of pixel clock, but - * HSM ends up being the limiting factor. + /* According to spec the HSM clock must be 108% of the pixel clock. + * Additionally, the AXI clock needs to be at least 25% of pixel clock, + * but HSM ends up being the limiting factor. + * It seems that operating the pixel clock at 154 MHz still works. */ - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) + if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100)) return MODE_CLOCK_HIGH; return MODE_OK;
Hi Stefan, thanks for taking the time with this. That was a hard to find one, specially given the race in X11. On Sun, 2020-03-15 at 20:16 +0100, Stefan Wahren wrote: > Hi Nicolas, > > [adjust audience] > > i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM > emulated driver was responsible for a working X on my Raspberry Pi 3 > with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X > didn't start anymore (display freeze). > > So i start bisecting and this was the commit where the freezing started: > > e08ab74bd4 drm/modes: Rewrite the command line parser > > After this i enabled drm debug and saw that suggest mode 1920x1200 by > the firmware is rejected by the driver because the pixel clock would be > too high (154 MHz, max = 148.5). This wasn't a problem before since the > firmware provided video cmdline parameter wasn't parseable: > > [drm] parse error at position 69 in video mode > '1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0' > > After mentioned commit the display just freezes (no try to use > 1920x1080, no error message). > > For comparison i switched to the vendor tree with firmware kms driver > and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz. > > So this patch works for me: > > --- > drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > index cea18dc..647803e 100644 > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > @@ -681,11 +681,12 @@ static enum drm_mode_status > vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, > const struct drm_display_mode *mode) > { > - /* HSM clock must be 108% of the pixel clock. I think it'd be nice to understand how Eric came by this number. Maybe just empirically with 1080p60? That said, I think your change is pretty much harmless. I'll add a reminder to Maxime's series for him to update RPi[0-3]'s max frequency to 1920x1200@60's. > - * the AXI clock needs to be at least 25% of pixel clock, but > - * HSM ends up being the limiting factor. > + /* According to spec the HSM clock must be 108% of the pixel clock. > + * Additionally, the AXI clock needs to be at least 25% of pixel clock, > + * but HSM ends up being the limiting factor. > + * It seems that operating the pixel clock at 154 MHz still works. > */ > - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) > + if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100)) Isn't hard-coding the HSM clock kind of limited, one could overclock it, isn't it? I remember reading someone did it to support wider resolutions. Regards, Nicolas [1] https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679#p333810 > return MODE_CLOCK_HIGH; > > return MODE_OK;
Hi Stefan and Nicolas On Mon, 16 Mar 2020 at 12:40, Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote: > > Hi Stefan, > thanks for taking the time with this. That was a hard to find one, specially > given the race in X11. > > On Sun, 2020-03-15 at 20:16 +0100, Stefan Wahren wrote: > > Hi Nicolas, > > > > [adjust audience] > > > > i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM > > emulated driver was responsible for a working X on my Raspberry Pi 3 > > with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X > > didn't start anymore (display freeze). > > > > So i start bisecting and this was the commit where the freezing started: > > > > e08ab74bd4 drm/modes: Rewrite the command line parser > > > > After this i enabled drm debug and saw that suggest mode 1920x1200 by > > the firmware is rejected by the driver because the pixel clock would be > > too high (154 MHz, max = 148.5). This wasn't a problem before since the > > firmware provided video cmdline parameter wasn't parseable: > > > > [drm] parse error at position 69 in video mode > > '1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0' > > > > After mentioned commit the display just freezes (no try to use > > 1920x1080, no error message). > > > > For comparison i switched to the vendor tree with firmware kms driver > > and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz. > > > > So this patch works for me: > > > > --- > > drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > > index cea18dc..647803e 100644 > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > > @@ -681,11 +681,12 @@ static enum drm_mode_status > > vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, > > const struct drm_display_mode *mode) > > { > > - /* HSM clock must be 108% of the pixel clock. > > I think it'd be nice to understand how Eric came by this number. Maybe just > empirically with 1080p60? That said, I think your change is pretty much > harmless. > > I'll add a reminder to Maxime's series for him to update RPi[0-3]'s max > frequency to 1920x1200@60's. > > > - * the AXI clock needs to be at least 25% of pixel clock, but > > - * HSM ends up being the limiting factor. > > + /* According to spec the HSM clock must be 108% of the pixel clock. > > + * Additionally, the AXI clock needs to be at least 25% of pixel clock, > > + * but HSM ends up being the limiting factor. > > + * It seems that operating the pixel clock at 154 MHz still works. > > */ > > - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) > > + if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100)) > > Isn't hard-coding the HSM clock kind of limited, one could overclock it, isn't > it? I remember reading someone did it to support wider resolutions. Checking the docs it does state the restriction that Eric quotes. HDMI Core Clock (state machine clock) Most of the HDMI logic operates on that clock. It is asynchronous to system core clock and pixel clock. Source for this clock can be chosen from various PLLs in the chip. See CPR Manager for details. This clock is also used for clocking pixel valve when HDMI peripheral is used. See Pixel Valve for details.axi_clock >= hdmi_core_clock > 108% of pixel_clock. The default max pixel clock from the firmware side is 162MHz. In the firmware source we have a comment // HDMI state machine clock must be faster than pixel clock - infinitessimally faster tested in simulation. // Otherwise, exact value is unimportant - for HDMI operation. // hdmi state machine clock now derived from PLLC_PER (typ 500MHz, see relevant platform.c). // // However, CEC bit clock is derived from the HSM clock, and the (programmable) CEC timing table // is configured for a 40.00kHz CEC clock. const unsigned margin = 1*1000*1000; unsigned min_hsm_clock = margin + timings->pixel_freq; const unsigned max_hsm_clock_for_cec = max(163682864, hdmi_pixel_freq_limit); unsigned hdmi_state_machine_clock = max_hsm_clock_for_cec; So it adds 1MHz to the pixel clock for min_hsm_clock, but then doesn't use the value. Unless you do request a higher hdmi_pixel_freq_limit then the HSM is running at the same 163.68MHz that Eric's driver hard codes, and our max pixel clock is 162MHz. Keeping it a fixed value makes sorting the divider for CEC easier. Just adopting a 162MHz limit with a suitable comment is probably the most sensible move here, and Maxime's patches can pick up the same value. Regards, Dave > Regards, > Nicolas > > [1] https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679#p333810 > > > return MODE_CLOCK_HIGH; > > > > return MODE_OK; > >
On Mon, 2020-03-16 at 13:57 +0000, Dave Stevenson wrote: > Hi Stefan and Nicolas > > Checking the docs it does state the restriction that Eric quotes. > > HDMI Core Clock (state machine clock) > Most of the HDMI logic operates on that clock. It > is asynchronous to system core clock and pixel > clock. Source for this clock can be chosen from > various PLLs in the chip. See CPR Manager for > details. > > This clock is also used for clocking pixel valve > when HDMI peripheral is used. See Pixel Valve > for details.axi_clock >= hdmi_core_clock > 108% of > pixel_clock. > > > The default max pixel clock from the firmware side is 162MHz. > > In the firmware source we have a comment > // HDMI state machine clock must be faster than pixel clock - > infinitessimally faster tested in simulation. > // Otherwise, exact value is unimportant - for HDMI operation. > // hdmi state machine clock now derived from PLLC_PER (typ > 500MHz, see relevant platform.c). > // > // However, CEC bit clock is derived from the HSM clock, and > the (programmable) CEC timing table > // is configured for a 40.00kHz CEC clock. > const unsigned margin = 1*1000*1000; > unsigned min_hsm_clock = margin + timings->pixel_freq; > const unsigned max_hsm_clock_for_cec = max(163682864, > hdmi_pixel_freq_limit); > > unsigned hdmi_state_machine_clock = max_hsm_clock_for_cec; > > So it adds 1MHz to the pixel clock for min_hsm_clock, but then doesn't > use the value. > Unless you do request a higher hdmi_pixel_freq_limit then the HSM is > running at the same 163.68MHz that Eric's driver hard codes, and our > max pixel clock is 162MHz. > Keeping it a fixed value makes sorting the divider for CEC easier. > > Just adopting a 162MHz limit with a suitable comment is probably the > most sensible move here, and Maxime's patches can pick up the same > value. I agree with Dave. Moreover, this was initially introduced to fix resolution negotiations with 4k devices, which use higher pixel clocks than HSM_CLOCK_FREQ. I've been reviewing common HDMI resolutions and 1200p60 seems to be the one closer to RPi's HSM limitations (as far as widely used aspect ratios are concerned). So I can't image how setting a smaller than HSM_CLOCK_FREQ limit here is going to break anything. That said I'm no expert in this area. Stefan, any opinions? Feel like sending a patch? :) Regards, Nicolas
Hi Dave, On Mon, Mar 16, 2020 at 01:57:13PM +0000, Dave Stevenson wrote: > Hi Stefan and Nicolas > > On Mon, 16 Mar 2020 at 12:40, Nicolas Saenz Julienne > <nsaenzjulienne@suse.de> wrote: > > > > Hi Stefan, > > thanks for taking the time with this. That was a hard to find one, specially > > given the race in X11. > > > > On Sun, 2020-03-15 at 20:16 +0100, Stefan Wahren wrote: > > > Hi Nicolas, > > > > > > [adjust audience] > > > > > > i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM > > > emulated driver was responsible for a working X on my Raspberry Pi 3 > > > with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X > > > didn't start anymore (display freeze). > > > > > > So i start bisecting and this was the commit where the freezing started: > > > > > > e08ab74bd4 drm/modes: Rewrite the command line parser > > > > > > After this i enabled drm debug and saw that suggest mode 1920x1200 by > > > the firmware is rejected by the driver because the pixel clock would be > > > too high (154 MHz, max = 148.5). This wasn't a problem before since the > > > firmware provided video cmdline parameter wasn't parseable: > > > > > > [drm] parse error at position 69 in video mode > > > '1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0' > > > > > > After mentioned commit the display just freezes (no try to use > > > 1920x1080, no error message). > > > > > > For comparison i switched to the vendor tree with firmware kms driver > > > and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz. > > > > > > So this patch works for me: > > > > > > --- > > > drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++---- > > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > > > index cea18dc..647803e 100644 > > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > > > @@ -681,11 +681,12 @@ static enum drm_mode_status > > > vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, > > > const struct drm_display_mode *mode) > > > { > > > - /* HSM clock must be 108% of the pixel clock. > > > > I think it'd be nice to understand how Eric came by this number. Maybe just > > empirically with 1080p60? That said, I think your change is pretty much > > harmless. > > > > I'll add a reminder to Maxime's series for him to update RPi[0-3]'s max > > frequency to 1920x1200@60's. > > > > > - * the AXI clock needs to be at least 25% of pixel clock, but > > > - * HSM ends up being the limiting factor. > > > + /* According to spec the HSM clock must be 108% of the pixel clock. > > > + * Additionally, the AXI clock needs to be at least 25% of pixel clock, > > > + * but HSM ends up being the limiting factor. > > > + * It seems that operating the pixel clock at 154 MHz still works. > > > */ > > > - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) > > > + if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100)) > > > > Isn't hard-coding the HSM clock kind of limited, one could overclock it, isn't > > it? I remember reading someone did it to support wider resolutions. > > Checking the docs it does state the restriction that Eric quotes. > > HDMI Core Clock (state machine clock) > Most of the HDMI logic operates on that clock. It > is asynchronous to system core clock and pixel > clock. Source for this clock can be chosen from > various PLLs in the chip. See CPR Manager for > details. > > This clock is also used for clocking pixel valve > when HDMI peripheral is used. See Pixel Valve > for details.axi_clock >= hdmi_core_clock > 108% of > pixel_clock. > > > The default max pixel clock from the firmware side is 162MHz. > > In the firmware source we have a comment > // HDMI state machine clock must be faster than pixel clock - > infinitessimally faster tested in simulation. > // Otherwise, exact value is unimportant - for HDMI operation. > // hdmi state machine clock now derived from PLLC_PER (typ > 500MHz, see relevant platform.c). > // > // However, CEC bit clock is derived from the HSM clock, and > the (programmable) CEC timing table > // is configured for a 40.00kHz CEC clock. > const unsigned margin = 1*1000*1000; > unsigned min_hsm_clock = margin + timings->pixel_freq; > const unsigned max_hsm_clock_for_cec = max(163682864, > hdmi_pixel_freq_limit); > > unsigned hdmi_state_machine_clock = max_hsm_clock_for_cec; > > So it adds 1MHz to the pixel clock for min_hsm_clock, but then doesn't > use the value. > Unless you do request a higher hdmi_pixel_freq_limit then the HSM is > running at the same 163.68MHz that Eric's driver hard codes, and our > max pixel clock is 162MHz. > Keeping it a fixed value makes sorting the divider for CEC easier. > > Just adopting a 162MHz limit with a suitable comment is probably the > most sensible move here, and Maxime's patches can pick up the same > value. It's kind of related, but one of the changes we did to support the RPi4 is to change that rate calculation to increase the HSM clock for pixel clocks higher than 148.5MHz (so typically 4k), while keeping it as low as possible to reduce the power consumption. How would that interact with this change? Thanks! Maxime
Hi Maxime On Mon, 23 Mar 2020 at 14:57, Maxime Ripard <maxime@cerno.tech> wrote: > > Hi Dave, > > On Mon, Mar 16, 2020 at 01:57:13PM +0000, Dave Stevenson wrote: > > Hi Stefan and Nicolas > > > > On Mon, 16 Mar 2020 at 12:40, Nicolas Saenz Julienne > > <nsaenzjulienne@suse.de> wrote: > > > > > > Hi Stefan, > > > thanks for taking the time with this. That was a hard to find one, specially > > > given the race in X11. > > > > > > On Sun, 2020-03-15 at 20:16 +0100, Stefan Wahren wrote: > > > > Hi Nicolas, > > > > > > > > [adjust audience] > > > > > > > > i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM > > > > emulated driver was responsible for a working X on my Raspberry Pi 3 > > > > with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X > > > > didn't start anymore (display freeze). > > > > > > > > So i start bisecting and this was the commit where the freezing started: > > > > > > > > e08ab74bd4 drm/modes: Rewrite the command line parser > > > > > > > > After this i enabled drm debug and saw that suggest mode 1920x1200 by > > > > the firmware is rejected by the driver because the pixel clock would be > > > > too high (154 MHz, max = 148.5). This wasn't a problem before since the > > > > firmware provided video cmdline parameter wasn't parseable: > > > > > > > > [drm] parse error at position 69 in video mode > > > > '1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0' > > > > > > > > After mentioned commit the display just freezes (no try to use > > > > 1920x1080, no error message). > > > > > > > > For comparison i switched to the vendor tree with firmware kms driver > > > > and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz. > > > > > > > > So this patch works for me: > > > > > > > > --- > > > > drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++---- > > > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > > > > index cea18dc..647803e 100644 > > > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > > > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > > > > @@ -681,11 +681,12 @@ static enum drm_mode_status > > > > vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, > > > > const struct drm_display_mode *mode) > > > > { > > > > - /* HSM clock must be 108% of the pixel clock. > > > > > > I think it'd be nice to understand how Eric came by this number. Maybe just > > > empirically with 1080p60? That said, I think your change is pretty much > > > harmless. > > > > > > I'll add a reminder to Maxime's series for him to update RPi[0-3]'s max > > > frequency to 1920x1200@60's. > > > > > > > - * the AXI clock needs to be at least 25% of pixel clock, but > > > > - * HSM ends up being the limiting factor. > > > > + /* According to spec the HSM clock must be 108% of the pixel clock. > > > > + * Additionally, the AXI clock needs to be at least 25% of pixel clock, > > > > + * but HSM ends up being the limiting factor. > > > > + * It seems that operating the pixel clock at 154 MHz still works. > > > > */ > > > > - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) > > > > + if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100)) > > > > > > Isn't hard-coding the HSM clock kind of limited, one could overclock it, isn't > > > it? I remember reading someone did it to support wider resolutions. > > > > Checking the docs it does state the restriction that Eric quotes. > > > > HDMI Core Clock (state machine clock) > > Most of the HDMI logic operates on that clock. It > > is asynchronous to system core clock and pixel > > clock. Source for this clock can be chosen from > > various PLLs in the chip. See CPR Manager for > > details. > > > > This clock is also used for clocking pixel valve > > when HDMI peripheral is used. See Pixel Valve > > for details.axi_clock >= hdmi_core_clock > 108% of > > pixel_clock. > > > > > > The default max pixel clock from the firmware side is 162MHz. > > > > In the firmware source we have a comment > > // HDMI state machine clock must be faster than pixel clock - > > infinitessimally faster tested in simulation. > > // Otherwise, exact value is unimportant - for HDMI operation. > > // hdmi state machine clock now derived from PLLC_PER (typ > > 500MHz, see relevant platform.c). > > // > > // However, CEC bit clock is derived from the HSM clock, and > > the (programmable) CEC timing table > > // is configured for a 40.00kHz CEC clock. > > const unsigned margin = 1*1000*1000; > > unsigned min_hsm_clock = margin + timings->pixel_freq; > > const unsigned max_hsm_clock_for_cec = max(163682864, > > hdmi_pixel_freq_limit); > > > > unsigned hdmi_state_machine_clock = max_hsm_clock_for_cec; > > > > So it adds 1MHz to the pixel clock for min_hsm_clock, but then doesn't > > use the value. > > Unless you do request a higher hdmi_pixel_freq_limit then the HSM is > > running at the same 163.68MHz that Eric's driver hard codes, and our > > max pixel clock is 162MHz. > > Keeping it a fixed value makes sorting the divider for CEC easier. > > > > Just adopting a 162MHz limit with a suitable comment is probably the > > most sensible move here, and Maxime's patches can pick up the same > > value. > > It's kind of related, but one of the changes we did to support the > RPi4 is to change that rate calculation to increase the HSM clock for > pixel clocks higher than 148.5MHz (so typically 4k), while keeping it > as low as possible to reduce the power consumption. > > How would that interact with this change? I'd forgotten that your patches mean we change the HSM clock on Pi3. As you're aware, whilst I have some extra docs, many of them aren't as comprehensive as one would hope. We can go back to the Broadcom and RTL if absolutely necessary, but it's a pain. Broadcom don't necessarily have the personnel who designed the blocks still working there. Your patches appear to recompute the HSM clock based on pixel_clock * 108%, with a min of 108MHz, so effectively the same limit as the old version did by fixing the HSM rate. Checking the firmware for Pi4, it sets the HSM (M2MC) clock to pixel_rate * 1.01, clipped to 120MHz and 600Mhz. (Audio drops out if less than 108MHz. "Pick 120 to have an integer divider with some margin." I'd need to check which divider that is referring to). As noted above, the Pi3 firmware sets the HSM clock to 163.6MHz. I'd suggest that we: a) Increase max_pixel_clock for vc4 (Pi0-3) to 162MHz. b) Set HSM clock to 101% of the pixel clock, with a min of 120MHz (4k60 with pixel clock 594MHz would go to a 599.94MHz HSM clock which is still within range) c) Test it! I know we have some 1920x1200 monitors in the office (when I'm back in there). Whilst the firmware would appear to use a fixed HSM clock on Pi0-3, I don't anticipate there being any issue with varying it. It looks like there was the expectation of it being variable in the past, but someone has refactored it and either accidentally or deliberately given up on the idea. Dave
Hi, Am 23.03.20 um 16:55 schrieb Dave Stevenson: > Hi Maxime > > On Mon, 23 Mar 2020 at 14:57, Maxime Ripard <maxime@cerno.tech> wrote: >> Hi Dave, >> >> On Mon, Mar 16, 2020 at 01:57:13PM +0000, Dave Stevenson wrote: >>> Hi Stefan and Nicolas >>> >>> On Mon, 16 Mar 2020 at 12:40, Nicolas Saenz Julienne >>> <nsaenzjulienne@suse.de> wrote: >>>> Hi Stefan, >>>> thanks for taking the time with this. That was a hard to find one, specially >>>> given the race in X11. >>>> >>>> On Sun, 2020-03-15 at 20:16 +0100, Stefan Wahren wrote: >>>>> Hi Nicolas, >>>>> >>>>> [adjust audience] >>>>> >>>>> i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM >>>>> emulated driver was responsible for a working X on my Raspberry Pi 3 >>>>> with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X >>>>> didn't start anymore (display freeze). >>>>> >>>>> So i start bisecting and this was the commit where the freezing started: >>>>> >>>>> e08ab74bd4 drm/modes: Rewrite the command line parser >>>>> >>>>> After this i enabled drm debug and saw that suggest mode 1920x1200 by >>>>> the firmware is rejected by the driver because the pixel clock would be >>>>> too high (154 MHz, max = 148.5). This wasn't a problem before since the >>>>> firmware provided video cmdline parameter wasn't parseable: >>>>> >>>>> [drm] parse error at position 69 in video mode >>>>> '1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0' >>>>> >>>>> After mentioned commit the display just freezes (no try to use >>>>> 1920x1080, no error message). >>>>> >>>>> For comparison i switched to the vendor tree with firmware kms driver >>>>> and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz. >>>>> >>>>> So this patch works for me: >>>>> >>>>> --- >>>>> drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++---- >>>>> 1 file changed, 5 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c >>>>> index cea18dc..647803e 100644 >>>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c >>>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c >>>>> @@ -681,11 +681,12 @@ static enum drm_mode_status >>>>> vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, >>>>> const struct drm_display_mode *mode) >>>>> { >>>>> - /* HSM clock must be 108% of the pixel clock. >>>> I think it'd be nice to understand how Eric came by this number. Maybe just >>>> empirically with 1080p60? That said, I think your change is pretty much >>>> harmless. >>>> >>>> I'll add a reminder to Maxime's series for him to update RPi[0-3]'s max >>>> frequency to 1920x1200@60's. >>>> >>>>> - * the AXI clock needs to be at least 25% of pixel clock, but >>>>> - * HSM ends up being the limiting factor. >>>>> + /* According to spec the HSM clock must be 108% of the pixel clock. >>>>> + * Additionally, the AXI clock needs to be at least 25% of pixel clock, >>>>> + * but HSM ends up being the limiting factor. >>>>> + * It seems that operating the pixel clock at 154 MHz still works. >>>>> */ >>>>> - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) >>>>> + if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100)) >>>> Isn't hard-coding the HSM clock kind of limited, one could overclock it, isn't >>>> it? I remember reading someone did it to support wider resolutions. >>> Checking the docs it does state the restriction that Eric quotes. >>> >>> HDMI Core Clock (state machine clock) >>> Most of the HDMI logic operates on that clock. It >>> is asynchronous to system core clock and pixel >>> clock. Source for this clock can be chosen from >>> various PLLs in the chip. See CPR Manager for >>> details. >>> >>> This clock is also used for clocking pixel valve >>> when HDMI peripheral is used. See Pixel Valve >>> for details.axi_clock >= hdmi_core_clock > 108% of >>> pixel_clock. >>> >>> >>> The default max pixel clock from the firmware side is 162MHz. >>> >>> In the firmware source we have a comment >>> // HDMI state machine clock must be faster than pixel clock - >>> infinitessimally faster tested in simulation. >>> // Otherwise, exact value is unimportant - for HDMI operation. >>> // hdmi state machine clock now derived from PLLC_PER (typ >>> 500MHz, see relevant platform.c). >>> // >>> // However, CEC bit clock is derived from the HSM clock, and >>> the (programmable) CEC timing table >>> // is configured for a 40.00kHz CEC clock. >>> const unsigned margin = 1*1000*1000; >>> unsigned min_hsm_clock = margin + timings->pixel_freq; >>> const unsigned max_hsm_clock_for_cec = max(163682864, >>> hdmi_pixel_freq_limit); >>> >>> unsigned hdmi_state_machine_clock = max_hsm_clock_for_cec; >>> >>> So it adds 1MHz to the pixel clock for min_hsm_clock, but then doesn't >>> use the value. >>> Unless you do request a higher hdmi_pixel_freq_limit then the HSM is >>> running at the same 163.68MHz that Eric's driver hard codes, and our >>> max pixel clock is 162MHz. >>> Keeping it a fixed value makes sorting the divider for CEC easier. >>> >>> Just adopting a 162MHz limit with a suitable comment is probably the >>> most sensible move here, and Maxime's patches can pick up the same >>> value. >> It's kind of related, but one of the changes we did to support the >> RPi4 is to change that rate calculation to increase the HSM clock for >> pixel clocks higher than 148.5MHz (so typically 4k), while keeping it >> as low as possible to reduce the power consumption. >> >> How would that interact with this change? > I'd forgotten that your patches mean we change the HSM clock on Pi3. > As you're aware, whilst I have some extra docs, many of them aren't as > comprehensive as one would hope. We can go back to the Broadcom and > RTL if absolutely necessary, but it's a pain. Broadcom don't > necessarily have the personnel who designed the blocks still working > there. > > Your patches appear to recompute the HSM clock based on pixel_clock * > 108%, with a min of 108MHz, so effectively the same limit as the old > version did by fixing the HSM rate. > > Checking the firmware for Pi4, it sets the HSM (M2MC) clock to > pixel_rate * 1.01, clipped to 120MHz and 600Mhz. (Audio drops out if > less than 108MHz. "Pick 120 to have an integer divider with some > margin." I'd need to check which divider that is referring to). > As noted above, the Pi3 firmware sets the HSM clock to 163.6MHz. > > I'd suggest that we: > a) Increase max_pixel_clock for vc4 (Pi0-3) to 162MHz. > b) Set HSM clock to 101% of the pixel clock, with a min of 120MHz > (4k60 with pixel clock 594MHz would go to a 599.94MHz HSM clock which > is still within range) > c) Test it! I know we have some 1920x1200 monitors in the office (when > I'm back in there). i don't think that i'm able to prepare those patches, but i'm happy to test them. Thanks Stefan > > Whilst the firmware would appear to use a fixed HSM clock on Pi0-3, I > don't anticipate there being any issue with varying it. It looks like > there was the expectation of it being variable in the past, but > someone has refactored it and either accidentally or deliberately > given up on the idea. > > Dave > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Stefan On Mon, 23 Mar 2020 at 18:53, Stefan Wahren <stefan.wahren@i2se.com> wrote: > > Hi, > > Am 23.03.20 um 16:55 schrieb Dave Stevenson: > > Hi Maxime > > > > On Mon, 23 Mar 2020 at 14:57, Maxime Ripard <maxime@cerno.tech> wrote: > >> Hi Dave, > >> > >> On Mon, Mar 16, 2020 at 01:57:13PM +0000, Dave Stevenson wrote: > >>> Hi Stefan and Nicolas > >>> > >>> On Mon, 16 Mar 2020 at 12:40, Nicolas Saenz Julienne > >>> <nsaenzjulienne@suse.de> wrote: > >>>> Hi Stefan, > >>>> thanks for taking the time with this. That was a hard to find one, specially > >>>> given the race in X11. > >>>> > >>>> On Sun, 2020-03-15 at 20:16 +0100, Stefan Wahren wrote: > >>>>> Hi Nicolas, > >>>>> > >>>>> [adjust audience] > >>>>> > >>>>> i've narrowed down the issue. From kernel 4.19 until 5.1 the DRM > >>>>> emulated driver was responsible for a working X on my Raspberry Pi 3 > >>>>> with HP ZR2440w. Starting with 5.2 the vc4drmfb took over and with 5.3 X > >>>>> didn't start anymore (display freeze). > >>>>> > >>>>> So i start bisecting and this was the commit where the freezing started: > >>>>> > >>>>> e08ab74bd4 drm/modes: Rewrite the command line parser > >>>>> > >>>>> After this i enabled drm debug and saw that suggest mode 1920x1200 by > >>>>> the firmware is rejected by the driver because the pixel clock would be > >>>>> too high (154 MHz, max = 148.5). This wasn't a problem before since the > >>>>> firmware provided video cmdline parameter wasn't parseable: > >>>>> > >>>>> [drm] parse error at position 69 in video mode > >>>>> '1920x1200M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0' > >>>>> > >>>>> After mentioned commit the display just freezes (no try to use > >>>>> 1920x1080, no error message). > >>>>> > >>>>> For comparison i switched to the vendor tree with firmware kms driver > >>>>> and noticed that the driver switches to 1920x1200 with a pixel at 154 MHz. > >>>>> > >>>>> So this patch works for me: > >>>>> > >>>>> --- > >>>>> drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +++++---- > >>>>> 1 file changed, 5 insertions(+), 4 deletions(-) > >>>>> > >>>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > >>>>> index cea18dc..647803e 100644 > >>>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > >>>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > >>>>> @@ -681,11 +681,12 @@ static enum drm_mode_status > >>>>> vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, > >>>>> const struct drm_display_mode *mode) > >>>>> { > >>>>> - /* HSM clock must be 108% of the pixel clock. > >>>> I think it'd be nice to understand how Eric came by this number. Maybe just > >>>> empirically with 1080p60? That said, I think your change is pretty much > >>>> harmless. > >>>> > >>>> I'll add a reminder to Maxime's series for him to update RPi[0-3]'s max > >>>> frequency to 1920x1200@60's. > >>>> > >>>>> - * the AXI clock needs to be at least 25% of pixel clock, but > >>>>> - * HSM ends up being the limiting factor. > >>>>> + /* According to spec the HSM clock must be 108% of the pixel clock. > >>>>> + * Additionally, the AXI clock needs to be at least 25% of pixel clock, > >>>>> + * but HSM ends up being the limiting factor. > >>>>> + * It seems that operating the pixel clock at 154 MHz still works. > >>>>> */ > >>>>> - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) > >>>>> + if (mode->clock > HSM_CLOCK_FREQ / (1000 * 106 / 100)) > >>>> Isn't hard-coding the HSM clock kind of limited, one could overclock it, isn't > >>>> it? I remember reading someone did it to support wider resolutions. > >>> Checking the docs it does state the restriction that Eric quotes. > >>> > >>> HDMI Core Clock (state machine clock) > >>> Most of the HDMI logic operates on that clock. It > >>> is asynchronous to system core clock and pixel > >>> clock. Source for this clock can be chosen from > >>> various PLLs in the chip. See CPR Manager for > >>> details. > >>> > >>> This clock is also used for clocking pixel valve > >>> when HDMI peripheral is used. See Pixel Valve > >>> for details.axi_clock >= hdmi_core_clock > 108% of > >>> pixel_clock. > >>> > >>> > >>> The default max pixel clock from the firmware side is 162MHz. > >>> > >>> In the firmware source we have a comment > >>> // HDMI state machine clock must be faster than pixel clock - > >>> infinitessimally faster tested in simulation. > >>> // Otherwise, exact value is unimportant - for HDMI operation. > >>> // hdmi state machine clock now derived from PLLC_PER (typ > >>> 500MHz, see relevant platform.c). > >>> // > >>> // However, CEC bit clock is derived from the HSM clock, and > >>> the (programmable) CEC timing table > >>> // is configured for a 40.00kHz CEC clock. > >>> const unsigned margin = 1*1000*1000; > >>> unsigned min_hsm_clock = margin + timings->pixel_freq; > >>> const unsigned max_hsm_clock_for_cec = max(163682864, > >>> hdmi_pixel_freq_limit); > >>> > >>> unsigned hdmi_state_machine_clock = max_hsm_clock_for_cec; > >>> > >>> So it adds 1MHz to the pixel clock for min_hsm_clock, but then doesn't > >>> use the value. > >>> Unless you do request a higher hdmi_pixel_freq_limit then the HSM is > >>> running at the same 163.68MHz that Eric's driver hard codes, and our > >>> max pixel clock is 162MHz. > >>> Keeping it a fixed value makes sorting the divider for CEC easier. > >>> > >>> Just adopting a 162MHz limit with a suitable comment is probably the > >>> most sensible move here, and Maxime's patches can pick up the same > >>> value. > >> It's kind of related, but one of the changes we did to support the > >> RPi4 is to change that rate calculation to increase the HSM clock for > >> pixel clocks higher than 148.5MHz (so typically 4k), while keeping it > >> as low as possible to reduce the power consumption. > >> > >> How would that interact with this change? > > I'd forgotten that your patches mean we change the HSM clock on Pi3. > > As you're aware, whilst I have some extra docs, many of them aren't as > > comprehensive as one would hope. We can go back to the Broadcom and > > RTL if absolutely necessary, but it's a pain. Broadcom don't > > necessarily have the personnel who designed the blocks still working > > there. > > > > Your patches appear to recompute the HSM clock based on pixel_clock * > > 108%, with a min of 108MHz, so effectively the same limit as the old > > version did by fixing the HSM rate. > > > > Checking the firmware for Pi4, it sets the HSM (M2MC) clock to > > pixel_rate * 1.01, clipped to 120MHz and 600Mhz. (Audio drops out if > > less than 108MHz. "Pick 120 to have an integer divider with some > > margin." I'd need to check which divider that is referring to). > > As noted above, the Pi3 firmware sets the HSM clock to 163.6MHz. > > > > I'd suggest that we: > > a) Increase max_pixel_clock for vc4 (Pi0-3) to 162MHz. > > b) Set HSM clock to 101% of the pixel clock, with a min of 120MHz > > (4k60 with pixel clock 594MHz would go to a 599.94MHz HSM clock which > > is still within range) > > c) Test it! I know we have some 1920x1200 monitors in the office (when > > I'm back in there). > > i don't think that i'm able to prepare those patches, but i'm happy to > test them. Conversations at slight cross-purposes. With the current driver we just need the limit lifting to 162MHz. My comment: > >>> Just adopting a 162MHz limit with a suitable comment is probably the > >>> most sensible move here above. And code change along the lines of: - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) + if (mode->clock > 162000000) with suitable comment. Maxime was querying the plan for how the increased pixel rate/HSM clock should be reflected in his patch set which adds Pi4 support to the vc4 driver. Dave > Thanks > Stefan > > > > > Whilst the firmware would appear to use a fixed HSM clock on Pi0-3, I > > don't anticipate there being any issue with varying it. It looks like > > there was the expectation of it being variable in the past, but > > someone has refactored it and either accidentally or deliberately > > given up on the idea. > > > > Dave > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Hi Stefan and Florian, On Tue, 2020-03-03 at 18:32 +0100, Nicolas Saenz Julienne wrote: > The register based driver turned out to be unstable, specially on RPi3a+ > but not limited to it. While a fix is being worked on, we roll back to > using firmware based scheme. > > Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver > instead of firmware") > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > --- now that the problem Stefan was seeing is being taken care of, I think it's fair to reconsider taking this patch. Maybe even adding a Tested-by by Stefan? Regards, Nicolas
Am 26.03.20 um 13:24 schrieb Nicolas Saenz Julienne: > Hi Stefan and Florian, > > On Tue, 2020-03-03 at 18:32 +0100, Nicolas Saenz Julienne wrote: >> The register based driver turned out to be unstable, specially on RPi3a+ >> but not limited to it. While a fix is being worked on, we roll back to >> using firmware based scheme. >> >> Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver >> instead of firmware") >> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >> --- > now that the problem Stefan was seeing is being taken care of, I think it's > fair to reconsider taking this patch. Maybe even adding a Tested-by by Stefan? after applying "drm/vc4: Fix HDMI mode validation" this commit doesn't cause any regression: Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Thanks > > Regards, > Nicolas
On 3/26/2020 10:24 AM, Stefan Wahren wrote: > Am 26.03.20 um 13:24 schrieb Nicolas Saenz Julienne: >> Hi Stefan and Florian, >> >> On Tue, 2020-03-03 at 18:32 +0100, Nicolas Saenz Julienne wrote: >>> The register based driver turned out to be unstable, specially on RPi3a+ >>> but not limited to it. While a fix is being worked on, we roll back to >>> using firmware based scheme. >>> >>> Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver >>> instead of firmware") >>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>> --- >> now that the problem Stefan was seeing is being taken care of, I think it's >> fair to reconsider taking this patch. Maybe even adding a Tested-by by Stefan? > > after applying "drm/vc4: Fix HDMI mode validation" this commit doesn't > cause any regression: > > Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Good, how do you like to see this applied? Do we need to ensure that drm/vc4: Fix HDMI mode validation is applied to Linus' tree before merging this one? Nicolas, should this be queued for 5.7 or 5.8 (I do not think the 5.7 PRs have been merged yet).
On Thu, 2020-03-26 at 17:35 -0700, Florian Fainelli wrote: > > On 3/26/2020 10:24 AM, Stefan Wahren wrote: > > Am 26.03.20 um 13:24 schrieb Nicolas Saenz Julienne: > > > Hi Stefan and Florian, > > > > > > On Tue, 2020-03-03 at 18:32 +0100, Nicolas Saenz Julienne wrote: > > > > The register based driver turned out to be unstable, specially on RPi3a+ > > > > but not limited to it. While a fix is being worked on, we roll back to > > > > using firmware based scheme. > > > > > > > > Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM > > > > driver > > > > instead of firmware") > > > > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > > > > --- > > > now that the problem Stefan was seeing is being taken care of, I think > > > it's > > > fair to reconsider taking this patch. Maybe even adding a Tested-by by > > > Stefan? > > > > after applying "drm/vc4: Fix HDMI mode validation" this commit doesn't > > cause any regression: > > > > Tested-by: Stefan Wahren <stefan.wahren@i2se.com> > > Good, how do you like to see this applied? Do we need to ensure that > drm/vc4: Fix HDMI mode validation is applied to Linus' tree before > merging this one? Nicolas, should this be queued for 5.7 or 5.8 (I do > not think the 5.7 PRs have been merged yet). Ideally both should be applied in the same time yes. I'm going to prepare an extra PR for v5.7 today. Regards, Nicolas
Hi, Am 27.03.20 um 01:35 schrieb Florian Fainelli: > > On 3/26/2020 10:24 AM, Stefan Wahren wrote: >> Am 26.03.20 um 13:24 schrieb Nicolas Saenz Julienne: >>> Hi Stefan and Florian, >>> >>> On Tue, 2020-03-03 at 18:32 +0100, Nicolas Saenz Julienne wrote: >>>> The register based driver turned out to be unstable, specially on RPi3a+ >>>> but not limited to it. While a fix is being worked on, we roll back to >>>> using firmware based scheme. >>>> >>>> Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver >>>> instead of firmware") >>>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> >>>> --- >>> now that the problem Stefan was seeing is being taken care of, I think it's >>> fair to reconsider taking this patch. Maybe even adding a Tested-by by Stefan? >> after applying "drm/vc4: Fix HDMI mode validation" this commit doesn't >> cause any regression: >> >> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> > Good, how do you like to see this applied? Do we need to ensure that > drm/vc4: Fix HDMI mode validation is applied to Linus' tree before > merging this one? Nicolas, should this be queued for 5.7 or 5.8 (I do > not think the 5.7 PRs have been merged yet). not sure how many are affected. I'm fine as long as both patches are applied to a tree. Regards
On Tue, 2020-03-03 at 18:32 +0100, Nicolas Saenz Julienne wrote: > The register based driver turned out to be unstable, specially on RPi3a+ > but not limited to it. While a fix is being worked on, we roll back to > using firmware based scheme. > > Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver > instead of firmware") > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> > --- Applied for-next. Regards, Nicolas
diff --git a/arch/arm/boot/dts/bcm2835-common.dtsi b/arch/arm/boot/dts/bcm2835-common.dtsi index 2b1d9d4c0cde..4119271c979d 100644 --- a/arch/arm/boot/dts/bcm2835-common.dtsi +++ b/arch/arm/boot/dts/bcm2835-common.dtsi @@ -130,7 +130,6 @@ v3d: v3d@7ec00000 { compatible = "brcm,bcm2835-v3d"; reg = <0x7ec00000 0x1000>; interrupts = <1 10>; - power-domains = <&pm BCM2835_POWER_DOMAIN_GRAFX_V3D>; }; vc4: gpu { diff --git a/arch/arm/boot/dts/bcm2835-rpi-common.dtsi b/arch/arm/boot/dts/bcm2835-rpi-common.dtsi new file mode 100644 index 000000000000..b78a57534611 --- /dev/null +++ b/arch/arm/boot/dts/bcm2835-rpi-common.dtsi @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * This include file covers the common peripherals and configuration between + * bcm2835, bcm2836 and bcm2837 implementations that interact with RPi's + * firmware interface. + */ + +#include <dt-bindings/power/raspberrypi-power.h> + +&v3d { + power-domains = <&power RPI_POWER_DOMAIN_V3D>; +}; diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi index 53bf4579cc22..0549686134ea 100644 --- a/arch/arm/boot/dts/bcm2835.dtsi +++ b/arch/arm/boot/dts/bcm2835.dtsi @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 #include "bcm283x.dtsi" #include "bcm2835-common.dtsi" +#include "bcm2835-rpi-common.dtsi" / { compatible = "brcm,bcm2835"; diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi index 82d6c4662ae4..b390006aef79 100644 --- a/arch/arm/boot/dts/bcm2836.dtsi +++ b/arch/arm/boot/dts/bcm2836.dtsi @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 #include "bcm283x.dtsi" #include "bcm2835-common.dtsi" +#include "bcm2835-rpi-common.dtsi" / { compatible = "brcm,bcm2836"; diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi index 9e95fee78e19..0199ec98cd61 100644 --- a/arch/arm/boot/dts/bcm2837.dtsi +++ b/arch/arm/boot/dts/bcm2837.dtsi @@ -1,5 +1,6 @@ #include "bcm283x.dtsi" #include "bcm2835-common.dtsi" +#include "bcm2835-rpi-common.dtsi" / { compatible = "brcm,bcm2837";
The register based driver turned out to be unstable, specially on RPi3a+ but not limited to it. While a fix is being worked on, we roll back to using firmware based scheme. Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware") Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- See https://github.com/raspberrypi/linux/issues/3046 for more reference. Note: I tested this on RPi3b, RPi3a+ and RPi2b. arch/arm/boot/dts/bcm2835-common.dtsi | 1 - arch/arm/boot/dts/bcm2835-rpi-common.dtsi | 12 ++++++++++++ arch/arm/boot/dts/bcm2835.dtsi | 1 + arch/arm/boot/dts/bcm2836.dtsi | 1 + arch/arm/boot/dts/bcm2837.dtsi | 1 + 5 files changed, 15 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/bcm2835-rpi-common.dtsi