From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754700AbbJNXfx (ORCPT ); Wed, 14 Oct 2015 19:35:53 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:28319 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753772AbbJNXfv (ORCPT ); Wed, 14 Oct 2015 19:35:51 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-c0-561ee6d46245 Subject: Re: [BUG] broken mixer after second resume from mem To: Tomeu Vizoso References: <561CDC33.7050103@collabora.com> <561DEE43.5040309@samsung.com> Cc: Javier Martinez Canillas , Sylwester Nawrocki , Tomasz Figa , Daniel Stone , Gustavo Padovan , Kukjin Kim , linux-samsung-soc , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" From: Krzysztof Kozlowski Message-id: <561EE6D4.6030803@samsung.com> Date: Thu, 15 Oct 2015 08:35:48 +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: Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsVy+t/xy7pXnsmFGVzYLWFx+N1VRotPq1vZ La79nsFm8fqFoUX/49fMFpseX2O1uLxrDpvFjPP7mCwOv2lntVi16w+jRd/aS2wO3B5/n19n 8dhxdwmjx9/ZrcweO2fdZffYtKqTzWPzknqPvi2rGD0+b5IL4IjisklJzcksSy3St0vgynh+ fxJTwSuxisaJ09kaGF8LdTFyckgImEic39DEDGGLSVy4t56ti5GLQ0hgKaPEk1/nWSGcL4wS 5/7NZwKpEhawkfg66yBQFQeHiICuxMkNUiBhIYFJjBI/foHVMwvcYJZYcnIOG0iCTcBYYvPy JWA2r4CWxN7Hr1lAbBYBVYlXd1+BxUUFIiQmTmhghagRlPgx+R5YDadAsMS9561gu5gF1CWm TMkFCTMLyEtsXvOWeQKjwCwkHbMQqmYhqVrAyLyKUTS1NLmgOCk911CvODG3uDQvXS85P3cT IyRKvuxgXHzM6hCjAAejEg/viQdyYUKsiWXFlbmHGCU4mJVEeLU3AIV4UxIrq1KL8uOLSnNS iw8xSnOwKInzzt31PkRIID2xJDU7NbUgtQgmy8TBKdXAmDTXlyXY2Pp2bafdNMGLHKZf1zx6 PM2Pkf3iZHP27zWyxS1BXFlyZj+5ktbOWVW1bdqRf5zNC7suCmw481m+Rfl59fczK4wleT+d aJzqIfvw7XTG5/4d2cVRAnHr5mnOnMIgXS5ydHXUzhdTyq9vn35AmWfSb72etcb1xbdn7hf+ olfeknYiXYmlOCPRUIu5qDgRAM/F552OAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14.10.2015 15:50, Tomeu Vizoso wrote: > On 14 October 2015 at 07:55, Krzysztof Kozlowski > 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