From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752389AbbJNFz2 (ORCPT ); Wed, 14 Oct 2015 01:55:28 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:42462 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750960AbbJNFzY (ORCPT ); Wed, 14 Oct 2015 01:55:24 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-47-561dee4a06b6 Subject: Re: [BUG] broken mixer after second resume from mem To: Tomeu Vizoso , javier@dowhile0.org, Sylwester Nawrocki , Tomasz Figa , Daniel Stone , Gustavo Padovan , Kukjin Kim , linux-samsung-soc@vger.kernel.org References: <561CDC33.7050103@collabora.com> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org From: Krzysztof Kozlowski X-Enigmail-Draft-Status: N1110 Message-id: <561DEE43.5040309@samsung.com> Date: Wed, 14 Oct 2015 14:55:15 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-version: 1.0 In-reply-to: <561CDC33.7050103@collabora.com> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42I5/e/4NV2vd7JhBocaBSwOv7vKaPFpdSu7 xbXfM9gsXr8wtOh//JrZYtPja6wWl3fNYbOYcX4fk8XhN+2sFqt2/WG06Ft7ic2B2+Pv8+ss HjvuLmH0+Du7ldlj56y77B6bVnWyeWxeUu/Rt2UVo8fnTXIBHFFcNimpOZllqUX6dglcGUc2 P2Mu+CJaMffdZ5YGxu+CXYycHBICJhLdT6YxQdhiEhfurWfrYuTiEBJYyijxd+cnJgjnC6NE z9yXYFXCAjYSX2cdBKsSETjAJLFw/i8WkISQgI5E79SzYDazgJvE385uVhCbTcBYYvPyJWwQ K+QkersngdXwCmhJ3OlfAjaURUBVYt79e2BxUYEIiYkTGlghagQlfkyGiHMK6ErMvfCHsYuR A2i+usSUKbkQq+QlNq95yzyBUXAWko5ZCFWzkFQtYGRexSiaWppcUJyUnmuoV5yYW1yal66X nJ+7iRESP192MC4+ZnWIUYCDUYmHN2O1bJgQa2JZcWXuIUYJDmYlEV6lZ0Ah3pTEyqrUovz4 otKc1OJDjNIcLErivHN3vQ8REkhPLEnNTk0tSC2CyTJxcEo1MLLv3CR2XzZotqjRHldH+Xn7 isMPLd/WFPKeedVO1kV3r10zlvqVbBKzQLR6jhnnhqTa5zqman/F1wQ8mpRYVPX4+pmSiLYP CmfETZSFix98/l2xxWfa9aI3H64cvh8ZtNpH4+7+KRyX7ucxq7e+snv9LKmj9Gyt1Tu5gjjW GYeqy4T7MvvfrlNiKc5INNRiLipOBABW/UEvmwIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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