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]

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

2015-04-01 6:03 GMT+02:00 Kevin Hilman <khilman@...nel.org>:
> Abhilash Kesavan <kesavan.abhilash@...il.com> writes:
>
>> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@...nel.org> wrote:
>>> Javier Martinez Canillas <javier.martinez@...labora.co.uk> writes:
>>>
>>> [...]
>>>
>>>> Unfortunately I don't fully understand why this clock needs to be
>>>> enabled. It would be good if someone at Samsung can explain in more
>>>> detail what the real problem really is.
>>>
>>> +1
>>>
>>> Maybe Abhilash can shed some light here?
>>>
>>> We really should know *why* this is needed because having the fix in the
>>> clock driver just doesn't seem right.  It seems like the DMA driver
>>> should be managing this clock.
>>
>> I think my last mail might not have reached you (was accidentally sent
>> as html).
>
> Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
> research and reporting back.
>
>> We are gating the aclk266_g2d clock without checking the
>> CG_STATUS0 register bits as specified in the UM. It looks like we need
>> to keep several clocks alive or gate them only after checking the
>> CG_STATUSx register bits.
>
> I dont' know much about this clock hardware, but to me it sounds like a
> clock driver bug.  The suspend fix Javier is proposing would fix it, but
> to me it sounds like the clock driver needs to actually start checking
> these CG_STATUSx bits before gating clocks.
>
> Otherwise, we might fix this current bug but a similar one will come and
> bite us another day.

Actually it looks kind a similar to issue with adma/mau_epll clocks:
https://lkml.org/lkml/2014/12/5/291

In that case runtime PM for pl330 caused adma clock to be gated. This
lead to gating its parent clock - mau_epll. The clock hierarchy is
strange for maudio domain. Basically mau_epll is needed to access
maudio clocks however these clocks are not children of mau_epll.

I think we should not enable the mdma0 but instead we should find the
proper parent which needs to be enabled.

Anyway it is kind of annoying (or funny if one has sense of black
humour) that two issues are exposed by runtime PM for pl330 driver.

Best regards,
Krzysztof
--
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/