On 14 October 2015 at 07:55, Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx> wrote: > On 13.10.2015 19:25, Tomeu Vizoso wrote: >> Hi, >> >> have been hunting down a bug on exynos5250-snow which caused both HDMI >> and LVDS output to be broken after the second resume (with suspend to >> mem, but not to idle). >> >> What I have found is that when powering down the DISP1 power domain >> while suspending for the second time, the contents of the SRC_TOP3 >> register change from 0x1110550 to 0x1110500. IIUIC, this means that >> ACLK_200_DISP1 is reparented to XXTI. >> >> When the CPU comes up again, that register contains 0x1110550 again, but >> it's set to 0x1110500 by the code that restores clk registers when resuming: >> >> First suspend: >> >> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before >> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - after >> exynos5250_clk_suspend: SRC_TOP3 1110550 >> exynos5250_clk_resume: SRC_TOP3 1110550 - before >> exynos5250_clk_resume: SRC_TOP3 1110550 - after >> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before >> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - after >> >> >> Second suspend: >> >> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before >> exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - after >> exynos5250_clk_suspend: SRC_TOP3 1110500 >> exynos5250_clk_resume: SRC_TOP3 1110550 - before >> exynos5250_clk_resume: SRC_TOP3 1110500 - after >> exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - before >> exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - after >> > > I am assuming you are talking about current linux-next. The actual > reparent happens in exynos_pd_power which would indicate the exynos pd > clock reparenting code. However the domains for Exynos5250 don't have > any clocks set up for reparenting... which actually might be the issue. > These clocks should be probably reparented - as it is done for other > platforms - look at 5420 example (they are glitch-free on both of SoCs). > > I've seen a such issues before. The problem is that after some time I > tend to forget the needed workaround and solution. :) > > Try with reparenting necessary clocks. On other platform for some kind > of similar issue the reset was required for the IP block - DECON > (actually the mux could not stabilize there which can be observed in one > of STATUS registers for mux). > > Let me know if explanation above is not detailed enough. Thanks for the reply, I looked at downstream and saw that two clocks are being reparented and that seems to fix things. Will send a patch later today. Regards, Tomeu >> I have no idea of why it happens on the second suspend, and also don't >> know why it doesn't happen when suspending to idle. > > As for the idle - domains are probably not gated so the problems just > does not exist. > > BTW as this is display, you can CC some Samsung guys from DRM... they > know a lot on these stuff. :) > > Best regards, > Krzysztof > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |