Re: [BUG] broken mixer after second resume from mem

[Krzysztof Kozlowski]

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.

> 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/