All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.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 10:32:17 +0100	[thread overview]
Message-ID: <570F63A1.3070904@arm.com> (raw)
In-Reply-To: <570F623B.3000105@synopsys.com>

On 14/04/16 10:26, Vineet Gupta wrote:
> 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.

Unsynchronized counters on SMP HW, who would have thought! ;-) I guess
each and every architecture has to repeat the same mistakes.

Thanks for shedding some light on it.

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH v4 2/5] ARC: clocksource: DT based probe
Date: Thu, 14 Apr 2016 10:32:17 +0100	[thread overview]
Message-ID: <570F63A1.3070904@arm.com> (raw)
In-Reply-To: <570F623B.3000105@synopsys.com>

On 14/04/16 10:26, Vineet Gupta wrote:
> 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.

Unsynchronized counters on SMP HW, who would have thought! ;-) I guess
each and every architecture has to repeat the same mistakes.

Thanks for shedding some light on it.

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2016-04-14  9:32 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
2016-04-14  9:26       ` Vineet Gupta
2016-04-14  9:32       ` Marc Zyngier [this message]
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=570F63A1.3070904@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=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=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.