From: John Stultz <john.stultz@linaro.org>
To: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Michal Simek <michal.simek@xilinx.com>
Subject: Re: clocksource with changing frequency?
Date: Thu, 20 Jun 2013 17:15:22 -0700 [thread overview]
Message-ID: <51C39B1A.5070902@linaro.org> (raw)
In-Reply-To: <f5e5d3d7-699d-4f89-80c8-849e432e8b26@VA3EHSMHS017.ehs.local>
On 06/20/2013 05:01 PM, Sören Brinkmann wrote:
> Hi all,
>
> I have a question/problem with a clocksource whose input frequency can
> change.
That behavior isn't supported by the clocksource core. We expect
frequency changing clocksources to be detected and disqualified (as we
do w/ freq changing TSCs on older laptops).
> On Zynq we use the cadece_ttc timer as clocksource. Its input clock is
> tightly coupled to the CPU clock. I.e. it changes when cpufreq scales
> the CPU clocks.
> To compensate this, I added a clock notifier doing this on a frequency
> change:
> clocksource_unregister(&ttccs->cs);
> clocksource_register_hz(&ttccs->cs, ndata->new_rate / PRESCALE);
This will definitely have problems if this is the only high-res capable
clocksource.
> This just seems not to be the most elegant way, a heavy weight operation
> and results in a couple of locking errors in combination with
> suspend/hotplug.
>
> Is there a sane solution for such a case? E.g. for clockevent devices
> there is a 'clockevents_update_freq()' to adjust to changing
> frequencies.
If you want to experiment with things, my suggestion would be to try to
fake a constant frequency clocksource in the clocksource driver(tracking
the change intervals and multiplying them up as needed). However, I
worry the quality of timekeeping won't be very good, as any latency in
the detection of the freq change will cause time error.
> I assume the sanest solution is an external oscillator as clock input,
> but I think our platforms don't provide that :(
I suspect your best bet, if there really is no other consistent clocks,
would be to disable highres timers and use the jiffies clocksource for
timekeeping, allowing you to change cpufreq to save power or increase
performance as you need. This will result in coarse timekeeping and
larger timer latency. But the only other approach is to fix the cpu freq
so the clocksource freq doesn't change (at the cost of cpu performance
or battery life - both of which I suspect are bigger issues then coarse
time).
thanks
-john
next prev parent reply other threads:[~2013-06-21 0:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-21 0:01 clocksource with changing frequency? Sören Brinkmann
2013-06-21 0:15 ` John Stultz [this message]
2013-06-21 8:12 ` Thomas Gleixner
2013-06-21 22:00 ` Sören Brinkmann
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=51C39B1A.5070902@linaro.org \
--to=john.stultz@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=soren.brinkmann@xilinx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox