All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: <linux-snps-arc@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, Noam Camus <noamc@ezchip.com>
Subject: Re: [PATCH v4 2/5] ARC: clocksource: DT based probe
Date: Thu, 14 Apr 2016 14:56:19 +0530	[thread overview]
Message-ID: <570F623B.3000105@synopsys.com> (raw)
In-Reply-To: <570E7263.8070108@arm.com>

On Wednesday 13 April 2016 09:52 PM, Marc Zyngier wrote:
>> -int arc_counter_setup(void)
>> > +static void __init arc_cs_setup_rtc(struct device_node *node)
>> >  {
>> > -	write_aux_reg(ARC_REG_TIMER1_LIMIT, ARC_TIMER_MAX);
>> > -	write_aux_reg(ARC_REG_TIMER1_CNT, 0);
>> > -	write_aux_reg(ARC_REG_TIMER1_CTRL, TIMER_CTRL_NH);
>> > +	int exists = cpuinfo_arc700[smp_processor_id()].extn.rtc;
>> > +
>> > +	if (WARN(!exists, "Local-64-bit-Ctr clocksource not detected"))
>> > +		return;
>> > +
>> > +	/* Local to CPU hence not usable in SMP */
>> > +	if (WARN(IS_ENABLED(CONFIG_SMP), "Local-64-bit-Ctr not usable in SMP"))
>> > +		return;
> Sorry if this outlines my lack of understanding of the ARC architecture,
> but what makes per-cpu timer unsuitable for SMP? I'd have thought that
> it was actually what you wanted...

This is clocksource, not clockevent. cs needs to synchronized across all cores so
that concurrent gtod call from threads on different cores gives you similar
values. This obviously is not true for the local RTC hardware timer.

WARNING: multiple messages have this Message-ID (diff)
From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH v4 2/5] ARC: clocksource: DT based probe
Date: Thu, 14 Apr 2016 14:56:19 +0530	[thread overview]
Message-ID: <570F623B.3000105@synopsys.com> (raw)
In-Reply-To: <570E7263.8070108@arm.com>

On Wednesday 13 April 2016 09:52 PM, Marc Zyngier wrote:
>> -int arc_counter_setup(void)
>> > +static void __init arc_cs_setup_rtc(struct device_node *node)
>> >  {
>> > -	write_aux_reg(ARC_REG_TIMER1_LIMIT, ARC_TIMER_MAX);
>> > -	write_aux_reg(ARC_REG_TIMER1_CNT, 0);
>> > -	write_aux_reg(ARC_REG_TIMER1_CTRL, TIMER_CTRL_NH);
>> > +	int exists = cpuinfo_arc700[smp_processor_id()].extn.rtc;
>> > +
>> > +	if (WARN(!exists, "Local-64-bit-Ctr clocksource not detected"))
>> > +		return;
>> > +
>> > +	/* Local to CPU hence not usable in SMP */
>> > +	if (WARN(IS_ENABLED(CONFIG_SMP), "Local-64-bit-Ctr not usable in SMP"))
>> > +		return;
> Sorry if this outlines my lack of understanding of the ARC architecture,
> but what makes per-cpu timer unsuitable for SMP? I'd have thought that
> it was actually what you wanted...

This is clocksource, not clockevent. cs needs to synchronized across all cores so
that concurrent gtod call from threads on different cores gives you similar
values. This obviously is not true for the local RTC hardware timer.

  reply	other threads:[~2016-04-14  9:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 11:40 [PATCH v4 0/5] Modernize ARC clocksource/clockevent/intc drivers Vineet Gupta
2016-04-13 11:40 ` Vineet Gupta
2016-04-13 11:40 ` [PATCH v4 1/5] ARC: clockevent: DT based probe Vineet Gupta
2016-04-13 11:40   ` Vineet Gupta
2016-04-13 12:59   ` Daniel Lezcano
2016-04-13 12:59     ` Daniel Lezcano
2016-04-14  9:32     ` Vineet Gupta
2016-04-14  9:32       ` Vineet Gupta
2016-04-14 10:05       ` Daniel Lezcano
2016-04-14 10:05         ` Daniel Lezcano
2016-04-18  6:46         ` [PATCH v5] " Vineet Gupta
2016-04-18  6:46           ` Vineet Gupta
2016-04-18  9:08           ` Daniel Lezcano
2016-04-18  9:08             ` Daniel Lezcano
2016-04-13 11:40 ` [PATCH v4 2/5] ARC: clocksource: " Vineet Gupta
2016-04-13 11:40   ` Vineet Gupta
2016-04-13 16:22   ` Marc Zyngier
2016-04-13 16:22     ` Marc Zyngier
2016-04-14  9:26     ` Vineet Gupta [this message]
2016-04-14  9:26       ` Vineet Gupta
2016-04-14  9:32       ` Marc Zyngier
2016-04-14  9:32         ` Marc Zyngier
2016-04-14  9:36         ` Vineet Gupta
2016-04-14  9:36           ` Vineet Gupta
2016-04-13 11:40 ` [PATCH v4 3/5] ARC: irq: export some IRQs again Vineet Gupta
2016-04-13 11:40   ` Vineet Gupta
2016-04-13 11:40 ` [PATCH v4 4/5] ARC: [intc-*] Do a domain lookup in primary handler for hwirq -> linux virq Vineet Gupta
2016-04-13 11:40   ` Vineet Gupta
2016-04-13 11:40 ` [PATCH v4 5/5] ARC: [intc-*] switch to linear domain Vineet Gupta
2016-04-13 11:40   ` Vineet Gupta
2016-04-18  6:51   ` Vineet Gupta
2016-04-18  6:51     ` Vineet Gupta
2016-04-18  9:41     ` Marc Zyngier
2016-04-18  9:41       ` Marc Zyngier

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=570F623B.3000105@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=noamc@ezchip.com \
    --cc=tglx@linutronix.de \
    /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.