Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[pekon <pekon@pek-sem.com>]

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