public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Valentine <vbarshak@ru•mvista.com>
To: Josh Boyer <jwboyer@linux•vnet.ibm.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: Thu, 12 Mar 2009 01:08:59 +0300	[thread overview]
Message-ID: <49B8367B.5060402@ru.mvista.com> (raw)
In-Reply-To: <20090311215728.GA12676@zod.rchland.ibm.com>

Josh Boyer wrote:
> 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

Yes, but until u-boot is fixed this will break Sequoia/Rainier support.
Thanks,
Valentine.

  reply	other threads:[~2009-03-11 22:13 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
2009-03-11 22:08             ` Valentine [this message]
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=49B8367B.5060402@ru.mvista.com \
    --to=vbarshak@ru$(echo .)mvista.com \
    --cc=jwboyer@linux$(echo .)vnet.ibm.com \
    --cc=lebon@lebon$(echo .)org.ua \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    --cc=sr@denx$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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