Re: [PATCH] arm64: kernel: compiling issue, need'EXPORT_SYMBOL_GPL(read_current_timer)'

[Will Deacon]

On Tue, May 21, 2013 at 05:06:52AM +0100, Chen Gang wrote:
> On 05/20/2013 05:56 PM, Will Deacon wrote:
> > Should be ok once the arch timer driver has moved exclusively to virtual
> > time. I'm also not sure we even need to implement read_current_timer() --
> > it's only used for delay-loop calibration, which we don't need for the
> > arch timer.
> > 
> 
> For whether we need implement read_current_timer():
> 
>   many platforms have implemented it (openrisc, arm, sparc, hexagon, avr32, x86).
>   it is called by init/calibrate.c when 'ARCH_HAS_READ_CURRENT_TIMER' is defined.
>   since arm64 can implement it, better to provide it as an architect features to let outside use.

No, that code is not needed on arm64 because we calibrate the delay loop
statically using a known timer frequency.

> For the implementation of read_current_timer():
> 
>   it has to face various configurations
>     (e.g. CONFIG_ARM_ARCH_TIMER, arch_timer_read_zero, arch_counter_get_cntvct, arch_counter_get_cntpct)
>   so better still use variable instead of.
>     (excuse me, I do not know what is 'CNTVCT_EL0', is it like a constant number ?)

cntvct_el0 is a system register, which provides the virtual counter value.

> For the implementation of get_cycles()
> 
>   if read_current_timer() is provided,
>   better to let get_cycles() to call it, instead of implement once again.

You can implement it as a macro if you like, I'm just suggesting that we
might not need read_current_timer after all.

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