linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 2/4] ARM: tegra: Fix DRAM refresh-interval clobbering on resume from LP1 on Tegra30
Date: Tue, 20 Nov 2018 01:09:20 +0300	[thread overview]
Message-ID: <cee4398b-edb8-4c9d-7830-6f52fffd6e1c@gmail.com> (raw)
In-Reply-To: <4f61bf5f-0aa8-df6e-109b-194b08f3374e@nvidia.com>

On 20.11.2018 0:34, Jon Hunter wrote:
> 
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> The DRAM refresh-interval is getting erroneously set to "1" on exiting
>> from memory self-refreshing mode. The clobbered interval causes the
>> "refresh request overflow timeout" error raised by the External Memory
>> Controller on exiting from LP1 on Tegra30.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>>  arch/arm/mach-tegra/sleep-tegra30.S | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
>> index 801fe58978ae..99ac9c6dcf7c 100644
>> --- a/arch/arm/mach-tegra/sleep-tegra30.S
>> +++ b/arch/arm/mach-tegra/sleep-tegra30.S
>> @@ -29,7 +29,6 @@
>>  #define EMC_CFG				0xc
>>  #define EMC_ADR_CFG			0x10
>>  #define EMC_TIMING_CONTROL		0x28
>> -#define EMC_REFRESH			0x70
>>  #define EMC_NOP				0xdc
>>  #define EMC_SELF_REF			0xe0
>>  #define EMC_MRW				0xe8
>> @@ -459,7 +458,6 @@ emc_wait_auto_cal_onetime:
>>  	cmp	r10, #TEGRA30
>>  	streq	r1, [r0, #EMC_NOP]
>>  	streq	r1, [r0, #EMC_NOP]
>> -	streq	r1, [r0, #EMC_REFRESH]
>>  
>>  	emc_device_mask r1, r0
> 
> This does look incorrect and it appears Tegra20 has the same bug.

Indeed.. somehow this doesn't cause any problems on T20. Maybe this affects only specific timing configurations and it's just a luck that "refresh overflow" isn't getting raised.

> However, looking at the EMC_REFRESH register it appears that bits 5:0
> are the REFRESH_LO and bits 15:6 are the refresh interval. So this seems
> to imply the interval is set to 0 and not 1. So maybe the commit message
> needs to be fixed up.

Do you mean that EMC_REFRESH is a fractional value?

> The other question I have, should we be restoring the refresh value here
> somewhere?

The EMC_REFRESH value isn't altered on enter/exit self-refresh, at least on Tegra30.. very likely it should be the same for other gens.

  reply	other threads:[~2018-11-19 22:09 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 [this message]
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
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=cee4398b-edb8-4c9d-7830-6f52fffd6e1c@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).