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... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
