From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Date: Thu, 7 Nov 2013 10:03:58 -0500 [thread overview]
Message-ID: <20131107150358.GS5925@bill-the-cat> (raw)
In-Reply-To: <1383835660-16516-2-git-send-email-r.sricharan@ti.com>
On Thu, Nov 07, 2013 at 08:17:39PM +0530, Sricharan R wrote:
> Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
> software leveling. This was done since hardware leveling was not
> working. Now that the right sequence to do hw leveling is identified,
> use it. This is required for EMIF clockdomain to idle and come back
> during lowpower usecases.
[snip]
> @@ -210,54 +210,76 @@ static void ddr3_leveling(u32 base, const struct emif_regs *regs)
> {
> struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
>
> - /* keep sdram in self-refresh */
[snip]
> + if (omap_revision() != DRA752_ES1_0) {
> + /* keep sdram in self-refresh */
[snip]
> + } else {
> + u32 fifo_reg;
[snip]
> + /* Disable leveling */
> + writel(0x0, &emif->emif_rd_wr_lvl_rmp_ctl);
> + }
Two things here. First, it seems that now ddr3_leveling has one
sequence for "not DRA752_ES1_0" (so likely to get wrong when used on
DRA752 whatever comes after ES1.0) and another for DRA752_ES1_0. This
would be because the it's different EMIF blocks and related HW, so it's
a different sequence, yes? Second, the comment at the end of this
function about "Disable leveling" seems misleading, but maybe it's just
me. We're saying "leveling sequence is complete now", yes?
For the second issue, we can expand / clarify the comment. For the
first issue, maybe we shouldn't have a single "ddr3_leveling" function
but per family ones? There's nothing in common between the two cases
here, so we're just gaining an indentation level when we could be
excluding code from the final binary instead (either ifdef or maybe just
separate files?).
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131107/fa97d026/attachment.pgp>
next prev parent reply other threads:[~2013-11-07 15:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 14:47 [U-Boot] [PATCH 0/2] OMAP5/DRA7: EMIF fixes for lowpower usecases Sricharan R
2013-11-07 14:47 ` [U-Boot] [PATCH 1/2] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling Sricharan R
2013-11-07 15:03 ` Tom Rini [this message]
2013-11-08 6:03 ` Sricharan R
2013-11-07 14:47 ` [U-Boot] [PATCH 2/2] ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039 Sricharan R
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=20131107150358.GS5925@bill-the-cat \
--to=trini@ti.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox