Hi Doug and Milan, Thanks for providing this information. Missatge de Doug Anderson <dianders@xxxxxxxxxxxx> del dia dl., 13 d’abr. 2020 a les 17:23: > > Hi, > > On Fri, Apr 10, 2020 at 12:29 PM Milan P. Stanić <mps@xxxxxxxxxxx> wrote: > > > > Hi, > > > > On Fri, 2020-04-10 at 08:28, Doug Anderson wrote: > > > Hi, > > > > > > On Fri, Apr 10, 2020 at 5:56 AM Enric Balletbo Serra > > > <eballetbo@xxxxxxxxx> wrote: > > > > > > > > Hi Milan, > > > > > > > > Right, this is an annoying issue but also known, unfortunately, I > > > > personally didn't have time to look at. but it is in my TODO. > > > > > > Random shot in the dark, but any chance somehow your PHY clock and > > > PCLK for the eDP don't match? If they don't then (IIRC) you'll get > > > random failures to access eDP registers. > > > > > > Some history in <https://crrev.com/c/433393>. It looks like the > > > changes in that patch are upstream but if something else happened to > > > make your PHY and PCLK mismatch it could cause similar symptoms. > > > > > > ...of course it's always possible (probable) that it's something > > > different, but since that was such a weird and hard-to-track-down > > > problem I figured I'd at least make sure it wasn't that. > > > > Not sure I understood (I'm not graphic hardware programmer) but I > > changed arch/arm64/boot/dts/rockchip/rk3399.dtsi file around line > > 1367 (current mainline kernel), this: > > assigned-clocks = > > <&cru PLL_GPLL>, <&cru PLL_CPLL>, > > <&cru PLL_NPLL>, > > <&cru ACLK_PERIHP>, <&cru HCLK_PERIHP>, > > <&cru PCLK_PERIHP>, > > <&cru ACLK_PERILP0>, <&cru HCLK_PERILP0>, > > <&cru PCLK_PERILP0>, <&cru ACLK_CCI>, > > <&cru HCLK_PERILP1>, <&cru PCLK_PERILP1>, > > <&cru ACLK_VIO>, <&cru ACLK_HDCP>, > > <&cru ACLK_GIC_PRE>, > > <&cru PCLK_DDR>; > > assigned-clock-rates = > > <594000000>, <800000000>, > > <1000000000>, > > <150000000>, <75000000>, > > <37500000>, > > <100000000>, <100000000>, > > <50000000>, <600000000>, > > <100000000>, <50000000>, > > <400000000>, <400000000>, > > <200000000>, > > <200000000>; > > > > and changed <594000000> to <600000000> > > build kernel and it boots but display is blank after boot. > > I think kevin already overrides those clocks in its dts. I was more > thinking of looking at "/sys/kernel/debug/clk/clk_summary" and seeing > if there was a clock mismatch. > Although I don't discard that this would be the problem, I think it is more a racing problem with the tracking status of the crtc active and self_refresh_active variables during the suspend path and PSR. I.e, if I apply the following patch which sets a delay of 100ms in the delayed entry work to entry the PSR state (similar to what we had before the commit I mentioned), suspend resume works as expected for me. @@ -218,7 +234,7 @@ void drm_self_refresh_helper_alter_state(struct drm_atomic_state *state) mutex_unlock(&sr_data->avg_mutex); mod_delayed_work(system_wq, &sr_data->entry_work, - msecs_to_jiffies(delay)); + msecs_to_jiffies(100)); } } Some more info is that I was not able to reproduce the problem by triggering an 'echo mem > /sys/power/state' The only way I can reproduce the issue is doing as 'systemctl supend' command, which if I am not mistaken does a DPMS off before suspending. - Enric > -Doug _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
