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 15:06:10 +0530	[thread overview]
Message-ID: <570F648A.2060307@synopsys.com> (raw)
In-Reply-To: <570F63A1.3070904@arm.com>

On Thursday 14 April 2016 03:02 PM, Marc Zyngier wrote:
>> 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.

Not really - hardware wise the SMP support is pretty recent and before that we
only had UP cores. So transition from 32 TIMER1 to 64 bit RTC was only a natural
progression in improvements and in theory SoC guys throw in this local timer into
the config. We just prevent SMP linux from using it.

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 15:06:10 +0530	[thread overview]
Message-ID: <570F648A.2060307@synopsys.com> (raw)
In-Reply-To: <570F63A1.3070904@arm.com>

On Thursday 14 April 2016 03:02 PM, Marc Zyngier wrote:
>> 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.

Not really - hardware wise the SMP support is pretty recent and before that we
only had UP cores. So transition from 32 TIMER1 to 64 bit RTC was only a natural
progression in improvements and in theory SoC guys throw in this local timer into
the config. We just prevent SMP linux from using it.

  reply	other threads:[~2016-04-14  9:36 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
2016-04-14  9:32         ` Marc Zyngier
2016-04-14  9:36         ` Vineet Gupta [this message]
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=570F648A.2060307@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.