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

[Marek Vasut <marex@denx.de>]

Dear Scott Wood,

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

I'm trying to make it user-proof. Honestly, loading to some bullshit unaligned 
address is a corner case, so it won't affect many people. And that minority 
who'll be affected will adjust their stuff by a few bytes, no problem there.

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

Ad absurdum indeed, but it's partly valid point. You'd need to restrict it 
somehow if that'd be the case, therefore I'll add it to the DM. Drivers should 
be able to specify their requirements.

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

I don't think I completely follow here.

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

Ok, I think I'm very stupid now, probably since I have high fever. I'll read 
this after I sleep. Sorry Scott, I'm sure you're rolling out a valid point, it's 
just that I'm incapable of understanding it right now.

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

And it's the easy part.

> >> 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?

At least all on the ARM architecture. And more will come, since ARM is on the 
rise.

> > it's not only nand, it's all over the place.
> 
> This patch is about NAND.

Check the whole patchset ... and that still only covers a small part of it all.

> -Scott

Best regards,
Marek Vasut