mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH RFC 0/3] clocksource/cadence_ttc: Handle frequency changes
@ 2013-08-29 17:53 Soren Brinkmann
  2013-08-29 17:53 ` [PATCH RFC 1/3] clocksource/cadence_ttc: Remove clocksource clock notifier Soren Brinkmann
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Soren Brinkmann @ 2013-08-29 17:53 UTC (permalink / raw)
  To: Michal Simek, Daniel Lezcano, Thomas Gleixner, John Stultz
  Cc: linux-kernel, linux-arm-kernel, Soren Brinkmann

Hi,

I've asked Thomas and John before, what to do about a clocksource with
variable input frequency. It looks like the easiest and probably also
best solution is to just not use a timer with a variable frequency - as
John suggested.

I thought another option to get around removing this feature might be
to use clock notifiers and updating the timer's prescaler on the fly.
But that seems to become messy really fast and causes more problems in
cases multiple clocksources are available, since the clock notifier
might impose the driver's restrictions on the input clock, although it
is not even the currently used clocksource.

I have sketched out both approaches in two series.

The first one, which should directly follow this email, is to introduce
a new flag in the driver's DT bindings, which marks the input clock as
'unstable'. In case this flag is present, the timer does not register
itself as clocksource (and not as sched_clock either, of course).
The clockevent feature is not affected.

The second approach uses clock and PM notifiers to adjust the timer's
pre-scaler on frequency changes. As mentioned above, I didn't see a way
to find out whether the timer is the current clock source to not enforce
restrictions in case it is not.

I'm actually not fully convinced of either approach. So, please let me
know of better solutions, or how to make either approach acceptable.
If everything works well, I send out the second series as reply to this
cover letter. I have both series listed below. Both are based on
tip/timers/core.

	Thanks,
	Sören


Approach 1, don't register as clocksource:
Soren Brinkmann (3):
  clocksource/cadence_ttc: Remove clocksource clock notifier
  clocksource/cadence_ttc: Make clocksource optional
  arm: dt: zynq: Mark TTC input clock as unstable

 .../bindings/timer/cadence,ttc-timer.txt           |  4 ++
 arch/arm/boot/dts/zynq-7000.dtsi                   |  2 +
 drivers/clocksource/cadence_ttc_timer.c            | 47 +---------------------
 3 files changed, 8 insertions(+), 45 deletions(-)

Approach 2, use notifiers to adjust:
Soren Brinkmann (1):
  clocksource/cadence_ttc: Overhaul clocksource frequency adjustment

 drivers/clocksource/cadence_ttc_timer.c | 141 +++++++++++++++++++++++++++-----
 1 file changed, 121 insertions(+), 20 deletions(-)

-- 
1.8.4


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-08-29 17:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-29 17:53 [PATCH RFC 0/3] clocksource/cadence_ttc: Handle frequency changes Soren Brinkmann
2013-08-29 17:53 ` [PATCH RFC 1/3] clocksource/cadence_ttc: Remove clocksource clock notifier Soren Brinkmann
2013-08-29 17:53 ` [PATCH RFC 2/3] clocksource/cadence_ttc: Make clocksource optional Soren Brinkmann
2013-08-29 17:53 ` [PATCH RFC 3/3] arm: dt: zynq: Mark TTC input clock as unstable Soren Brinkmann
2013-08-29 17:55 ` [PATCH RFC] clocksource/cadence_ttc: Overhaul clocksource frequency adjustment Soren Brinkmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®