All of lore.kernel.org
 help / color / mirror / Atom feed
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 12:06:52 +0800	[thread overview]
Message-ID: <519AF2DC.2040200@asianux.com> (raw)
In-Reply-To: <20130520095606.GH31359@mudshark.cambridge.arm.com>

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.

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 ?)

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.



Thanks.
-- 
Chen Gang

Asianux Corporation

WARNING: multiple messages have this Message-ID (diff)
From: Chen Gang <gang.chen@asianux.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Tony Lindgren <tony@atomide.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: kernel: compiling issue, need 'EXPORT_SYMBOL_GPL(read_current_timer)'
Date: Tue, 21 May 2013 12:06:52 +0800	[thread overview]
Message-ID: <519AF2DC.2040200@asianux.com> (raw)
In-Reply-To: <20130520095606.GH31359@mudshark.cambridge.arm.com>

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.

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 ?)

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.



Thanks.
-- 
Chen Gang

Asianux Corporation

  reply	other threads:[~2013-05-21  4:06 UTC|newest]

Thread overview: 34+ 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  6:48 ` Chen Gang
2013-05-20  7:15 ` Marc Zyngier
2013-05-20  7:15   ` Marc Zyngier
2013-05-20  9:56   ` Will Deacon
2013-05-20  9:56     ` Will Deacon
2013-05-21  4:06     ` Chen Gang [this message]
2013-05-21  4:06       ` Chen Gang
2013-05-21  6:13       ` Marc Zyngier
2013-05-21  6:13         ` Marc Zyngier
2013-05-21  8:41         ` Chen Gang
2013-05-21  8:41           ` Chen Gang
2013-05-21  8:58           ` Marc Zyngier
2013-05-21  8:58             ` Marc Zyngier
2013-05-21  9:26             ` Chen Gang
2013-05-21  9:26               ` Chen Gang
2013-05-21  8:53       ` Will Deacon
2013-05-21  8:53         ` Will Deacon
2013-05-21  9:27         ` Chen Gang
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-21  9:46           ` Chen Gang
2013-05-27 10:02           ` Chen Gang
2013-05-27 10:02             ` Chen Gang
2013-06-08  4:37             ` Chen Gang
2013-06-08  4:37               ` Chen Gang
2013-06-10  8:57               ` Will Deacon
2013-06-10  8:57                 ` Will Deacon
2013-06-13  1:12                 ` Chen Gang
2013-06-13  1:12                   ` Chen Gang
2013-06-10  8:57               ` Marc Zyngier
2013-06-10  8:57                 ` Marc Zyngier
2013-06-13  1:13                 ` Chen Gang
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=519AF2DC.2040200@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.