All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/7] ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register
Date: Fri, 1 Feb 2013 09:37:33 -0500	[thread overview]
Message-ID: <510BD32D.4000401@ti.com> (raw)
In-Reply-To: <510B60F5.20406@ti.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/01/2013 01:30 AM, R Sricharan wrote:
> On Thursday 31 January 2013 09:59 PM, Tom Rini wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 01/31/2013 12:51 AM, R Sricharan wrote:
>>> From: Lokesh Vutla <lokeshvutla@ti.com>
>>> 
>>> Now SDRAM initialization is done on the basis of omap
>>> revision. Instead this should be done on basis of SDRAM type
>>> read from EMIF_SDRAM_CONFIG register. This will be helpful to
>>> avoid unnessecary cpu checks for new boards
>>> 
>>> Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: 
>>> Lokesh Vutla <lokeshvutla@ti.com>
>> 
>> Does this mean the ROM is already doing some basic EMIF 
>> programming here?  I swear I looked down this path before, when I
>> wanted to share this code with am33xx and the problem is that 
>> while the registers aren't reset on warm boot, on cold boot they
>>  always come up in a default value, for both DDR2 and DDR3.
>> 
>> Or are you able to get by as the platforms come up with
>> different default values?
>> 
> Not the ROMCODE, the default value for SDRAM_CONFIG register is 
> exported from control module register based on efuse settings. We 
> did see that this default value was correct depending upon LPDDR2 
> or DDR3 in the case of OMAP.

OK, good.

> So does this mean that am3xx did not have the logic to load this 
> register dynamically based on efuse settings ? If that is the only
>  exception, then we can hardcode the register during startup only 
> in that case. Except for this, where you able to use the 
> emif-common driver in your case ?

In my initial testing, it was not being setup correctly.  I think it
was between that, and trying to abstract out further the PM-related
changes there wasn't much common EMIF code left, so I set the project
aside at the time.  I'll try and take another whack at it as I know
someone is adding ti814x support currently and did find a good
match-up with this EMIF code rather than the am33xx version, so maybe
that will help me to see what's going on.

And with all of that:
Reviewed-by: Tom Rini <trini@ti.com>

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRC9MsAAoJENk4IS6UOR1WjVkP/AzWShG1HSZR77Wk3Ax9kfs6
6P5cHTMX8Am9R+2SUk2j5LV54CzBYwGwUpdH3tDdE5nZQ0IieXs1MhYsx5kqSFHF
mIZHMeO8CVM4n/VjguKybAItYCmaXjQ3QVPkN63FuVgK50AZJPeBJZJV5m0pICSq
YnAQdQSirTHuJEZlhA4aJ9H5h7w1yRLeZ8YWtfX+feGotQoZgn/ZsieljfTc7MBY
PowXxUbZmxjcv+9WRd/ExQxWrbGhb2Jvq3bxnJMvPoTpYgYs9MBf1lv1bO5BRqnq
eD4hQjgVYWp7Et1ENHL1SEL9BCjeNmSho49a/27zV3KH+HeCnA1kwDJiwMvyxsI9
fN8rqHl87TZEOVi++VB5wtM9ksKWVcZW4IGLxExG5XCUI5rYYZjKYGW5yx4H4481
E5fS+bQohHr1PcGXvTmYJjSs/pIBvgqbmEM61Pd5AApRc0s7SVXfsHeKz0TTnFLU
JaclcxGlBqa2LO3Ysard51t/+wrSz5gin5eQhwMux+IdRM2XErLh0xyBpyzc+iQR
d/eG1KpUpmLOHBEk5c8lAGhkJX2t2SL7MXTiYbVgu74nUndPyJR8UR/hCF5ilh/M
iDFN4tV70cc9gyuYVasJ+Qw4Ufct1THh4o5cAlew0FLCIEqdSGy/3LgVkFF28QuF
xv45NQhl2nuA+Zk6Fb/M
=l80i
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-02-01 14:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31  5:51 [U-Boot] [PATCH 0/7] ARM: OMAP4+: Cleanup clocks, control and emif code R Sricharan
2013-01-31  5:51 ` [U-Boot] [PATCH 1/7] ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register R Sricharan
2013-01-31 16:29   ` Tom Rini
2013-02-01  6:30     ` R Sricharan
2013-02-01 14:37       ` Tom Rini [this message]
2013-01-31  5:52 ` [U-Boot] [PATCH 2/7] ARM: OMAP4+: Change the PRCM structure prototype common for all Socs R Sricharan
2013-01-31 16:40   ` Tom Rini
2013-02-01  6:47     ` R Sricharan
2013-01-31  5:52 ` [U-Boot] [PATCH 3/7] ARM: OMAP4+: Cleanup the clocks layer R Sricharan
2013-01-31 16:42   ` Tom Rini
2013-01-31  5:52 ` [U-Boot] [PATCH 4/7] ARM: OMAP4+: Clean up the pmic code R Sricharan
2013-01-31 17:01   ` Tom Rini
2013-02-01  6:49     ` R Sricharan
2013-01-31  5:52 ` [U-Boot] [PATCH 5/7] ARM: OMAP4+: Cleanup emif specific files R Sricharan
2013-01-31 17:03   ` Tom Rini
2013-01-31  5:52 ` [U-Boot] [PATCH 6/7] ARM: OMAP4+: Make control module register structure generic R Sricharan
2013-01-31 17:05   ` Tom Rini
2013-01-31  5:52 ` [U-Boot] [PATCH 7/7] ARM: OMAP5: Clean up iosettings code R Sricharan
2013-01-31 17:06   ` Tom Rini

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=510BD32D.4000401@ti.com \
    --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 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.