[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1414492984.2295.8.camel@leyfoon-vm>
Date: Tue, 28 Oct 2014 18:43:04 +0800
From: Ley Foon Tan <lftan@...era.com>
To: Arnd Bergmann <arnd@...db.de>
CC: Thomas Gleixner <tglx@...utronix.de>,
Linux-Arch <linux-arch@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH v5 21/29] nios2: Time keeping
On Sel, 2014-10-28 at 10:23 +0100, Arnd Bergmann wrote:
> On Tuesday 28 October 2014 10:46:29 Ley Foon Tan wrote:
> > On Sun, Oct 26, 2014 at 5:10 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > > On Fri, 24 Oct 2014, Ley Foon Tan wrote:
> > >> +#ifndef _ASM_NIOS2_TIMEX_H
> > >> +#define _ASM_NIOS2_TIMEX_H
> > >> +
> > >> +typedef unsigned long cycles_t;
> > >> +
> > >> +extern cycles_t get_cycles(void);
> > >> +
> > >> +#define ARCH_HAS_READ_CURRENT_TIMER
> > >
> > > Why does NIOS need that? Does it have a hardware implementation
> > > dependent clock frequency which needs to be calibrated at boot time?
> > This is suggestion from Arnd to use read_current_timer instead of using
> > expensive delay loop calibration during boot.
>
> My mistake, sorry. I think the right way is to define
> calibrate_delay_is_known() rather than read_current_timer(), I was
> getting confused by the ARM implementation that does both.
Hi Arnd,
No problem, I can change that. But, seem that we don't need to have
calibrate_delay_is_known() as well. We can just set "lpj_fine" variable,
arm64 uses this.
BTW, do you have further comment for other patches in this series? Only
few minor updates since v4 patches and would like to get it into the
v3.18 merge window if possible. What's your opinion?
Thanks.
Regards
Ley Foon
--
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