Re: question: Why the nand_wait() wait for 20ms for nand program.

[Huang Shijie <b32955@freescale.com>]

于 2013年01月21日 17:32, Matthieu CASTET 写道:
> Huang Shijie a écrit :
>> 于 2013年01月21日 17:15, Matthieu CASTET 写道:
>>> Huang Shijie a écrit :
>>>>    于 2013年01月21日 16:57, Matthieu CASTET 写道:
>>>>> Huang Shijie a écrit :
>>>>>> 于 2013年01月18日 20:26, Matthieu CASTET 写道:
>>>>>>> Huang Shijie a écrit :
>>>>>>>> Hi all:
>>>>>>>> Why the nand_wait() wait for 20ms for nand program. could we
>>>>>>>> expand this time to 40ms? I have a nand chip : Micron MT29F64G08CBABAWP.
>>>>>>>> The chip's BUSY/READY pin may needs more then 20ms to become ready,
>>>>>>>> though its
>>>>>>>> datasheet tells me the tPROG's max value is 2.5ms.
>>>>>>>>
>>>>>>> Don't you have an hardware problem (missing pullup/down on ready busy pin) ?
>>>>>>>
>>>>>>> If the datasheet say the max value is 2.5 ms , how it can be more than 20 ms.
>>>>>> I finally found the root cause.
>>>>>>
>>>>>> I added the do_gettimeofday() in the nand_wait() to measure the
>>>>>> READY/BUSY time. The code is like this:
>>>>>> ---------------------------------------------------- code start
>>>>>>
>>>>> Could you dump jiffies and timeo in your code ?
>>>> The following just shows some part of the log:
>>>>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   665911, 664170>,<1, 1741>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   735989, 734626>,<1, 1363>
>>>> [my_nand_wait]status : 80,<21480, 21480>,<   805693, 804825>,<0, 868>
>>>>
>>>>    From the log, we can see that the kernel just waits for 1741us to break
>>>> the while loop,
>>>> not 20ms.
>>>>
>>> Yes but you should display jiffies and timeo value to understand why the kernel
>>> thinks 2 jiffies elapsed.
>> I dumpped the jiffies and timeo too. The jiffies is really _equal_ to
>> the timeo, and then the while loop breaks.
>>
>> thanks for your comments.
>>
>> I think there is something wrong with the timer.
>>
> timeo += (HZ * 20) / 1000;
>
> So what is the value of HZ ?
>
> In order (HZ * 20) / 1000 is 0 HZ should be<  50.

thanks for your help.

I really appreciate it.

this bug is caused by our unstable kernel.
I tried with some other stable code, the issue never occurs.


thanks
Huang shijie
>
> Matthieu
>