Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
@ 2020-03-03 17:32 Nicolas Saenz Julienne
  2020-03-03 18:17 ` Stefan Wahren
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-03 17:32 UTC (permalink / raw)
  To: Rob Herring, Mark Rutland, Florian Fainelli, Ray Jui,
	Scott Branden, bcm-kernel-feedback-list, Nicolas Saenz Julienne,
	Stefan Wahren, Eric Anholt
  Cc: devicetree, linux-kernel, wahrenst, linux-arm-kernel, linux-rpi-kernel

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

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";
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-03 17:32 [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D Nicolas Saenz Julienne
@ 2020-03-03 18:17 ` Stefan Wahren
  2020-03-03 18:37   ` Nicolas Saenz Julienne
  2020-03-26 12:24 ` Nicolas Saenz Julienne
  2020-03-27 12:58 ` Nicolas Saenz Julienne
  2 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-03 18:17 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Rob Herring, Mark Rutland,
	Florian Fainelli, Ray Jui, Scott Branden,
	bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, linux-rpi-kernel, linux-kernel, linux-arm-kernel, wahrenst

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";


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-03 18:17 ` Stefan Wahren
@ 2020-03-03 18:37   ` Nicolas Saenz Julienne
  2020-03-03 19:24     ` Stefan Wahren
  0 siblings, 1 reply; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-03 18:37 UTC (permalink / raw)
  To: Stefan Wahren, Rob Herring, Mark Rutland, Florian Fainelli,
	Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, wahrenst, linux-rpi-kernel, linux-arm-kernel, linux-kernel

