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

[Yann Dirson]

(resent after subscribing, seemed stuck in moderation)

Le jeu. 11 mars 2021 à 12:08, Yann Dirson
<yann.dirson at blade-group.com> a écrit :
>
> 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



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