On 14.10.2015 15:50, Tomeu Vizoso wrote: > 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. > Great! Happy to hear that! Best regards, Krzysztof -- 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
 |