Messages in this thread | | | Date | Wed, 7 Jan 2015 01:41:33 -0500 (EST) | From | Nicolas Pitre <> | Subject | Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix pyaudio (and probably more) |
| |
On Tue, 6 Jan 2015, Catalin Marinas wrote:
> I think that's where the misunderstanding is. We don't have any idea > how many times we go through the delay loop. We just go through the > delay loop until the counter (driven by an independent frequency) > changes X times. From arch/arm/lib/delay.c: > > static void __timer_delay(unsigned long cycles) > { > cycles_t start = get_cycles(); > > while ((get_cycles() - start) < cycles) > cpu_relax(); > } > > where the number of cycles is based on the pre-calculated lpj_fine > value using the counter/timer frequency (read from DT or hardware). > > I think Nico already pointed out that the way we use loops_per_jiffy > when the udelay is timer-based is probably wrong. We actually need a > ticks_per_jiffy which has nothing to do with loops_per_jiffy, the > former is actually completely independent from the CPU speed.
We already have the former.
The patch I posted rehabilitated thelater. That's the sanest we can do. Then we have both a timer based delay and a bogomips that is somewhat related to CPU speed again.
I also posted another patch to remove the 3355 bogomips limitation on ARM.
Nicolas
| |