linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
To: Valentine Barshak <vbarshak@ru.mvista.com>
Cc: linuxppc-dev@ozlabs.org, Stefan Roese <sr@denx.de>, lebon@lebon.org.ua
Subject: Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
Date: Wed, 11 Mar 2009 17:57:28 -0400	[thread overview]
Message-ID: <20090311215728.GA12676@zod.rchland.ibm.com> (raw)
In-Reply-To: <49B80BA3.1090301@ru.mvista.com>

On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote:
> Josh Boyer wrote:
>> On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
>>> I was just going to submit a patch for that too.
>>> Indeed, the denali_fixup_memsize() miscalculated a couple of address
>>> field widths. We were lucky to eventually get the right result,
>>> because the effect of the first error was killed by the other one.
>>> According to the AMCC 440EPX/GRX user manual,
>>> the Chip Select width is always fixed at 1 bit no matter
>>> what is actually read from register DDR_10.
>>> The workaround is to use a predefined chipselect value for 440EPx/GRx.
>>> Also, setting the REDUC bit (REDUC = 1) enables 32-bit data path.
>>> If REDUC = 0, full data path of 64 bits is used.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>
>>
>> I've been looking over this one a bit more.  At the moment, I'm inclined
>> to queue this up in my -next branch.  I would like to see if Mikhail
>> could test it though, and have Valentine answer the question in the hard
>> wired part.
>
> I've been looking at the docs once again and actually I couldn't find an  
>   explanation there. And I don't have that e-mail from AMCC support that 
> I got a while back regarding the issue anymore.
> There might have been some misunderstanding.
> The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip  
> select field width is always fixed at one bit, but this doesn't actually  
>  mean that there's always one chip select used.
> The patch works fine on Sequoia and another Sequoia-like board with 1GB  
> RAM installed, but it might not work with 2GB RAM. I've tried to play  
> with DDR0_10 settings and Sequoia works fine regardless of what's  
> actually written to DDR0_10.
> So, probably the best way would be to fix that in u-boot
> amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x00000100); instead of  
> mtsdram(DDR0_10, 0x00000300);
> Sorry, for confusion, but after reviewing the docs, I think that
> only REDUC interpretation has to be fixed. The chips select part should  
> be fixed in u-boot sdram code for Sequoia as was originally proposed by  
> Mikhail.

Ok, so we're back to using Mikhail's original patch then?

josh

  reply	other threads:[~2009-03-11 21:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09 16:21 [PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly Mikhail Zolotaryov
2009-03-09 17:12 ` Josh Boyer
2009-03-09 21:17   ` Mikhail Zolotaryov
2009-03-10 19:50     ` [PATCH] PowerPC 440EPx/GRx fix memory size calculation Valentine Barshak
2009-03-10 20:57       ` Mikhail Zolotaryov
2009-03-11  1:40         ` Valentine
2009-03-11  2:26           ` Benjamin Herrenschmidt
2009-03-11  8:24             ` Mikhail Zolotaryov
2009-03-11  8:29           ` Mikhail Zolotaryov
2009-03-11 10:37       ` Josh Boyer
2009-03-11 19:06         ` Valentine Barshak
2009-03-11 21:57           ` Josh Boyer [this message]
2009-03-11 22:08             ` Valentine
2009-03-11 23:07               ` Josh Boyer
2009-03-12  6:02           ` Stefan Roese
2009-03-12  7:32             ` Benjamin Herrenschmidt
2009-03-12  8:05               ` Stefan Roese
2009-03-12  8:12                 ` Benjamin Herrenschmidt
2009-03-12  8:24                   ` Stefan Roese
2009-03-12  8:45                     ` Mikhail Zolotaryov
2009-03-12 10:45                     ` Josh Boyer
2009-03-12 11:02                       ` Stefan Roese
2009-03-13 23:01             ` Feng Kan

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=20090311215728.GA12676@zod.rchland.ibm.com \
    --to=jwboyer@linux.vnet.ibm.com \
    --cc=lebon@lebon.org.ua \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=sr@denx.de \
    --cc=vbarshak@ru.mvista.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;
as well as URLs for NNTP newsgroup(s).