[-- Attachment #1.1: Type: text/plain, Size: 1036 bytes --]

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.


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-03 18:37   ` Nicolas Saenz Julienne
@ 2020-03-03 19:24     ` Stefan Wahren
  2020-03-05 10:44       ` Nicolas Saenz Julienne
  0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-03 19:24 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Rob Herring, Mark Rutland,
	Florian Fainelli, Ray Jui, Scott Branden,
	bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, wahrenst, linux-rpi-kernel, linux-arm-kernel, linux-kernel

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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-03 19:24     ` Stefan Wahren
@ 2020-03-05 10:44       ` Nicolas Saenz Julienne
  2020-03-06 20:33         ` Stefan Wahren
  0 siblings, 1 reply; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-05 10:44 UTC (permalink / raw)
  To: Stefan Wahren, Rob Herring, Mark Rutland, Florian Fainelli,
	Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, wahrenst, linux-rpi-kernel, linux-arm-kernel, linux-kernel

[-- Attachment #1.1: Type: text/plain, Size: 2564 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-05 10:44       ` Nicolas Saenz Julienne
@ 2020-03-06 20:33         ` Stefan Wahren
  2020-03-09 15:41           ` Stefan Wahren
  0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-06 20:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Rob Herring, Mark Rutland,
	Florian Fainelli, Ray Jui, Scott Branden,
	bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, wahrenst, linux-rpi-kernel, linux-arm-kernel, linux-kernel

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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-06 20:33         ` Stefan Wahren
@ 2020-03-09 15:41           ` Stefan Wahren
  2020-03-09 19:22             ` Nicolas Saenz Julienne
  0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-09 15:41 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Rob Herring, Mark Rutland,
	Florian Fainelli, Ray Jui, Scott Branden,
	bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, wahrenst, linux-rpi-kernel, linux-arm-kernel, linux-kernel

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
>
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-09 15:41           ` Stefan Wahren
@ 2020-03-09 19:22             ` Nicolas Saenz Julienne
  2020-03-13 13:59               ` Stefan Wahren
  0 siblings, 1 reply; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-09 19:22 UTC (permalink / raw)
  To: Stefan Wahren, Rob Herring, Mark Rutland, Florian Fainelli,
	Ray Jui, Scott Branden, bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, wahrenst, linux-rpi-kernel, linux-arm-kernel, linux-kernel

[-- Attachment #1.1: Type: text/plain, Size: 1942 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-09 19:22             ` Nicolas Saenz Julienne
@ 2020-03-13 13:59               ` Stefan Wahren
  2020-03-15 19:16                 ` Stefan Wahren
  0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-13 13:59 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Rob Herring, Mark Rutland,
	Florian Fainelli, Ray Jui, Scott Branden,
	bcm-kernel-feedback-list, Eric Anholt
  Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel

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
>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-13 13:59               ` Stefan Wahren
@ 2020-03-15 19:16                 ` Stefan Wahren
  2020-03-16 12:40                   ` Nicolas Saenz Julienne
  0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-15 19:16 UTC (permalink / raw)
  To: Nicolas Saenz Julienne
  Cc: Florian Fainelli, Dave Stevenson, Eric Anholt, linux-rpi-kernel,
	linux-arm-kernel, Maxime Ripard

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;
-- 
2.7.4



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-15 19:16                 ` Stefan Wahren
@ 2020-03-16 12:40                   ` Nicolas Saenz Julienne
  2020-03-16 13:57                     ` Dave Stevenson
  0 siblings, 1 reply; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-16 12:40 UTC (permalink / raw)
  To: Stefan Wahren
  Cc: Florian Fainelli, Dave Stevenson, Eric Anholt, linux-rpi-kernel,
	linux-arm-kernel, Maxime Ripard

[-- Attachment #1.1: Type: text/plain, Size: 2997 bytes --]

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;



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-16 12:40                   ` Nicolas Saenz Julienne
@ 2020-03-16 13:57                     ` Dave Stevenson
  2020-03-20 14:43                       ` Nicolas Saenz Julienne
  2020-03-23 14:56                       ` Maxime Ripard
  0 siblings, 2 replies; 23+ messages in thread
From: Dave Stevenson @ 2020-03-16 13:57 UTC (permalink / raw)
  To: Nicolas Saenz Julienne
  Cc: Stefan Wahren, Florian Fainelli, Eric Anholt, linux-rpi-kernel,
	linux-arm-kernel, Maxime Ripard

 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;
>
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-16 13:57                     ` Dave Stevenson
@ 2020-03-20 14:43                       ` Nicolas Saenz Julienne
  2020-03-23 14:56                       ` Maxime Ripard
  1 sibling, 0 replies; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-20 14:43 UTC (permalink / raw)
  To: Dave Stevenson, Stefan Wahren
  Cc: Eric Anholt, Florian Fainelli, linux-rpi-kernel,
	linux-arm-kernel, Maxime Ripard

[-- Attachment #1.1: Type: text/plain, Size: 2525 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-16 13:57                     ` Dave Stevenson
  2020-03-20 14:43                       ` Nicolas Saenz Julienne
@ 2020-03-23 14:56                       ` Maxime Ripard
  2020-03-23 15:55                         ` Dave Stevenson
  1 sibling, 1 reply; 23+ messages in thread
From: Maxime Ripard @ 2020-03-23 14:56 UTC (permalink / raw)
  To: Dave Stevenson
  Cc: Stefan Wahren, Florian Fainelli, Eric Anholt, linux-rpi-kernel,
	Nicolas Saenz Julienne, linux-arm-kernel

[-- Attachment #1.1: Type: text/plain, Size: 5372 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-23 14:56                       ` Maxime Ripard
@ 2020-03-23 15:55                         ` Dave Stevenson
  2020-03-23 18:48                           ` Stefan Wahren
  0 siblings, 1 reply; 23+ messages in thread
From: Dave Stevenson @ 2020-03-23 15:55 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Stefan Wahren, Florian Fainelli, Eric Anholt, linux-rpi-kernel,
	Nicolas Saenz Julienne, linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-23 15:55                         ` Dave Stevenson
@ 2020-03-23 18:48                           ` Stefan Wahren
  2020-03-23 19:10                             ` Dave Stevenson
  0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-23 18:48 UTC (permalink / raw)
  To: Dave Stevenson, Maxime Ripard
  Cc: linux-arm-kernel, Eric Anholt, Florian Fainelli,
	linux-rpi-kernel, Nicolas Saenz Julienne

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-23 18:48                           ` Stefan Wahren
@ 2020-03-23 19:10                             ` Dave Stevenson
  0 siblings, 0 replies; 23+ messages in thread
From: Dave Stevenson @ 2020-03-23 19:10 UTC (permalink / raw)
  To: Stefan Wahren
  Cc: Florian Fainelli, Nicolas Saenz Julienne, Eric Anholt,
	Maxime Ripard, linux-arm-kernel, linux-rpi-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
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-03 17:32 [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D Nicolas Saenz Julienne
  2020-03-03 18:17 ` Stefan Wahren
@ 2020-03-26 12:24 ` Nicolas Saenz Julienne
  2020-03-26 17:24   ` Stefan Wahren
  2020-03-27 12:58 ` Nicolas Saenz Julienne
  2 siblings, 1 reply; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-26 12:24 UTC (permalink / raw)
  To: Stefan Wahren, Eric Anholt
  Cc: devicetree, Florian Fainelli, Scott Branden, Ray Jui,
	linux-kernel, bcm-kernel-feedback-list, wahrenst,
	linux-arm-kernel, linux-rpi-kernel

[-- Attachment #1.1: Type: text/plain, Size: 636 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-26 12:24 ` Nicolas Saenz Julienne
@ 2020-03-26 17:24   ` Stefan Wahren
  2020-03-27  0:35     ` Florian Fainelli
  0 siblings, 1 reply; 23+ messages in thread
From: Stefan Wahren @ 2020-03-26 17:24 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: devicetree, Florian Fainelli, Scott Branden, Ray Jui,
	linux-kernel, bcm-kernel-feedback-list, wahrenst,
	linux-arm-kernel, linux-rpi-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-26 17:24   ` Stefan Wahren
@ 2020-03-27  0:35     ` Florian Fainelli
  2020-03-27 10:41       ` Nicolas Saenz Julienne
  2020-03-27 11:24       ` Stefan Wahren
  0 siblings, 2 replies; 23+ messages in thread
From: Florian Fainelli @ 2020-03-27  0:35 UTC (permalink / raw)
  To: Stefan Wahren, Nicolas Saenz Julienne, Eric Anholt
  Cc: devicetree, Scott Branden, Ray Jui, linux-kernel,
	bcm-kernel-feedback-list, wahrenst, linux-arm-kernel,
	linux-rpi-kernel



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).
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-27  0:35     ` Florian Fainelli
@ 2020-03-27 10:41       ` Nicolas Saenz Julienne
  2020-03-27 11:24       ` Stefan Wahren
  1 sibling, 0 replies; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-27 10:41 UTC (permalink / raw)
  To: Florian Fainelli, Stefan Wahren, Eric Anholt
  Cc: devicetree, Scott Branden, Ray Jui, linux-kernel,
	bcm-kernel-feedback-list, wahrenst, linux-arm-kernel,
	linux-rpi-kernel

[-- Attachment #1.1: Type: text/plain, Size: 1447 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-27  0:35     ` Florian Fainelli
  2020-03-27 10:41       ` Nicolas Saenz Julienne
@ 2020-03-27 11:24       ` Stefan Wahren
  1 sibling, 0 replies; 23+ messages in thread
From: Stefan Wahren @ 2020-03-27 11:24 UTC (permalink / raw)
  To: Florian Fainelli, Nicolas Saenz Julienne, Eric Anholt
  Cc: devicetree, Scott Branden, Ray Jui, linux-kernel,
	bcm-kernel-feedback-list, wahrenst, linux-arm-kernel

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D
  2020-03-03 17:32 [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D Nicolas Saenz Julienne
  2020-03-03 18:17 ` Stefan Wahren
  2020-03-26 12:24 ` Nicolas Saenz Julienne
@ 2020-03-27 12:58 ` Nicolas Saenz Julienne
  2 siblings, 0 replies; 23+ messages in thread
From: Nicolas Saenz Julienne @ 2020-03-27 12:58 UTC (permalink / raw)
  To: Rob Herring, Mark Rutland, Florian Fainelli, Ray Jui,
	Scott Branden, bcm-kernel-feedback-list, Stefan Wahren,
	Eric Anholt
  Cc: devicetree, linux-kernel, wahrenst, linux-arm-kernel, linux-rpi-kernel

[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, back to index

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-03 17:32 [PATCH] ARM: dts: bcm283x: Use firmware PM driver for V3D Nicolas Saenz Julienne
2020-03-03 18:17 ` Stefan Wahren
2020-03-03 18:37   ` Nicolas Saenz Julienne
2020-03-03 19:24     ` Stefan Wahren
2020-03-05 10:44       ` Nicolas Saenz Julienne
2020-03-06 20:33         ` Stefan Wahren
2020-03-09 15:41           ` Stefan Wahren
2020-03-09 19:22             ` Nicolas Saenz Julienne
2020-03-13 13:59               ` Stefan Wahren
2020-03-15 19:16                 ` Stefan Wahren
2020-03-16 12:40                   ` Nicolas Saenz Julienne
2020-03-16 13:57                     ` Dave Stevenson
2020-03-20 14:43                       ` Nicolas Saenz Julienne
2020-03-23 14:56                       ` Maxime Ripard
2020-03-23 15:55                         ` Dave Stevenson
2020-03-23 18:48                           ` Stefan Wahren
2020-03-23 19:10                             ` Dave Stevenson
2020-03-26 12:24 ` Nicolas Saenz Julienne
2020-03-26 17:24   ` Stefan Wahren
2020-03-27  0:35     ` Florian Fainelli
2020-03-27 10:41       ` Nicolas Saenz Julienne
2020-03-27 11:24       ` Stefan Wahren
2020-03-27 12:58 ` Nicolas Saenz Julienne

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git