From: Huang Shijie <b32955@freescale.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: linux-mtd@lists.infradead.org, Huang Shijie <shijie8@gmail.com>,
Pekon Gupta <pekon@ti.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Subject: Re: [PATCH v2 3/4] mtd: nand: support Micron READ RETRY
Date: Tue, 17 Dec 2013 12:23:08 +0800 [thread overview]
Message-ID: <20131217042307.GA15469@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <20131217044342.GB12034@norris-Latitude-E6410>
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? :)
>
> > 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. :(
> now, though I haven't looked at it closely. Micron's support is nice and
> simple because it properly uses the ONFI vendor block. Other vendors
> should take note...
yes. Micron is good example.
thanks
Huang Shijie
next prev parent reply other threads:[~2013-12-17 4:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 20:09 [PATCH v2 1/4] mtd: nand: localize ECC failures per page Brian Norris
2013-12-09 20:09 ` [PATCH v2 2/4] mtd: nand: add ONFI vendor block for Micron Brian Norris
2013-12-09 20:09 ` [PATCH v2 3/4] mtd: nand: support Micron READ RETRY Brian Norris
2013-12-11 13:54 ` Huang Shijie
2013-12-11 19:03 ` Brian Norris
2013-12-11 20:31 ` Ezequiel Garcia
2013-12-12 3:49 ` Huang Shijie
2013-12-12 3:47 ` Huang Shijie
2013-12-17 4:43 ` Brian Norris
2013-12-17 4:23 ` Huang Shijie [this message]
2013-12-17 5:06 ` Brian Norris
2013-12-17 5:11 ` Huang Shijie
2013-12-17 7:01 ` Brian Norris
2013-12-17 7:12 ` Huang Shijie
2013-12-09 20:09 ` [PATCH v2 4/4] mtd: nand: use __packed shorthand Brian Norris
[not found] <20980858CB6D3A4BAE95CA194937D5E73EA53CF1@DBDE04.ent.ti.com>
2013-12-11 18:37 ` [PATCH v2 3/4] mtd: nand: support Micron READ RETRY Brian Norris
2013-12-11 20:54 ` Gupta, Pekon
2013-12-17 5:22 ` Brian Norris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131217042307.GA15469@shlinux2.ap.freescale.net \
--to=b32955@freescale.com \
--cc=computersforpeace@gmail.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.com \
--cc=shijie8@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.