Hi Roger,
On Wednesday 03 September 2014 02:02 PM, Roger Quadros wrote:
Hi Pekon,
On 09/02/2014 10:02 PM, pekon wrote:
Hi Roger,
On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.
I think this is incorrect assumption. NAND framework allows
wait-pin monitoring at end of each read/write cycle. Please
refer following code in drivers/mtd/nand/nand_base.c
@@ void nand_wait_ready(...)
- nand_wait_ready() calls controller-driver specific call-back
for chip->dev_ready().
It is important to note that this NAND device ready mechanism is different from
GPMC inter cycle wait state mechanism controlled by the read/write monitoring
bits. The same WAIT pin is used in both the cases.
For more details about NAND use case refer to
AM437x TRM:
Section: 9.1.3.3.12.2 NAND Device-Ready Pin
below excerpt from there
"To avoid a time-out caused by a block/page opening delay in NAND flash,
disable the wait pin monitoring
for read and write accesses (that is, set the GPMC_CONFIG1_i[[21]
WAITWRITEMONITORING and
GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0):
I re-read the AM437x TRM, and the section you mentioned above.
-----------------
*9.1.3.3.12.2 NAND Device-Ready Pin*
The NAND memory device provides a ready pin to indicate data
availability after a block/page opening and to indicate that data
programming is complete. The ready pin can be connected to one of the
WAIT GPMC input pins; data read accesses must not be tried when the
ready pin is sampled inactive (device is not ready) even if the
associated chip-select WAITREADMONITORING bit field is set. The duration
of the NAND device busy state after the block/page opening is so long
(up to 50 μs) that accesses occurring when the ready pin is sampled
inactive can stall GPMC access and eventually cause a system time-out.
If a read access to a NAND flash is done using the wait monitoring mode,
the device is blocked during a page opening, and so is the GPMC. If the
correct settings are used, other chip-selects can be used while
the memory processes the page opening command.
...
-----------------
It's clearly written that wait-pin monitoring is used for read/write
(programs) access, and GPMC is blocked till wait signal is asserted
during reads.
Also, on NAND there can be no read/write access except at page-level
so wait-pin monitoring is implicitly related to read/write accesses.
However, whether you use it or not is purely user's choice, but it
has performance impact.
You are probably seeing timeout condition when enabling wait-pin
monitoring, and this can be due to multiple reasons like;
(1) incorrect pin-mux configuration (like directions, pull-up etc)
(2) incorrect board-level pull-up
(3) incorrect driver setting, like though wait-pin is enabled but
wrong wait-pin is being monitored.
I request you to fix this instead of disabling it completely,
as you should see significant NAND throughput increase once this
feature works correctly.
- chip->dev_ready in-case of OMAP NAND drivers is set in
drivers/mtd/nand/omap2.c during probe.
if (pdata->dev_ready) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
}
Problem is we don't set pdata->dev_ready correctly as part
of platform-data dring GPMC initialization. This was what my
earlier patch for wait-pin monitoring about. But it was a
quick fix for NAND devices.
So, I suggest to fix wait-pin monitoring instead of de-scoping
it from DTS as wait-pin monitoring should boast the NAND
performance significantly.
(please see if you can find an old mail thread which had some
good feedbacks from Ezequiel and Javier about wait-pin monitoring).
This is to get the device ready mechanism work and has nothing to do with
GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
interrupt based on the WAIT pin polarity.
To monitor NAND device ready status
from TRM
"-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
OR
-Configure an interrupt that is generated on the WAIT signal change (through the
GPMC_IRQEN [11-8] bits)"
[...]
This patch also gets rid of the below warning when NAND is
accessed for the first time.
omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
Can you debug this further.
This warning probably comes when driver tries to access some
"reserved" addresses. Or violate read/write bits.
It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling
the
wait monitoring gets rid of this error. I don't understand what else I should
debug
I'm not sure how a NAND or GPMC feature can cause omap_l3_noc: L3
application error ?
But now as I re-read the text, its probably the L3 interconnect timeout
error due to no response from GPMC. There is a timer in L3 which
monitors if the L3 interconnect is stalled/blocked waiting for response
from a target. I think it's that timer which is getting timeout. (but
just my guess).
> and why.
>
As there were number of users on linux-mtd list wanted to use
NAND wait-pin monitoring on OMAP devices, so I have just looped
them if they see any concerns.
Otherwise, no further concerns from me.
with regards, pekon
------------------------
Powered by BigRock.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
