From: Jon Hunter <jonathanh@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-tegra@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] ARM: tegra: Fix restoration of PLLM when exiting suspend
Date: Tue, 10 Dec 2019 14:29:19 +0000 [thread overview]
Message-ID: <8bf12fcd-02c7-4dc0-90e6-30009ab9f8e7@nvidia.com> (raw)
In-Reply-To: <20191210120909.GA2703785@ulmo>
On 10/12/2019 12:09, Thierry Reding wrote:
> On Tue, Dec 10, 2019 at 10:37:08AM +0000, Jon Hunter wrote:
>> The suspend entry and exit code for 32-bit Tegra devices assumes that
>> the PLLM (which is used to provide the clock for external memory)
>> is always enabled on entry to suspend. Hence, the current code always
>> disables the PLLM on entry to suspend and re-enables the PLLM on exit
>> from suspend.
>>
>> Since the introduction of the Tegra124 EMC driver by commit 73a7f0a90641
>> ("memory: tegra: Add EMC (external memory controller) driver"), which is
>> used to scale the EMC frequency, PLLM may not be the current clock
>> source for the EMC on entry to suspend and hence may not be enabled.
>> Always enabling the PLLM on exit from suspend can cause the actual
>> status on the PLL to be different from that reported by the common clock
>> framework.
>>
>> On kernels prior to v4.5, the code to set the rate of the PLLM had a
>> test to verify if the PLL was enabled and if the PLL was enabled,
>> setting the rate would fail. Since commit 267b62a96951
>> ("clk: tegra: pll: Update PLLM handling") the test to see if PLLM is
>> enabled was removed.
>>
>> With these earlier kernels, if the PLLM is disabled on entering suspend
>> and the EMC driver attempts to set the parent of the EMC clock to the
>> PLLM on exiting suspend, then the set rate for the PLLM will fail and in
>> turn cause the resume to fail.
>>
>> We should not be re-enabling the PLLM on resume from suspend unless it
>> was enabled on entry to suspend. Therefore, fix this by saving the state
>> of PLLM on entry to suspend and only re-enable it, if it was already
>> enabled.
>>
>> Fixes: 73a7f0a90641 ("memory: tegra: Add EMC (external memory controller) driver")
>> Cc: stable@vger.kernel.org
>>
>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>> ---
>> arch/arm/mach-tegra/sleep-tegra30.S | 33 +++++++++++++++++++++++------
>> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> Looks good to me. If I understand correctly we really only need this on
> v4.4 and earlier because the issue doesn't happen on later kernels
> because of that PLLM handling update change that you mentioned, right?
Yes.
> At the same time, this is the correct thing to do even on more recent
> kernels because we currently rely on the PLLM status check being absent
> for this to work.
Yes exactly.
> So it seems like the safest option going forward is to apply this patch
> to all versions, so that we don't rely on any assumptions.
>
> Do you agree?
Yes, my feeling is that we should apply to mainline and then it should
be picked-up for stable.
Cheers
Jon
--
nvpublic
next prev parent reply other threads:[~2019-12-10 14:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 10:37 [PATCH] ARM: tegra: Fix restoration of PLLM when exiting suspend Jon Hunter
2019-12-10 12:09 ` Thierry Reding
2019-12-10 14:29 ` Jon Hunter [this message]
2019-12-10 14:32 ` Jon Hunter
2019-12-10 19:28 ` Dmitry Osipenko
2019-12-10 20:29 ` Dmitry Osipenko
2019-12-11 8:50 ` Peter De Schrijver
2019-12-12 22:18 ` Dmitry Osipenko
2019-12-17 14:19 ` Jon Hunter
2019-12-17 14:28 ` Dmitry Osipenko
[not found] ` <57264acd-2623-9e9f-53c6-3b4cd3991315-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-06-12 15:20 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8bf12fcd-02c7-4dc0-90e6-30009ab9f8e7@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox