[U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets

[Otavio Salvador]

On Tue, Jan 29, 2013 at 1:14 AM, Marek Vasut <marex at denx.de> wrote:
> Dear Marek Vasut,
>
>> Dear Otavio Salvador,
>>
>> > This enables the 'Fast Auto Pre-Charge' found in the memory chip.
>> >
>> > Signed-off-by: Otavio Salvador <otavio at 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 .

I've been trying to be cooperative and to improve on the way. I (as
other humans) do mistakes but I try to fix them as soon as possible.

I've been trying to get MX23 in basic working state (for users) and do
wish to have it for next release and that's why I am trying to make
things fast; I am sorry by the patch but it is normal to make mistakes
on the way.

I am glad you noticed it but not so glad by the way you communicated it.

Regards,


--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br