mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®