[U-Boot] [PATCH 6/9] CACHE: nand read/write: Test if start address is aligned

[Scott Wood <scottwood@freescale.com>]

On 06/25/2012 06:42 PM, Marek Vasut wrote:
> Dear Scott Wood,
> 
>> On 06/25/2012 03:48 PM, Tom Rini wrote:
>>> Right.  What I'm trying to say is it's not a NAND problem it's an
>>> unaligned addresses problem so the solution needs to be easily used
>>> everywhere.
>>
>> OK, so fix it in each driver that has this issue.  A lot of drivers are
>> probably not so performance critical that you can't just always use a
>> bounce buffer.  A static buffer plus memcpy isn't that burdensome --
>> it's close to what the drivers for non-DMA hardware do.  For higher
>> performance peripherals, throw in an if-statement or two.  It doesn't
>> seem like something that needs a U-Boot-wide change.
> 
> This is flat bull. I don't want bounce buffers growing all around uboot, see my 
> previous email. I'm 120% firm in that.

I'm 150% firm that you're going to need a better justification to change
the user interface for everybody.

What's next, restricting "cp" (or even "cp.b") in case someone wants to
use a DMA engine to copy the bits?

Note that in the case of "nand read.oob", depending on NAND page size
and platform, there's a good chance that you're imposing an alignment
restriction that is larger than the data being transferred even if the
user asks to read the entire OOB.

What about "nand write.yaffs2" or multi-page "nand read.raw", which deal
with arrays of interleaved main+spare?  With a small page NAND chip,
you'll need cache lines that are 16 bytes or smaller to avoid unaligned
transactions -- and those will bypass your front-end check (unless the
user is so "stupid" as to want to modify the data after a raw-read, and
do a raw-write of a particular page).

> And btw it's not about bounce buffers, it's also about other code (like FS code) 
> which does unaligned accesses and we're fixing it.

Fixing the alignment of U-Boot-generated buffers is good.  That doesn't
affect the user interface.  This is different.

>> In the specific case of NAND, how many NAND drivers use DMA at all?
> 
> Many do, 

How many?  Specifically, how many that have alignment restrictions, that
would need to be fixed?

> it's not only nand, it's all over the place.

This patch is about NAND.

-Scott