Riley> Hi all.
Riley> I have no objection to anything along these lines. The basic scenario
Riley> is simply this:
Riley> 1. On ALL architectures except for IA64 and ARM there is a SINGLE
Riley> value for CLOCK_TICK_RATE that is used by several GENERIC drivers.
Riley> Currently, that value is used as a MAGIC NUMBER that corresponds
Riley> to the value in the Ix86 case, which is clearly wrong.
What do you mean be "generic"? AFAIK, the drivers you're talking
about all depend on there being an 8259-style PIT. As such, they
depend on the 8259 and are not generic. This dependency should be
made explicit.
BTW: I didn't think Alpha derived its clock-tick from the PIT either,
but I could be misremembering. Could someone more familiar with Alpha
confirm or deny?
Riley> 2. According to the IA64 people, those GENERIC drivers are apparently
Riley> irrelevant for that architecture, so making the CORRECT change of
Riley> replacing those magic numbers in the GENERIC drivers with the
Riley> CLOCK_TICK_RATE value will make no difference to IA64.
That's not precise: _some_ ia64 machies do have legacy hardware and
those should be able to use 8259-dependent drivers if they choose to
do so.
Moreover, the current drivers would compile just fine on ia64, even
though they could not possibly work correctly with the current use of
CLOCK_TICK_RATE. With a separate header file (and a config option),
these dependencies would be made explicit and that would improve
overall cleanliness.
In other words, I still think the right way to go about this is to
have <asm/pit.h>. On x86, this could be:
-- #include <asm/timex.h>#define PIT_FREQ CLOCK_TICK_RATE #define PIT_LATCH ((PIT_FREQ + HZ/2) / HZ)
--If you insist, you could even put this in asm-generic, though personally I don't think that's terribly elegant.
On ia64, <asm/pit.h> could be:
#ifdef CONFIG_PIT # define PIT_FREQ 1193182 # define PIT_LATCH ((PIT_FREQ + HZ/2) / HZ) #endif
--david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/