From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 26 Jun 2012 14:38:54 -0500 Subject: [U-Boot] [PATCH 6/9] CACHE: nand read/write: Test if start address is aligned In-Reply-To: <201206260316.02206.marex@denx.de> References: <1340583477-14018-1-git-send-email-marex@denx.de> <201206260142.30537.marex@denx.de> <4FE9045E.3080903@freescale.com> <201206260316.02206.marex@denx.de> Message-ID: <4FEA0FCE.4040101@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 06/25/2012 08:16 PM, Marek Vasut wrote: > Dear Scott Wood, >> 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. Why should I need to have 64-byte alignment for transfering a 16-byte 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). > > 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. Probably best to wait until you're feeling better for the rest of it, too. Hope you get well soon. >>>> 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. atmel: no, doesn't use DMA davinci: no, doesn't use DMA kb9202: no, doesn't use DMA kirkwood: no, doesn't use DMA mxc: I don't think this uses DMA, but this driver scares me. :-) mxs: Even scarier. Looks like this one does use DMA. omap_gpmc: no, doesn't use DMA s3c64xx: no, doesn't use DMA spr: no, doesn't use DMA s3c2410: no, doesn't use DMA If this is about not wanting to touch the mxs_nand driver again, I sympathize. :-) >>> 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. Right, I think it's wrong elsewhere too when it's user interface, but I'll let the relevant custodians argue those cases. -Scott