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

[Vojtech Pavlik <vojtech@suse.cz>]

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)
>  #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?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR