Hi Enric and Doug, Yesterday I managed to build chromeOS kernel version 4.4.174 and boot with it without any serious problem. Current uptime is over 21 hour and it works well, i.e. without problem related to rockchip-dp/analogix driver, even after suspend-to-ram/resume few times. I will let it few days to work without shutdown (without poweroff or reboot) to see will it work or will any problem appear. (beside this analogix issue, looks like also emmc works fine with this kernel, although it doesn't work fine with mainline kernels. but this is not related). If the machine work for three or more days without problem I will report to you. Maybe someone experienced in video/gpu drivers programming could make diffs and make it to work with mainline kernels. Thank you help On Tue, 2020-04-14 at 18:17, Enric Balletbo Serra wrote: > 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
