[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKnu2MrHibKWezjEK+6oOnamkjxWnWwKfoVYRDBURZ3VkaoxEQ@mail.gmail.com>
Date: Thu, 12 Jul 2012 02:18:42 +0200
From: Linus Walleij <linus.ml.walleij@...il.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Marc Zyngier <marc.zyngier@....com>,
Will Deacon <will.deacon@....com>,
Mike Turquette <mike.turquette@...aro.org>
Subject: Re: [PATCH 33/36] AArch64: Generic timers support
I'm reviewing the only patch I really understand...
2012/7/6 Catalin Marinas <catalin.marinas@....com>:
> +/* This isn't really used any more */
> +#define CLOCK_TICK_RATE 1000
Is it still necessary to even have it there?
> + /* Try to determine the frequency from the device tree or CNTFRQ */
> + if (!of_property_read_u32(np, "clock-frequency", &freq))
> + arch_timer_rate = freq;
Have you documented the bindings for this thing?
> + arch_timer_calibrate();
Why is the ability to get this from a clk not contemplated?
I think this will be common. You could make it optional I think,
just like in the SMP TWD.
> diff --git a/include/clocksource/arm_generic.h b/include/clocksource/arm_generic.h
> new file mode 100644
> index 0000000..6933f8e
(...)
> +#ifndef __ASM_ARCH_TIMER_H
> +#define __ASM_ARCH_TIMER_H
This #ifdef name looks confusing, what about
#ifndef __CLKSOURCE_ARM_GENERIC_H?
I noticed you already saw the problem with naming it "arch timers"
and renamed it to "arm generic" so a leftover here :)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists