From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: Question: ARM: local timers: add num_possible_cpus() in local_timer_register()
Date: Mon, 14 Jan 2013 15:21:22 +0000 [thread overview]
Message-ID: <50F42272.3010804@arm.com> (raw)
In-Reply-To: <CAKvkGKfxT6cQF6rXmYZEL5tJbtsm0Yv4i1D_9NXQRsdbNFi2PQ@mail.gmail.com>
On 14/01/13 14:31, steve.zhan wrote:
> Hi,
> Russel, Marc,
> 2013/1/14 Marc Zyngier <marc.zyngier@arm.com>:
>> On 14/01/13 13:33, Steve zhan wrote:
>>
>> Hi Steve,
>>
>>> Do you think we should add num_possible_cpus() in
>>> local_timer_register() function, When core number is
>>>> 1, then reutrn TRUE? Enable the local timer only if
>>> we have more than one CPU, if the current config is
>>> SMP and setup_max_cpus >= 1, but if smp_init_cpus in
>>> platform code have set cpu possible value to One(that
>>> maybe read number from scu or other hardware), then
>>> percpu_timer_setup in smp_prepare_cpus have no chance
>>> to be called.
>>>
>>> For local timer, because local_timer_register have
>>> return 1, that will miss global timer register.
>>>
>>> Could you pls check it?
>>
>> I'm not sure I understand your question.
>>
>> We only enable the use of the SMP local timers infrastructure if we're
>> SMP and we have more that one CPU. If you only have one CPU up and
>> running, then you can still use your CPU local timer as a global timer.
>>
>> What would we gain by using the local timer infrastructure when we're
>> not running on SMP hardware?
>>
>> M.
>> --
>> Jazz is not dead. It just smells funny...
>>
>
> For these code:
> err = local_timer_register(&arch_timer_ops);
> if (err) {
> /*
> * We couldn't register as a local timer (could be
> * because we're on a UP platform, or because some
> * other local timer is already present...). Try as a
> * global timer instead.
> */
> arch_timer_global_evt.cpumask = cpumask_of(0);
> err = arch_timer_setup(&arch_timer_global_evt);
> }
>
> if err == 0, we have no register global arch timer, but platform code
> platsmp.c will set
> cpu possible number to one, that let percpu_timer_setup in
> smp_prepare_cpus have no
> chance to call becaue ncores = num_possible_cpus() is one.
> Is this right?
Ah, I get it now. Yes, this is a problem. Mark Rutland's patch series
actually fixes this issue entirely though. You may want to check it out.
M.
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2013-01-14 15:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 13:33 Question: ARM: local timers: add num_possible_cpus() in local_timer_register() Steve zhan
2013-01-14 13:35 ` Russell King - ARM Linux
2013-01-14 14:19 ` Marc Zyngier
2013-01-14 14:31 ` steve.zhan
2013-01-14 15:21 ` Marc Zyngier [this message]
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=50F42272.3010804@arm.com \
--to=marc.zyngier@arm.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.