All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Pihet <jpihet@mvista.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: "Syed Mohammed, Khasim" <khasim@ti.com>,
	"Kridner, Jason" <jdk@ti.com>,
	linux-omap <linux-omap@vger.kernel.org>
Subject: Re: Beagleboard rev C memory timings & suspend/resume
Date: Mon, 11 May 2009 21:10:34 +0200	[thread overview]
Message-ID: <200905112110.34589.jpihet@mvista.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0905081527330.17514@utopia.booyaka.com>

Hi Paul,

On Saturday 09 May 2009 00:43:43 Paul Walmsley wrote:
> Hello Jean,
>
> On Fri, 8 May 2009, Jean Pihet wrote:
> > On Thursday 07 May 2009 20:59:43 Paul Walmsley wrote:
> > > On Thu, 7 May 2009, Jean Pihet wrote:
> > > > From the OMAP datasheet it looks like the ARCV setting is off:
> > > > shouldn't it be (tREFI/tCK)+50=(7800/6)+50=0x546?
> > >
> > > Could you elaborate further what you're seeing?  It would help to
> > > see the register value that you're using to come to this conclusion.
> >
> > The SDRC_RFR_CTRL_p registers are now programmed with 0x4dc01, which
> > means the fiel ARCV has the value 0x4dc=1244.
> > From the DDR datasheet we need an average refresh period of 7.8us and a
> > clock period of 6ns (166MHz). From the definition of the ARCV field in
> > the OMAP TRM I need to program ARCV with: (tREFI/tCK)+50 =
> > (7800/6)+50=1350=0x546. The SDRC_RFR_CTRL_p registers would then have the
> > value of 0x54601.
> >
> > Does that make sense? Am I wrong with the calculation?
>
> According to the TRM, the 50 cycles should be subtracted rather than added
> (section 11.2.6.3.3.4).  One other thing is that the bootloaders I've seen
> program DPLL3 such that the SDRC clock is 166000000 Hz, rather than
> 166666666 Hz, so tCK winds up being something like 6.024... ns.
The settings should be ok with tCK=6.024ns

> Auto-refresh is only used while the SDRC is active, though.  So unless
> memory corruption is evident outside of suspend, the ARCV value is
> unlikely to be the problem.
Ok

> It sounds like the problem is related to self-refresh, that the SDRAM bank
> on one of the chipselects either can't enter or exit self-refresh.  You
> have self-refresh working on a different board with both SDRC CS0 and CS1
> in use, correct?  Is that with an ES2 or ES3 chip?
>
> One possibility: perhaps the problem is with Beagle's pin mux settings.
> You might want to boot with mem=128M and make sure
> CONTROL_PADCONF_SAD2D_SBUSFLAG and CONTROL_PADCONF_SDRC_CKE1 are in mode 0
> before suspend and after resume.
Yes that definitely is the root cause. I should have checked this first ;-(
The U-Boot change is committed, cf. 
http://gitorious.org/u-boot-omap3/mainline/commit/c6f01ad390308800693c62dbdb096ab59e03630b
and
http://gitorious.org/u-boot-omap3/mainline/commit/4025cfbde3611b14c0d4831a5524e5e061128e30

> Another thought: it could be that the ROM code on Beagle is not
> programming the correct SDRC register values after resume.  You might try
> booting with mem=128M and dumping the SDRC register values before suspend
> and after resume.
Those are OK.

I am looking at a fix for the SDRC setup with 2 CSes. I will propose the 
changes asap.

>
> - Paul

Thx & regards,
Jean

  reply	other threads:[~2009-05-11 19:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29 13:53 Beagleboard rev C memory timings & suspend/resume Jean Pihet
2009-05-06 23:39 ` Paul Walmsley
2009-05-07 11:18   ` Jean Pihet
2009-05-07 16:44     ` Jean Pihet
2009-05-07 18:59       ` Paul Walmsley
2009-05-08  7:05         ` Jean Pihet
2009-05-08 22:43           ` Paul Walmsley
2009-05-11 19:10             ` Jean Pihet [this message]
2009-05-11 20:27               ` Paul Walmsley
2009-05-26 13:27                 ` [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume) Jean Pihet
2009-06-02 23:40                   ` Paul Walmsley
2009-06-03  7:03                     ` Jean Pihet
2009-06-05 15:35                     ` Jean Pihet
2009-06-05 18:10                       ` Paul Walmsley
2009-06-08  7:37                         ` Tero.Kristo
2009-06-08  8:59                         ` Jean Pihet
2009-06-08 14:59                           ` Kevin Hilman
2009-06-08 17:08                             ` Jean Pihet
2009-06-08 17:23                               ` [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects Kevin Hilman
2009-06-09  8:14                                 ` Tero.Kristo
2009-06-09  8:23                                   ` Jean Pihet
2009-06-09  8:29                                     ` Tero.Kristo
2009-06-09  7:26                           ` [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume) Paul Walmsley
2009-06-05 19:14                       ` Paul Walmsley
2009-06-06 10:50                         ` Grazvydas Ignotas
2009-06-08  9:02                           ` Jean Pihet
2009-06-08 11:01                             ` Grazvydas Ignotas
2009-06-08 17:11                               ` Jean Pihet
2009-06-08 17:28                                 ` [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects Kevin Hilman
2009-05-07 19:18     ` Beagleboard rev C memory timings & suspend/resume Paul Walmsley
2009-05-08  8:13       ` Jean Pihet
2009-05-08 22:51         ` Paul Walmsley

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=200905112110.34589.jpihet@mvista.com \
    --to=jpihet@mvista.com \
    --cc=jdk@ti.com \
    --cc=khasim@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.