public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"john.stultz@linaro.org" <john.stultz@linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Subject: Re: update timer frequencies
Date: Fri, 4 Aug 2017 12:28:43 +0530	[thread overview]
Message-ID: <cd7ddf4e-ecde-8450-99c4-80932a7952d8@synopsys.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1703101113370.3681@nanos>

Hi Thomas,

On 03/10/2017 03:58 PM, Thomas Gleixner wrote:
> Vlad,
> 
> On Fri, 10 Mar 2017, Vlad Zakharov wrote:
>>
>> I am trying to implement a cpufreq driver for ARC CPUs.  The point is
>> that ARC timers (including those are used for timekeeping) are driven by
>> the same clock as ARC CPU core(s).
> 
> To be honest: That's broken by design and you really should go and tell
> your hardware folks to fix that. Proper timekeeping is essential for any
> Operating System (not only Linux).
> 
> It's well known for more than TWO decades that changing the frequency of
> the timekeeper clocksource is a complete disaster, but obviously every
> hardware vendor has to learn that the hard way instead of simply learning
> from history.
> 
...
> 
> Your hardware design is broken by making the clocksource clock depend on
> the CPU frequency. Tell your hardware people to fix that or just use a
> seperate independent clocksource.

The hardware is being changed and I had a couple of questions to help do it right:

1. The clocksource timers TIMER1, GFRC, RTC etc will now be clocked independent of 
core using a fixed clk. Is there some magic freq value which best works so we can 
recommend that to implementors. AFAIKR ARM has 24 MHz.

2. I'm not sure if the timer generating interrupts (periodic or oneshot) needs to 
be fed invariant fixed clk or dynamic core clk. Naively it should follow the core 
- but what happens to scheduled timers (say TCP timeouts): if this clk changes - 
they need to be canceled/updated. If it doesn't then the notion of timing is 
broken ? I'm likely not thinking this through correctly.

Thx,
-Vineet

  reply	other threads:[~2017-08-04  6:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10  9:17 update timer frequencies Vlad Zakharov
2017-03-10 10:28 ` Thomas Gleixner
2017-08-04  6:58   ` Vineet Gupta [this message]
2017-08-04  9:38     ` Peter Zijlstra

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=cd7ddf4e-ecde-8450-99c4-80932a7952d8@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox