From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lokesh Vutla <lokeshvutla@ti.com>
Date: Wed, 27 Mar 2013 11:13:55 +0530
Subject: [U-Boot] [PATCH] arm: omap: emif: Support for ddr3 after warm
	reset
In-Reply-To: <51527F6E.4090201@ti.com>
References: <1364358325-21672-1-git-send-email-lokeshvutla@ti.com>
	<51527F6E.4090201@ti.com>
Message-ID: <5152871B.3030905@ti.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

On Wednesday 27 March 2013 10:41 AM, Sricharan R wrote:
> On Wednesday 27 March 2013 09:55 AM, Lokesh Vutla wrote:
>> EMIF supports a global warm reset mode, during which the
>> EMIF keeps the SDRAM content. But if leveling is enabled
>> at the time of warm reset for DDR3, the following steps
>> needs to be done after warm reset:
>> 1) Keep EMIF in self refresh mode.
>> 2) Reset PHY to bring back the PHY to a known state.
>> 3) Start Levelling procedure.
>> Doing the same.
>> And also enabling DLL lock and code output after warm reset.
>>
>
>   Should the $subject be something like
>     Fix DDR3 initialisation after warm reset ?
Ok I ll change it.
>
>> Tested on OMAP5432 ES2.0
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>>   arch/arm/cpu/armv7/omap-common/emif-common.c |   12 +++++++++---
>>   1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c b/arch/arm/cpu/armv7/omap-common/emif-common.c
>> index 9eb1279..8811958 100644
>> --- a/arch/arm/cpu/armv7/omap-common/emif-common.c
>> +++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
>> @@ -1072,6 +1072,12 @@ static void do_sdram_init(u32 base)
>>   		else
>>   			ddr3_init(base, regs);
>>   	}
>> +	if (!in_sdram && warm_reset() &&
>> +	    (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3)) {
>> +		set_lpmode_selfrefresh(base);
>> +		emif_reset_phy(base);
>> +		ddr3_leveling(base, regs);
>> +	}
>>
>
>     Why do we need !in_sdram check here ?. Otherwise, good..
DDR3 leveling cannot happen from SDRAM. So I kept a check here.

Thanks and Regards,
Lokesh
>
>     Reviewed-by: R Sricharan <r.sricharan@ti.com>
>
>
> Regards,
>   Sricharan
>