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

Russell King - ARM Linux linux at
Mon Jan 21 17:44:49 EST 2013

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

More information about the linux-arm-kernel mailing list