[PATCH]Fixes of performance and stability issues in CFI driver.

[Nicolas Pitre]

On Tue, 27 Jun 2006, David Woodhouse wrote:

> On Tue, 2006-06-27 at 14:38 -0400, Nicolas Pitre wrote:
> > OK, but I think this should all be done within cfi_udelay().  Or maybe 
> > not since cfi_udelay() is used by other chip drivers.  
> 
> I'm not sure I follow that argument. cfi_udelay() is used in basically
> the same circumstances by other chip drivers, so why not do it there
> instead of open-coding it?

The code simply ends up being simpler.  With my patch it looks like:

        /* set our timeout to 8 times the expected delay */
        timeo = chip_op_time * 8;
	[...]
                /* OK Still waiting. Drop the lock, wait a while and retry. */
                spin_unlock(chip->mutex);
                if (chip_op_time/2 >= 1000000/HZ) {
                        /*
                         * Half of the normal delay still remaining
                         * can be performed with a sleeping delay instead
                         * of busy waiting.
                         */
                        msleep(chip_op_time/2000);
                        timeo -= chip_op_time/2;
                        chip_op_time -= chip_op_time/2;
                } else {
                        udelay(1);
                        cond_resched();
                        timeo--;
                }
                spin_lock(chip->mutex);

I think trying to fit cfi_udelay() here would add more complexity than 
it intend to prevent since the condition needed to update the delay 
variables will still have to remain out of cfi_udelay() anyway.


Nicolas