One of these things (CONFIG_HZ) is not like the others..

[Russell King - ARM Linux]

On Mon, Jan 21, 2013 at 02:18:20PM -0800, John Stultz wrote:
> So we used to have the ACTHZ code to handle error from the HZ rate  
> requested and the HZ rate possible given the underlying hardware. That's  
> been moved to the register_refined_jiffies(), but do you have a sense if  
> there a reason it couldn't be used? I don't quite recall the bounds at  
> this second, so ~7% error might very well be too large.
>
> So yes, I suspect these sorts of platforms, where there are no modern  
> clocksource/clockevent driver, as well as further constraints (like  
> specific HZ) are likely not good candidates for a multi-arch build.

In this particular case, EBSA110 is not a candidate for multi-arch
build anyway, because it's ARMv4 and we're only really bothering with
ARMv6 and better.

Not only that, but the IO stuff on it is sufficiently obscure and
non-standard...