From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Tue, 29 Jan 2013 04:14:10 +0100
Subject: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of
	HW_DRAM_CTL08) as in imx-bootlets
In-Reply-To: <201301290333.56239.marek.vasut@gmail.com>
References: <1359304956-6540-1-git-send-email-otavio@ossystems.com.br>
	<1359304956-6540-2-git-send-email-otavio@ossystems.com.br>
	<201301290333.56239.marek.vasut@gmail.com>
Message-ID: <201301290414.10712.marex@denx.de>
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

Dear Marek Vasut,

> Dear Otavio Salvador,
> 
> > This enables the 'Fast Auto Pre-Charge' found in the memory chip.
> > 
> > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> > ---
> > Changes in v2:
> > - Improve commit message
> > 
> >  arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> > b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87 100644
> > --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> > +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> > @@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
> > 
> >  #elif defined(CONFIG_MX23)
> >  
> >  	0x01010001, 0x00010100, 0x01000101, 0x00000001,
> >  	0x00000101, 0x00000000, 0x00010000, 0x01000001,
> > 
> > -	0x00000000, 0x00000001, 0x07000200, 0x00070202,
> > +	0x01000000, 0x00000001, 0x07000200, 0x00070202,
> > 
> >  	0x02020000, 0x04040a01, 0x00000201, 0x02040000,
> >  	0x02000000, 0x19000f08, 0x0d0d0000, 0x02021313,
> >  	0x02061521, 0x0000000a, 0x00080008, 0x00200020,
> 
> I went through the u-boot mem init and detected you apparently added the
> following undocumented portion of code (the writel((1 << 24 ...) already:
> 
> 112 static void initialize_dram_values(void)
> 113 {
> 114         int i;
> 115
> 116         mxs_adjust_memory_params(dram_vals);
> 117
> 118         for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
> 119                 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
> 120
> 121 #ifdef CONFIG_MX23
> 122         writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
> 123 #endif
> 124 }
[...]

Sorry about me blowing. Anyway, I better put down the message I would like to 
relay. Otavio, please follow these steps:

* Work in proper sequence -- patches must apply one after another. The same way 
you cannot build house from the roof to the ground, you can not apply patches in 
anachronistic order against their dependencies.
* Prove why your patch fixes issues -- apply proper reasoning. Do a proper 
research, there's no time-limit for sending a patch. There is no deadline, take 
your time.
* Step back and slow down -- please do not roll one patch after another, wait 
for more reviews. This does put a great deal of strain on everyone in the ML, so 
please be considerate ; you are flooding the mailing list for no reason ; you 
are also pushing too much work on the reviewers. Thus, wait for some reviews, 
then fix the issues and repost.
* Focus on the changes you make -- look at the stuff above, you need to properly 
study the code instead of rolling out random patches. Properly focus on a single 
task, finish it, then move on to the other task.

Hacking is not a race, it's an art .

Best regards,
Marek Vasut