From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Schwarz <simonschwarzcor@googlemail.com>
Date: Mon, 31 Oct 2011 09:56:54 +0100
Subject: [U-Boot] [PATCH 1/2] nand_spl_simple: Add omap3 DMA usage to SPL
In-Reply-To: <4EA6FEF9.6070208@freescale.com>
References: <1318759804-18688-1-git-send-email-simonschwarzcor@gmail.com>
	<1318759804-18688-2-git-send-email-simonschwarzcor@gmail.com>
	<4EA6FEF9.6070208@freescale.com>
Message-ID: <4EAE62D6.5030109@gmail.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

Dear Scott,

On 10/25/2011 08:24 PM, Scott Wood wrote:
> On 10/16/2011 05:10 AM, Simon Schwarz wrote:
>> This adds DMA copy for the nand spl implementation. If CONFIG_SPL_DMA_SUPPORT
>> is defined the DMA is used.
>>
>> Based on DMA driver patch:
>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/109744/focus=109747
>
> As Wolfgang pointed out, this doesn't belong here.  Create your own
> alternate SPL driver if your hardware doesn't work with the simple one
> (similar to the not-yet-migrated nand_spl/nand_boot_fsl_elbc.c,
> nand_spl/nand_boot_fsl_ifc.c, etc).
>

Hm. The naming of the functions was a fault. Will rename the calls in 
nand_spl_simple to remove omap parts. So
omap3_dma_wait_for_transfer
will become
dma_wait_for_transfer
etc.

So a board which intents to use DMA in SPL can implement these 
functions. Would this be ok?

A whole new driver is IMHO not the right thing as there is too much 
duplicated code then.

>> @@ -46,11 +59,11 @@ static int nand_command(int block, int page, uint32_t offs,
>>   	this->cmd_ctrl(&mtd, offs, NAND_CTRL_ALE | NAND_CTRL_CHANGE);
>>   	this->cmd_ctrl(&mtd, page_addr&  0xff, NAND_CTRL_ALE); /* A[16:9] */
>>   	this->cmd_ctrl(&mtd, (page_addr>>  8)&  0xff,
>> -		       NAND_CTRL_ALE); /* A[24:17] */
>> +			NAND_CTRL_ALE); /* A[24:17] */
>>   #ifdef CONFIG_SYS_NAND_4_ADDR_CYCLE
>>   	/* One more address cycle for devices>  32MiB */
>>   	this->cmd_ctrl(&mtd, (page_addr>>  16)&  0x0f,
>> -		       NAND_CTRL_ALE); /* A[28:25] */
>> +			NAND_CTRL_ALE); /* A[28:25] */
>>   #endif
>
> Please refrain from making random unrelated whitespace changes in a
> patch that also makes functional changes, particularly when they are
> extensive enough to make it hard to spot the functional changes.
>
> In this particular case, I think the whitespace was fine the way it was;
> the continuation lines were nicely aligned.


If I remember right I changed these because of checkpatch errors.

Regards
Simon