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? Francesco
