Bogus usage of HZ in cfi_cmdset_0001.c

Nicolas Pitre nico at cam.org
Thu Jul 5 09:42:42 EDT 2007


On Thu, 5 Jul 2007, Guennadi Liakhovetski wrote:

> Hi
> 
> There are several places in cfi_cmdset_0001.c (possibly others?) like
> 
> 		} else if (usec >= 1000000/HZ) {
> 		if (sleep_time >= 1000000/HZ) {
> 			sleep_time = 1000000/HZ;
> 	udelay = (!extp || !(extp->FeatureSupport & (1 << 5))) ? 1000000/HZ : 0;
> 
> which means timeout (e.g., waiting for hardware) are hard-coded in ticks, 
> which can have variable duration. What should they really be?

They should be exactly what they are, on purpose.

Did you read the comments surrounding those locations?  They should 
provide sufficient hints to explain why things were done that way.

> The problem I am seeing is that on a PXA270-based system the unlock 
> operation sometimes returns with a timeout, when the CPU is running with 
> 520MHz, no problem up to 416MHz. Any idea?

Maybe your static memory space bus timings are not set up properly in 
the 520 MHz case?  In any case the CPU clock doesn't change the value of 
HZ anyway.


Nicolas



More information about the linux-mtd mailing list