[U-Boot] [PATCH 1/2] nand_spl_simple: Add omap3 DMA usage to SPL

[Scott Wood <scottwood@freescale.com>]

On 10/31/2011 03:56 AM, Simon Schwarz wrote:
> 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?

What would the semantics of a generic dma_wait_for_transfer() be?

I just don't see how this is generic at all, whatever the name.

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

So factor the common bits out into a separate file.

>>> @@ -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.

I believe checkpatch only complains when you have 8 or more spaces in a
row, which isn't the case here.  I don't think there's any prohibition
on lining things up with single-column granularity.

Further, checkpatch should not be complaining about lines that you don't
touch.

Where reformatting is warranted, it should be a separate patch.

-Scott