[v3] drm: rockchip: hdmi: enable higher resolutions than FHD

[Yann Dirson]

Vicente wrote:
> This patch series enable a QHD HDMI monitor to work at native resolution.
> Tested on a Sapphire board with RK3399 connected to a Q27q-10 monitor at 2560x1440 at 60

Which kernel did you test this patch series on ?

I am trying to get this to work on our rk3999 hardware, with a Dell
s2719dgf with 2560x1440 at 60 and 2560x1440 at 144, both of which do work
with Rockchip's 4.4 branch.

If I'm applying this patch to 5.10.18, everything breaks:
- the newly-shown 2560x1440 mode is selected by default, but dclk_vop0
is set to 200000 not 241500, and screen stays black
- if I switch to 1920x1080 with xrandr I get no video output either
- if then I request to switch back to 2560x1440, I can see dclk_vop0
getting set back to 200000, and after a couple of seconds get
something like the following, freezing the board:

[   97.504469] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[   98.528471] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[   99.552469] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[  100.576469] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[  101.600468] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[  101.601011] cpu cpu4: _set_opp_voltage: failed to set voltage
(1200000 1200000 1200000 mV): -110
[  101.601793] cpufreq: __target_index: Failed to change cpu frequency: -110
[  117.496429] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[  117.496975] rcu:     0-...0: (10 ticks this GP)
idle=bf6/1/0x4000000000000002 softirq=716/718 fqs=415
[  117.497765] rcu:     5-...0: (6 ticks this GP)
idle=916/1/0x4000000000000000 softirq=613/614 fqs=415
[  117.498547]  (detected by 2, t=5252 jiffies, g=677, q=6)

It also tends to cause timeouts right on boot afterwards if I don't
leave the board unplugged for a few seconds.


If I apply the same patch to 5.4.88, the clock rate when switching to
1080p gets a value you may have seen yourself given your previous
patches, and the screen does not get the signal (and I don't even need
to switch back to 1440p to hang the platform):

root at shadow-ghost:~# cat /sys/kernel/debug/clk/dclk_vop0/clk_rate
148500999
root at shadow-ghost:~# [   60.986455] rcu: INFO: rcu_preempt detected
stalls on CPUs/tasks:
[   60.987001] rcu:     0-...0: (4 ticks this GP)
idle=2ce/1/0x4000000000000002 softirq=513/513 fqs=2625
[   60.987791] rcu:     2-...0: (4 ticks this GP)
idle=862/1/0x4000000000000000 softirq=519/520 fqs=2625
[   60.988579]  (detected by 1, t=5252 jiffies, g=529, q=1)
[   60.989043] Task dump for CPU 0:
[   60.989327] irq/40-ff940000 R  running task        0   161      2 0x0000002a
[   60.989945] Call trace:
[   60.990172]  __switch_to+0xd8/0x120
[   60.990482]  __wake_up_common_lock+0x78/0xc0
[   60.990857]  __wake_up+0x14/0x20
[   60.991143]  netlink_broadcast_filtered+0x2f4/0x3dc
[   60.991570]  netlink_broadcast+0x14/0x20
[   60.991914]  0xffff80001180bae0
[   60.992190] Task dump for CPU 2:
[   60.992472] udevd           R  running task        0   170      1 0x00000002
[   60.993088] Call trace:
[   60.993306]  __switch_to+0xd8/0x120
[   60.993612]  0xffff000079a60c80
[   60.993889]  0xaaaafc79fcf8
[   60.994135]  0x65


OTOH, if I apply the same patch to 4.19.177, I have no trouble
switching to 1080p, and when I ask to switch back to 1440p the screen
does get a signal, although it reports 1903x1440 50Hz, probably due to
the clock rate getting capped to 200000.

Any idea where those hangs with kernels 5.x would come from ?  That
could help cutting down bisect time on this :)


Other experiments show that dclk_vop0 on 4.4rk gets its 241500 rate
from vpll (via dclk_vop0_div), but on mainline vpll apparently refuses
to provide this (proposing just 148500 instead) so it is cpll of gpll
which gets to provide a 200000 kHz clock.

What could be the reason for this ?

Best regards,
-- 
Yann Dirson <yann at blade-group.com>
Blade / Shadow -- http://shadow.tech