On 4/5/22 11:09, Francesco Dolcini wrote:
On Mon, Apr 04, 2022 at 09:56:50PM +0200, Marek Vasut wrote:
On 4/4/22 16:53, Francesco Dolcini wrote:
On Mon, Apr 04, 2022 at 03:39:35PM +0200, Marek Vasut wrote:
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -1526,6 +1526,8 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo,
((sysinfo->ncs == 2) ? 1 : 0) << 30; /* SDE_1 for CS1 */
/* Step 8: Write Mode Registers to Init DDR3 devices */
+ mdelay(1); /* Wait before issuing the first MRS command
+ (tXPR / 500us CKE delay after reset deassertion) */
Should we infer this delay from tXPR instead ?
I could just delay(tXPR + 500us) and do the exact worst case delay.
However I wonder if it is worth doing it, the 1ms delay works in
practice, it is big enough to be correct in any case, but small enough
not to be a concern on the boot time.
Please note that I do not know which timing is violated here
(tXPR, the 500us after reset de-assertion or both of them).
Can the tXPR ever be larger than 500us ?
No, it can't. Max value for 8GB density is 360ns, min value 120ns
for 1GB density (see JEDEC standard, but also mx6/ddr.c).
Would be fine for you to improve the commit message and code comment
to make this discussion we just had transparent, while keeping the 1ms
delay?
Yeah, 1ms is fine. If you do V2, add my:
Reviewed-by: Marek Vasut <ma...@denx.de>
