All of lore.kernel.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: 26+ 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 16:21 ` Mikhail Zolotaryov
2009-03-09 17:12 ` Josh Boyer
2009-03-09 17:12   ` Josh Boyer
2009-03-09 21:17   ` Mikhail Zolotaryov
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.mvista.com \
    --cc=jwboyer@linux.vnet.ibm.com \
    --cc=lebon@lebon.org.ua \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=sr@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.