From: Dmitry Osipenko <digetx@gmail.com>
To: Jon Hunter <jonathanh@nvidia.com>,
Thierry Reding <thierry.reding@gmail.com>,
Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 4/4] ARM: tegra: Clear EMC interrupts on resume from LP1 on Tegra30+
Date: Tue, 20 Nov 2018 01:35:34 +0300 [thread overview]
Message-ID: <60898d23-63a1-caf5-8fd4-2bbd7bb6aaab@gmail.com> (raw)
In-Reply-To: <9c085248-41df-c8be-294d-6bf8b95c1085@nvidia.com>
On 20.11.2018 1:00, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> Two interrupts are raised on resume from LP1 on Tegra30+: first is the
>> clock change completed interrupt which is set after updating timing
>> configuration, second is DLL alarm interrupt which is set when DLL
>> starts re-calibration after being reset. Clear these two interrupts
>> in the end of exiting from the self-refresh mode for consistency, that
>> will also allow to not receive spurious interrupts in the EMC driver
>> after resume from suspend.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>> arch/arm/mach-tegra/sleep-tegra30.S | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
>> index 828f6c37afde..78c6e9fb56e7 100644
>> --- a/arch/arm/mach-tegra/sleep-tegra30.S
>> +++ b/arch/arm/mach-tegra/sleep-tegra30.S
>> @@ -26,6 +26,7 @@
>> #include "irammap.h"
>> #include "sleep.h"
>>
>> +#define EMC_INTSTATUS 0x0
>> #define EMC_CFG 0xc
>> #define EMC_ADR_CFG 0x10
>> #define EMC_TIMING_CONTROL 0x28
>> @@ -44,6 +45,9 @@
>> #define EMC_XM2VTTGENPADCTRL 0x310
>> #define EMC_XM2VTTGENPADCTRL2 0x314
>>
>> +#define EMC_CLKCHANGE_COMPLETE_INT (1 << 4)
>> +#define EMC_DLL_ALARM_INT (1 << 7)
>> +
>> #define MC_EMEM_ARB_CFG 0x90
>>
>> #define PMC_CTRL 0x0
>> @@ -539,6 +543,9 @@ zcal_done:
>>
>> emc_timing_update r1, r0
>>
>> + mov r1, #(EMC_CLKCHANGE_COMPLETE_INT | EMC_DLL_ALARM_INT)
>> + str r1, [r0, #EMC_INTSTATUS] @ clear interrupts
>> +
>> /* Tegra114 had dual EMC channel, now config the other one */
>> cmp r10, #TEGRA114
>> bne __no_dual_emc_chanl
>>
>
> Where are these interrupts enabled? I did not see where they are
> enabled. I see that the Tegra24 EMC driver does poll these, but it did
> not look like they were enabled. If they are enabled, I wondering if
> they should be masked on entering self-refresh?
EMC interrupt is not enabled on Tegra124. IIRC, it doesn't use the interrupt at all in the driver. Indeed, T124 EMC driver polls the interrupt status, but it clears the status before starting to poll. Probably I was just thinking about to write T30 EMC driver at that time and to utilize the interrupt..
Seems it should be okay to drop this patch for now, but maybe then we will have to return to it sometime later. Up to you to decide.
next prev parent reply other threads:[~2018-11-19 22:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 18:54 [PATCH v1 0/4] EMC fixes for Tegra30+ Dmitry Osipenko
2018-08-30 18:54 ` [PATCH v1 1/4] ARM: tegra: Fix missed EMC registers latching on resume from LP1 on Tegra30+ Dmitry Osipenko
2018-11-19 21:27 ` Jon Hunter
2018-11-19 21:51 ` Jon Hunter
2018-08-30 18:54 ` [PATCH v1 2/4] ARM: tegra: Fix DRAM refresh-interval clobbering on resume from LP1 on Tegra30 Dmitry Osipenko
2018-11-19 21:34 ` Jon Hunter
2018-11-19 22:09 ` Dmitry Osipenko
2018-11-19 22:32 ` Dmitry Osipenko
2018-11-20 10:26 ` Jon Hunter
2018-11-20 11:22 ` Dmitry Osipenko
2018-11-20 10:25 ` Jon Hunter
2018-11-20 10:27 ` Jon Hunter
2018-08-30 18:54 ` [PATCH v1 3/4] ARM: tegra: Restore memory arbitration on resume from LP1 on Tegra30+ Dmitry Osipenko
2018-11-19 21:51 ` Jon Hunter
2018-08-30 18:54 ` [PATCH v1 4/4] ARM: tegra: Clear EMC interrupts " Dmitry Osipenko
2018-11-19 22:00 ` Jon Hunter
2018-11-19 22:35 ` Dmitry Osipenko [this message]
2018-11-20 10:27 ` Jon Hunter
2018-11-20 11:32 ` Dmitry Osipenko
2018-10-15 12:34 ` [PATCH v1 0/4] EMC fixes for Tegra30+ Dmitry Osipenko
2018-11-18 22:06 ` Dmitry Osipenko
2018-11-19 15:42 ` Jon Hunter
2018-11-19 17:05 ` Dmitry Osipenko
2018-11-19 21:26 ` Jon Hunter
2018-11-19 22:48 ` 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=60898d23-63a1-caf5-8fd4-2bbd7bb6aaab@gmail.com \
--to=digetx@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=pdeschrijver@nvidia.com \
--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;
as well as URLs for NNTP newsgroup(s).