From: gang.chen@asianux.com (Chen Gang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: kernel: compiling issue, need 'EXPORT_SYMBOL_GPL(read_current_timer)'
Date: Tue, 21 May 2013 16:41:19 +0800 [thread overview]
Message-ID: <519B332F.1000404@asianux.com> (raw)
In-Reply-To: <5bf8a8dd20ecd01c14f0ed9aa054f2df@localhost>
On 05/21/2013 02:13 PM, Marc Zyngier wrote:
> On Tue, 21 May 2013 12:06:52 +0800, Chen Gang <gang.chen@asianux.com>
> wrote:
>> On 05/20/2013 05:56 PM, Will Deacon wrote:
>>> On Mon, May 20, 2013 at 08:15:04AM +0100, Marc Zyngier wrote:
>>>> On Mon, 20 May 2013 14:48:05 +0800, Chen Gang <gang.chen@asianux.com>
>>>> wrote:
>>>>> Need 'EXPORT_SYMBOL_GPL(read_current_timer)' if build with
>>>>> allmodconfig.
>>>>>
>>>>> The related error:
>>>>> ERROR: "read_current_timer" [lib/rbtree_test.ko] undefined!
>>>>> ERROR: "read_current_timer" [lib/interval_tree_test.ko] undefined!
>>>>> ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
>>>>> ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
>>>>>
>>>>>
>>>>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>>>>> ---
>>>>> arch/arm64/kernel/time.c | 1 +
>>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
>>>>> index a551f88..7fcba80 100644
>>>>> --- a/arch/arm64/kernel/time.c
>>>>> +++ b/arch/arm64/kernel/time.c
>>>>> @@ -73,6 +73,7 @@ int read_current_timer(unsigned long *timer_value)
>>>>> *timer_value = arch_timer_read_counter();
>>>>> return 0;
>>>>> }
>>>>> +EXPORT_SYMBOL_GPL(read_current_timer);
>>>>>
>>>>> void __init time_init(void)
>>>>> {
>>>>
>>>> While this solves the problem, I'm not sure this is the best fix. The
>>>> real
>>>> issue is with get_cycles, which is a macro around read_current_timer.
>>>>
>>>> AArch32 exports it because of the number of timer implementations. On
>>>> arm64, we should be able to just return CNTVCT_EL0.
>>>>
>>>> Catalin, Will, what do you think?
>>>
>>> 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.
>
> Nobody disputes the interest of read_current_timer.
>
It is for Will said "I'm also not sure we even need to implement
read_current_timer()".
I think we still need it.
>> 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 ?)
>
> Architected timer is mandatory on arm64, so we can always rely on it it be
> present. CNTVCT_EL0 is the system register accessing the Virtual Counter,
> which is basically what read_current_timer() returns.
>
OK, thanks. for CNTVCT_EL0, can we use arch_counter_get_cntvct() which
is defined in "arch/arm64/include/asm/arch_timer.h" ?
>> 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.
>
> There is certainly some value in reusing existing code, but in this
> particular case we can simply inline two instructions (isb + mrs
> cntvct_el0), and I'm not even completely sure about the isb.
>
OK, thanks.
So, how about the fix below :)
------------------------diff begin-------------------------------
diff --git a/arch/arm64/include/asm/timex.h b/arch/arm64/include/asm/timex.h
index b24a31a..768ba44 100644
--- a/arch/arm64/include/asm/timex.h
+++ b/arch/arm64/include/asm/timex.h
@@ -16,11 +16,13 @@
#ifndef __ASM_TIMEX_H
#define __ASM_TIMEX_H
+#include <asm/arch_timer.h>
+
/*
* Use the current timer as a cycle counter since this is what we use for
* the delay loop.
*/
-#define get_cycles() ({ cycles_t c; read_current_timer(&c); c; })
+#define get_cycles() arch_counter_get_cntvct()
#include <asm-generic/timex.h>
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index a551f88..6d7ce08 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -38,6 +38,7 @@
#include <asm/thread_info.h>
#include <asm/stacktrace.h>
+#include <asm/arch_timer.h>
#ifdef CONFIG_SMP
unsigned long profile_pc(struct pt_regs *regs)
@@ -70,7 +71,7 @@ unsigned long long notrace sched_clock(void)
int read_current_timer(unsigned long *timer_value)
{
- *timer_value = arch_timer_read_counter();
+ *timer_value = arch_counter_get_cntvct();
return 0;
}
------------------------diff end---------------------------------
--
Chen Gang
Asianux Corporation
next prev parent reply other threads:[~2013-05-21 8:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 6:48 [PATCH] arm64: kernel: compiling issue, need 'EXPORT_SYMBOL_GPL(read_current_timer)' Chen Gang
2013-05-20 7:15 ` Marc Zyngier
2013-05-20 9:56 ` Will Deacon
2013-05-21 4:06 ` Chen Gang
2013-05-21 6:13 ` Marc Zyngier
2013-05-21 8:41 ` Chen Gang [this message]
2013-05-21 8:58 ` Marc Zyngier
2013-05-21 9:26 ` Chen Gang
2013-05-21 8:53 ` Will Deacon
2013-05-21 9:27 ` Chen Gang
2013-05-21 9:46 ` [PATCH v2] arm64: kernel: compiling issue, need delete read_current_timer() Chen Gang
2013-05-27 10:02 ` Chen Gang
2013-06-08 4:37 ` Chen Gang
2013-06-10 8:57 ` Will Deacon
2013-06-13 1:12 ` Chen Gang
2013-06-10 8:57 ` Marc Zyngier
2013-06-13 1:13 ` Chen Gang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519B332F.1000404@asianux.com \
--to=gang.chen@asianux.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).