[PATCH 1/2] mtd: nand: add OOB argument to NAND {read, write}_page interfaces

Brian Norris computersforpeace at gmail.com
Tue Apr 17 23:44:11 EDT 2012


Hi Matthieu,

On Tue, Apr 17, 2012 at 12:50 AM, Matthieu CASTET
<matthieu.castet at parrot.com> wrote:
> Brian Norris a écrit :
>> New NAND controllers can perform read/write via HW engines which don't expose
>> OOB data in their DMA mode. To reflect this, we should rework the nand_chip /
>> nand_ecc_ctrl interfaces that assume that drivers will always read/write OOB
>> data in the nand_chip.oob_poi buffer. A better interface would pass the
>> appropriate buffer explicitly when OOB data is requested and otherwise pass a
>> NULL pointer, meaning that no OOB data is needed.
>
> If I understand correctly you propose that these driver will fetch oob (via pio
> mode) only when needed ?

Sure, that's the idea.

> Do you have an example of such controller ?

Yes. I'm working with a new ASIC which has a DMA mode as well as a PIO
mode. For DMA transactions (the preferred interface), I fill out a
64-byte descriptor (format specified below) then point the controller
to that DRAM address via a register. The "command" field only supports
page program, page read, and block erase, though.

So for instance, if I want to perform a page program, I can only
specify a single buffer (via dram_addr/dram_addr_ext) for the in-band
data; the OOB data is automatically filled with 0xFF + HW ECC
(calculated on the fly, internally, by HW controller). And on page
read, I only receive the in-band data in my DRAM buffer.

Now, in future revisions of this ASIC, it may be possible to access
OOB via DMA as well, but even if this happens, it doesn't make a lot
of sense on this hardware to *always* pull OOB data. As mentioned
previously, most normal applications (i.e., UBI(FS)) don't need to
access this OOB data at all, so it seems silly to go to extra work to
have the DMA controller return it to the MTD/NAND layers. I'm not
familiar with the OOB/ECC schemes on enough other hardware to
determine whether other drivers could make use of this same
optimization. It would require hardware with internal buffers for
error correction and an access mode that easily returns page data
only...

Brian

struct nand_dma_desc {
       __le32 next_desc;
       __le32 next_desc_ext;
       u8 type_E;
       u8 irq_swap;
       u8 __pad1;
       u8 command;
       __le32 dram_addr;
       __le32 dram_addr_ext;
       __le32 tfr_len;
       __le32 total_len;
       __le32 flash_addr;
       __le32 flash_addr_ext;
       __le32 cs;
       u32 __pad[5];
       u8 valid;
       u8 ecc_status;
       u8 flash_status;
       u8 dma_status;
} __attribute__((packed));



More information about the linux-mtd mailing list