From: Peter Rosin <peda@axentia.se>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
Wenyou Yang <wenyou.yang@atmel.com>,
"nicolas.ferre@atmel.com" <nicolas.ferre@atmel.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alexandre.belloni@free-electrons.com"
<alexandre.belloni@free-electrons.com>,
"sylvain.rochet@finsecur.com" <sylvain.rochet@finsecur.com>,
"linux@maxim.org.za" <linux@maxim.org.za>
Subject: RE: [PATCH v3 03/13] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories.
Date: Tue, 27 Jan 2015 12:14:11 +0000 [thread overview]
Message-ID: <fd04e7c80f6841368ea1953d544f3386@EMAIL.axentia.se> (raw)
In-Reply-To: <54C7675D.8000204@cogentembedded.com>
Sergei Shtylyov wrote:
> Hello.
Hi!
> On 1/27/2015 8:53 AM, Wenyou Yang wrote:
>
> > From: Peter Rosin <peda@axentia.se>
>
> > The DDRSDR controller fails miserably to put LPDDR1 memories in
> > self-refresh. Force the controller to think it has DDR2 memories
> > during the self-refresh period, as the DDR2 self-refresh spec is
> > equivalent to LPDDR1, and is correctly implemented in the controller.
>
> > Assume that the second controller has the same fault, but that is
> > untested.
>
> > Signed-off-by: Peter Rosin <peda@axentia.se>
> > Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> > ---
> > arch/arm/mach-at91/pm_slowclock.S | 43
> +++++++++++++++++++++++++++++++-----
> > include/soc/at91/at91sam9_ddrsdr.h | 2 +-
> > 2 files changed, 39 insertions(+), 6 deletions(-)
>
> > diff --git a/arch/arm/mach-at91/pm_slowclock.S
> > b/arch/arm/mach-at91/pm_slowclock.S
> > index e2bfaf5..1155217 100644
> > --- a/arch/arm/mach-at91/pm_slowclock.S
> > +++ b/arch/arm/mach-at91/pm_slowclock.S
> [...]
> > @@ -108,14 +118,26 @@ ddr_sr_enable:
> >
> > /* figure out if we use the second ram controller */
> > cmp ramc1, #0
> > - ldrne tmp2, [ramc1, #AT91_DDRSDRC_LPR]
> > - strne tmp2, .saved_sam9_lpr1
> > - bicne tmp2, #AT91_DDRSDRC_LPCB
> > - orrne tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH
> > + beq ddr_no_2nd_ctrl
> > +
> > + ldr tmp2, [ramc1, #AT91_DDRSDRC_MDR]
> > + str tmp2, .saved_sam9_mdr1
> > + bic tmp2, tmp2, #~AT91_DDRSDRC_MD
> > + cmp tmp2, #AT91_DDRSDRC_MD_LOW_POWER_DDR
> > + ldreq tmp2, [ramc1, #AT91_DDRSDRC_MDR]
> > + biceq tmp2, tmp2, #AT91_DDRSDRC_MD
>
> Didn't you forget ~? Either that, or ~ above is not needed, I think.
The code is correct, the first bic with ~ clears bits not in the relevant
field in order to compare if LPDDR mode is active. The second bic(eq)
w/o ~ clears the field, to make way for the bits in the below orreq
when actually changing the register content into DDR2 mode.
> > + orreq tmp2, tmp2, #AT91_DDRSDRC_MD_DDR2
> > + streq tmp2, [ramc1, #AT91_DDRSDRC_MDR]
> > +
> > + ldr tmp2, [ramc1, #AT91_DDRSDRC_LPR]
> > + str tmp2, .saved_sam9_lpr1
> > + bic tmp2, #AT91_DDRSDRC_LPCB
>
> Didn't you forget ~? And isn't it 3-operand instruction (as seen in the above
> code)?
The logic for the LPR register is from the old code, the "only" thing
I did to it was changing the instruction sequence to not have the
???ne form, i.e. ldrne, strne, bicne, orrne became ldr, str, bic, orr
with a jump around it instead. So, the original code also had a two
argument bic(ne), which indeed is strange, and I don't know why
there is no warning from the assembler. Since there is no warning,
my guess is that the assembler somehow mends it? Or does the
patch actually break the second controller? It would be a surprise
it the assembler handles 2-operand bicne differently from a
2-operand bic, no?
> > + orr tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH
>
> Only 2 operands?
Same argument as above. I didn't touch it (sort of...)
Should I update the patch and fix this collateral 2-operand problem as
well? To me, it feels like a separate patch, no?
> [...]
>
> WBR, Sergei
Cheers,
Peter
next prev parent reply other threads:[~2015-01-27 12:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-27 5:50 [PATCH v3 00/13] AT91 pm cleanup for 3.20 Wenyou Yang
2015-01-27 5:51 ` [PATCH v3 01/13] pm: at91: pm_slowclock: fix suspend/resume hang up in timeouts Wenyou Yang
2015-01-27 5:52 ` [PATCH v3 02/13] pm: at91: pm_slowclock: remove clocks which are already stopped when entering slow clock mode Wenyou Yang
2015-01-27 5:53 ` [PATCH v3 03/13] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories Wenyou Yang
2015-01-27 10:24 ` Sergei Shtylyov
2015-01-27 12:14 ` Peter Rosin [this message]
2015-01-27 21:55 ` Peter Rosin
2015-01-27 22:43 ` Russell King - ARM Linux
2015-01-27 5:54 ` [PATCH v3 04/13] pm: at91: pm_slowclock: remove the unused code related with SLOWDOWN_MASTER_CLOCK Wenyou Yang
2015-01-27 5:55 ` [PATCH v3 05/13] pm: at91: move the copying the sram function to the sram initializationi phase Wenyou Yang
2015-01-27 5:56 ` [PATCH v3 06/13] ARM: at91: move select SRAM to ARCH_AT91 Wenyou Yang
2015-01-27 5:57 ` [PATCH v3 07/13] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK Wenyou Yang
2015-01-27 9:55 ` Sylvain Rochet
2015-01-27 10:07 ` Alexandre Belloni
2015-01-27 10:13 ` Sylvain Rochet
2015-01-27 5:58 ` [PATCH v3 08/13] pm: at91: the standby mode uses the same sram function as the suspend to memory mode Wenyou Yang
2015-01-27 10:08 ` Sylvain Rochet
2015-01-27 10:11 ` Yang, Wenyou
2015-01-27 5:59 ` [PATCH v3 09/13] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S Wenyou Yang
2015-01-27 5:59 ` [PATCH v3 10/13] pm: at91: rename function name: at91_slow_clock()-->at91_pm_suspend_sram_fn Wenyou Yang
2015-01-27 6:00 ` [PATCH v3 11/13] pm: at91: remove the at91_xxx_standby() function definitions in the pm.h Wenyou Yang
2015-01-27 6:01 ` [PATCH v3 12/13] pm: at91: setup: remove the struct ramc_ids .data at91_xxx_standby members Wenyou Yang
2015-01-27 6:01 ` [PATCH v3 13/13] pm: at91: amend the pm_suspend entry for at91_cpuidle_device Wenyou Yang
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=fd04e7c80f6841368ea1953d544f3386@EMAIL.axentia.se \
--to=peda@axentia.se \
--cc=alexandre.belloni@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linux@maxim.org.za \
--cc=nicolas.ferre@atmel.com \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=sylvain.rochet@finsecur.com \
--cc=wenyou.yang@atmel.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
all inboxes | Powered by JetHome®