[PATCH 3/6] refactor mtd wait code

[Matthieu CASTET]

Artem Bityutskiy a écrit :
> On Tue, 2011-06-28 at 11:00 +0300, Artem Bityutskiy wrote:
>> On Sun, 2011-06-26 at 18:26 +0200, Matthieu CASTET wrote:
>>> +/**
>>> +  * This is call after sending a read command, or for autoincrement
>>> +  * chip that need it (!NAND_NO_READRDY).
>>> +  *
>>> +  * We can't call NAND_CMD_STATUS here, because the read command
>>> +  * is not finished
>>> +  */
>>> +static void nand_wait_read(struct mtd_info *mtd, struct nand_chip *chip)
>>> +{
>>> +	/*
>>> +	 * If we don't have access to the busy pin, we apply the given
>>> +	 * command delay
>>> +	 */
>>> +	if (!chip->dev_ready) {
>>> +		udelay(chip->chip_delay);
>>> +	}
>>> +	else {
>>> +		/* Apply this short delay always to ensure that we do wait tWB in
>>> +		 * any case on any machine. */
>>> +		ndelay(100);
>> Please, all these hard-coded numbers should be hidden in the specific
>> driver.
> 
> Or could you please explain a bit better why this delay has to be part
> of nand core? And why it is 100 and not 200?
> 
This delay is already in the nand core. I only put it in a common function :

> -	/* Apply this short delay always to ensure that we do wait tWB in
> -	 * any case on any machine. */
> -	ndelay(100);
> -
> -	nand_wait_ready(mtd);
> +	/* This applies to read commands */
> +	nand_wait_read(mtd, chip);
>  }

> -
> -	/* Apply this short delay always to ensure that we do wait tWB in
> -	 * any case on any machine. */
> -	ndelay(100);
> -
> -	nand_wait_ready(mtd);
> +	/* This applies to read commands */
> +	nand_wait_read(mtd, chip);
>  }


And I think it is 100 ns, because it is the worst case for tWB.


Matthieu