From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lei Wen <adrian.wenl@gmail.com>
Date: Wed, 26 Jan 2011 10:01:12 +0800
Subject: [U-Boot] [PATCH V2 2/5] ARM: Add Support for Marvell Pantheon
 Familiy SoCs
In-Reply-To: <20110125213200.2FB46B187@gemini.denx.de>
References: <1294632087-8025-1-git-send-email-leiwen@marvell.com>
	<1294632087-8025-3-git-send-email-leiwen@marvell.com>
	<20110125213200.2FB46B187@gemini.denx.de>
Message-ID: <AANLkTin0HQKxKiLas8H4_GHmFsdi1Mt3gPbTK0A17r2d@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Wolfgang,

On Wed, Jan 26, 2011 at 5:32 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Lei Wen,
>
> In message <1294632087-8025-3-git-send-email-leiwen@marvell.com> you wrote:
>> Pantheon Family processors are highly integrated SoCs
>> based on Sheeva_88SV331x-v5 PJ1 cpu core.
>> Ref:
>> http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf
>>
>> SoC versions Supported:
>> 1) PANTHEON920 ? ? ? ? ?(TD)
>> 2) PANTHEON910 ? ? ? ? ?(TTC)
>>
>> Signed-off-by: Lei Wen <leiwen@marvell.com>
> ...
>> +int dram_init(void)
>> +{
> ...
>> + ? ? for (; i < CONFIG_NR_DRAM_BANKS; i++) {
>> + ? ? ? ? ? ? /* If above loop terminated prematurely, we need to set
>> + ? ? ? ? ? ? ?* remaining banks' start address & size as 0. Otherwise other
>> + ? ? ? ? ? ? ?* u-boot functions and Linux kernel gets wrong values which
>> + ? ? ? ? ? ? ?* could result in crash */
>
> Incorrect multiline comment style.
>

This already fix in the v6 patch...
http://patchwork.ozlabs.org/patch/80305/

>> +/* For preventing risk of instability in reading counter value,
>> + * first set read request to register cvwr and then read same
>> + * register after it captures counter value.
>> + */
>
> Ditto. ?Please fix globally.
>
>> + ? ? writel(COUNT_RD_REQ, &panthtimers->cvwr);
>> + ? ? while (loop--);
>
> Please write:
>
> ? ? ? ?while (loop--)
> ? ? ? ? ? ? ? ?;

Fixed...
>
> But then - are you sure the compiler does not optimize this out? ?You
> probably want to use __udelay() instead.