linux-kernel - Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5523C5F5.6000604@collabora.co.uk>
Date:	Tue, 07 Apr 2015 13:56:37 +0200
From:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
To:	Abhilash Kesavan <kesavan.abhilash@...il.com>
CC:	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Mike Turquette <mturquette@...aro.org>,
	Kukjin Kim <kgene@...nel.org>, Olof Johansson <olof@...om.net>,
	Doug Anderson <dianders@...omium.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Kevin Hilman <khilman@...aro.org>,
	Tyler Baker <tyler.baker@...aro.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is
 enabled during suspend

On 04/07/2015 12:59 PM, Javier Martinez Canillas wrote:
> 
> So IIUC the CG_STATUS0 bits were a red herring and the real problem
> is that the aclk266_g2d needs to be enabled during suspend (although
> we still don't know why).
> 
> It seems were are at a dead end now. Without being able to ask the HW
> Samsung folks we would never know what's going on here...
> 

Ok, I found another interesting data point. ACLK_266_G2D has as
constraints that CG_STATUS0[21:22] needs to be 0 before gating
the clock and as I mentioned before those are associated with
the SSS and SSS_SLIM HW crypto modules according the docs I've.

So I looked at the clock used by the SSS module and found that
CLK_SSS parent is ACLK_266_G2D but CLK_SSS is never requested
since drivers/crypto/s5p-sss.c isn't built for exynos_defconfig.

Enabling CONFIG_CRYPTO_DEV_S5P makes the system to resume without
any patches since the sss clock prevents aclk266_g2d to be gated.

But I wanted to know if it was really aclk266_g2d that was needed
or the actual sss clock since the kernel didn't manage that clock
without the driver enabled.

So I disabled the sss clock before trying a S2R:

# devmem 0x10018800 32 0xFFFFFFFB
(CLK_SSS in CLK_GATE_IP_G2D is gated)

and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
its default value on S2R so maybe that is why it works anyways?

# devmem 0x10018800
0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)

Does this shed any more light? Could the problem be that the sss
clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
required for S2R or is just that CLK_SSS prevents the parent to
be gated and so it is another red herring?

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/