Re: [PATCH] Remove CLOCK_TICK_RATE from acpi_pm clocksource driver

[John Stultz]

On Wed, 2011-08-03 at 17:08 -0700, Deepak Saxena wrote:
> The acpi_pm clocksource driver uses CLOCK_TICK_RATE which is
> defined as PIT_TICK_RATE on x86. This patch cleans it up to
> just use the later so that CLOCK_TICK_RATE can be depecrated.
> 
> Signed-off-by: Deepak Saxena <dsaxena@xxxxxxxxxx>
> ---
>  drivers/clocksource/acpi_pm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
> index effe797..6b5cf02 100644
> --- a/drivers/clocksource/acpi_pm.c
> +++ b/drivers/clocksource/acpi_pm.c
> @@ -143,7 +143,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_LE,
>  #ifndef CONFIG_X86_64
>  #include <asm/mach_timer.h>
>  #define PMTMR_EXPECTED_RATE \
> -  ((CALIBRATE_LATCH * (PMTMR_TICKS_PER_SEC >> 10)) / (CLOCK_TICK_RATE>>10))
> +  ((CALIBRATE_LATCH * (PMTMR_TICKS_PER_SEC >> 10)) / (PIT_TICK_RATE>>10))
>  /*
>   * Some boards have the PMTMR running way too fast. We check
>   * the PMTMR rate against PIT channel 2 to catch these cases.

I suspect the PMTMR_EXPECTED_RATE is not so sensitive that it actually
needs to use CLOCK_TICK_RATE or PIT_TICK_RATE here. 

Instead we probably should rework mach_countup() to return how long it
ran for (in nsecs), since the acpi_pm code really shouldn't need to know
PIT_TICK_RATE details at all.

That said, mach_countup is pretty old and crusty code that is important
to TSC and loop-per-jiffy calibration. So I'm not sure if there's much
gain to digging in and mucking with things there. 

So for now, the PIT_TICK_RATE change seems like a fair change.

Acked-by: John Stultz <john.stultz@xxxxxxxxxx>

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