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