[PATCH v2 3/4] mtd: nand: support Micron READ RETRY

[Brian Norris]

On Tue, Dec 17, 2013 at 12:23:08PM +0800, Huang Shijie wrote:
> On Mon, Dec 16, 2013 at 08:43:42PM -0800, Brian Norris wrote:
> > > 
> > > The DMA warning only occurs when we enable the CONFIG_DMA_API_DEBUG.
> > 
> > But the warning has a significant purpose: it is *not* legal to perform
> > DMA on stack memory, and no driver should do this. Either nand_base or
> > gpmi-nand need to be fixed here.
> > 
> > But I think it's the GPMI driver is the one that needs fixing, not this
> > patch. Are there any scenarios where it makes sense for gpmi-nand to use
> > DMA for its read_buf/write_buf? Shouldn't the only DMA-necessary
> > operations come through the ecc.write_page and ecc.read_page callbacks?
> > If I'm correct, then gpmi-nand should not be using DMA at all in
> > read_buf/write_buf.
> Currently, all the operations, including the read_buf/write_buf, use
> the DMA.
> 
> Is there any ABI tells us we should not use the DMA for read_buf/write_buf? :)

No... but this is not about ABI, it's about designing a reasonable API
and abstraction between users (NAND drivers) and the helper code
(nand_base). MTD never had a good design for DMA-able operations; but I
think that it's at least an approachable problem if we provide
limitations on when and where we might expect to use DMA.

Particularly, I think it is quite reasonable to restrict DMA to
mtd_read()/mtd_write()-like operations -- so this trickles down to
read_page/write_page, but not to device configuration operations like
ONFI set_features/get_features/read parameter tables, etc.

Do you disagree? Do you see some need to perform DMA on all operations?

> > > Different nand chips use different read-retry methods. A headache to us.
> > 
> > Any chance we can push these vendors to implement things through a
> > standard, like JEDEC? I believe there's a JEDEC parameter page standard
> we do not have such influence to push these vendors.
> they will not listen to us. :(

We can try! Strength in numbers! BTW, last time I brought up ONFI w/ a
Toshiba representative, I think I offended them :) But at least I had
their ear for a moment.

Anyway, it may be more reasonable to suggest a JEDEC standard, as I
think they felt JEDEC was more vendor-independent, and they were at
least open to entertaining the idea.

Brian