[PATCH 2/2] mtd: nand: use hrtimer to measure timeout in nand_wait{_ready, }

Johan Gunnarsson johan.gunnarsson at axis.com
Tue May 22 10:24:47 EDT 2012



> -----Original Message-----
> From: Artem Bityutskiy [mailto:dedekind1 at gmail.com]
> Sent: den 22 maj 2012 12:25
> To: Johan Gunnarsson
> Cc: Brian Norris; linux-mtd at lists.infradead.org; Jesper Nilsson
> Subject: RE: [PATCH 2/2] mtd: nand: use hrtimer to measure timeout in
> nand_wait{_ready, }
> 
> On Tue, 2012-05-22 at 10:52 +0200, Johan Gunnarsson wrote:
> > Not an expert on the MTD framework -- but I believe the 400 comes
> from
> > the comment above nand_wait(): "Wait for command done. This applies
> to
> > erase and program only. Erase can take up to 400ms and program up to
> > 20ms according to general NAND and SmartMedia specs."
> 
> Most probably this legacy can be killed along with the IPAQ h1910
> driver you pointed. But could you please start with cleaning these
> functions up and turning the "!chip->dev_ready()" case into a simple
> msleep() or
> mdelay() for the panic case?
> 

I don't understand what clean-up is needed here. Can you please elaborate?

The case you mentioned earlier doesn't really make sense to me:

if (!dev_ready()) {
	msleep(400);
	return
}

Making a single call to dev_ready() and giving up if FALSE is wrong IMHO, since we very much want to poll dev_ready() and return as soon as it turns TRUE (or timeout.) Assuming you actually mean "if(!dev_ready)) {" also doesn't make sense since checks like that exists on all path leading to nand_wait_ready().


More information about the linux-mtd mailing list