Re: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13]

george anzinger (george@mvista.com)
Tue, 17 Jun 2003 17:47:38 -0700


Vojtech Pavlik wrote:
> On Tue, Jun 17, 2003 at 04:24:04PM -0700, David Mosberger wrote:
>
>>>>>>>On Wed, 18 Jun 2003 01:14:11 +0200, Vojtech Pavlik <vojtech@suse.cz> said:
>>
>> >> Sounds much better to me. Wouldn't something along the lines of
>> >> this make the most sense:
>>
>> >> #ifdef __ARCH_PIT_FREQ # define PIT_FREQ __ARCH_PIT_FREQ #else #
>> >> define PIT_FREQ 1193182 #endif
>>
>> >> After all, it seems like the vast majority of legacy-compatible
>> >> hardware _do_ use the standard frequency.
>>
>> Vojtech> Now, if this was in some nice include file, along with the
>> Vojtech> definition of the i8253 PIT spinlock, that'd be
>> Vojtech> great. Because not just the beeper driver uses the PIT,
>> Vojtech> also some joystick code uses it if it is available.
>>
>>ftape, too. The LATCH() macro should also be moved to such a header
>>file, I think. How about just creating asm/pit.h? Only platforms
>>that need to (potentially) support legacy hardware would need to
>>define it. E.g., on ia64, we could do:
>>
>> #ifndef _ASM_IA64_PIT_H
>> #define _ASM_IA64_PIT_H
>>
>> #include <linux/config.h>
>>
>> #ifdef CONFIG_LEGACY_HW
>> # define PIT_FREQ 1193182
>> # define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ)
----------------------------------^^^^^^^^^^^^^^^
should be PIT_FREQ me thinks :)

-g
>> #endif
>>
>> #endif /* _ASM_IA64_PIT_H */
>>
>>This way, machines that support legacy hardware can define
>>CONFIG_LEGACY_HW and on others, the macro can be left undefined, so
>>that any attempt to compile drivers requiring legacy hw would fail to
>>compile upfront (much better than accessing random ports!).
>
>
> Yes, that looks very good indeed. Riley?
>

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

- 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/