[PATCH v2 3/4] mtd: nand: support Micron READ RETRY
Huang Shijie
b32955 at freescale.com
Tue Dec 17 00:11:25 EST 2013
On Mon, Dec 16, 2013 at 09:06:13PM -0800, Brian Norris wrote:
> 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.
> 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?
The gpmi is much coupled with the MXS-DMA engine. the gpmi can uses the
mxs-dma to set the gpmi registers.
Use the DMA makes the GPMI code very simple, it really makes the code very
_ugly_ if we do not use the DMA for read_buf/write_buf.
If you insist that it is okay to use the local array in the nand_base.c,
I can use kmalloc/memcpy in the gpmi's read_buf/write_buf hooks. In such a
way, we can make the gpmi looks more normal.
sorry, I really think it is no need to force the gpmi do not use the DMA
for read_buf/write_buf.
>
> > > > 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.
>
look good to me. :)
I will suggest their FAE/AE when i meet them next time.
thanks
Huang Shijie
More information about the linux-mtd
mailing list