From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared
Date: Sun, 6 May 2012 18:30:44 +0200 [thread overview]
Message-ID: <201205061830.45104.marex@denx.de> (raw)
In-Reply-To: <4FA6A695.6060503@denx.de>
Dear Stefano Babic,
> On 03/05/2012 17:47, Marek Vasut wrote:
> > This solves issues when larger amount of DRAM is used. Behave the
> > same in case of CPU bypass as we do in case of EMI bypass, wait
> > 15 ms. We need to wait until the clock domain stabilizes.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Wolfgang Denk <wd@denx.de>
> > Cc: Detlev Zundel <dzu@denx.de>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > ---
> >
> > V2: Change the description, this issue seemed to have been caused by not
> >
> > waiting after frobbing with the CPU bypass, it was unrelated to
> > memory, but had a direct impact, causing trouble. This was yet
> > another X-File of the imx-bootlets, sigh.
> >
> > arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c index 0d13537..a9b1bb6
> > 100644
> > --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > @@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)
> >
> > /* Disable CPU bypass */
> > writel(CLKCTRL_CLKSEQ_BYPASS_CPU,
> >
> > &clkctrl_regs->hw_clkctrl_clkseq_clr);
> >
> > +
> > + early_delay(15000);
>
> Is there some influence (I assume that from your commit message) between
> size of the RAM and amount of time to wait ?
Nope
> Then yes, with boards with
> even more memory (this patch touches a common MX28 file) this delay is
> not enough. Should we correlate the delay maybe with PHYS_SDRAM_1_SIZE
> (maybe early_delay(15000 * (PHYS_SDRAM_1_SIZE / 512MB)) ?
There was a new version of this patch explaining how I got to this delay (or how
FSL hid it from me).
>
> Best regards,
> Stefano Babic
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-05-06 16:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-03 15:47 [U-Boot] [PATCH 1/4 V2] Revert "i.MX28: Enable additional DRAM address bits" Marek Vasut
2012-05-03 15:47 ` [U-Boot] [PATCH 2/4 RESEND] M28: Scan only first 512 MB of DRAM to avoid memory wraparound Marek Vasut
2012-05-03 15:47 ` [U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared Marek Vasut
2012-05-04 9:20 ` Detlev Zundel
2012-05-04 11:13 ` Marek Vasut
2012-05-04 11:32 ` [U-Boot] [PATCH] " Marek Vasut
2012-05-06 16:38 ` Stefano Babic
2012-05-06 16:39 ` Marek Vasut
2012-05-07 9:49 ` Detlev Zundel
2012-05-06 16:28 ` [U-Boot] [PATCH 3/4 V2] " Stefano Babic
2012-05-06 16:30 ` Marek Vasut [this message]
2012-05-03 15:47 ` [U-Boot] [PATCH 4/4] M28: Enable FDT support Marek Vasut
2012-05-06 15:53 ` Stefano Babic
2012-05-06 16:12 ` Marek Vasut
2012-05-06 16:18 ` Stefano Babic
2012-05-06 16:41 ` Marek Vasut
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=201205061830.45104.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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.