ARM: 7653/2: do not scale loops_per_jiffy when using a constant delay clock

[Nicolas Pitre]

On Thu, 7 Mar 2013, Will Deacon wrote:

> On the topic of this patch: I still think that we should revert it and
> require cpufreq drivers to pass CPUFREQ_CONST_LOOPS in their flags (I guess
> the cpu0 platform data may need extending to take some flags).

I must disagree.  The constness here is a property of the timer source 
used to implement one of the udelay() providers.  Constness has no 
relation with cpufreq which may or may not impact a given udelay 
implementation.

> Longer term, we might want to assess the binding between timer-based 
> delays and loops_per_jiffy, but that's an entirely new problem.

Actually I do think that the lpj should always be scaled regardless, as 
this has meaning only for a CPU loop.  This is even more important if 
there is the possibility for switching between different 
implementations. The local timer based udelay implementation should 
simply never factor in lpj into its delay evaluation.

So the current patch is a stop gap to fix the problem today.  When 
something better is proposed we can remove this fix.


Nicolas