From: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Rob Herring <rob.herring@calxeda.com>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Russell King <linux@arm.linux.org.uk>,
Michal Simek <michal.simek@xilinx.com>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 4/9] clocksource/cadence_ttc: Use enable/disable_irq
Date: Fri, 6 Dec 2013 14:47:32 -0800 [thread overview]
Message-ID: <f6d25456-8e30-4792-b184-21eb02dfaa1c@AM1EHSMHS001.ehs.local> (raw)
In-Reply-To: <alpine.DEB.2.02.1311281939000.30673@ionos.tec.linutronix.de>
Hi Thomas,
sorry for the delay, but I couldn't find time any earlier.
On Thu, Nov 28, 2013 at 08:07:10PM +0100, Thomas Gleixner wrote:
> On Thu, 28 Nov 2013, Sören Brinkmann wrote:
> > On Thu, Nov 28, 2013 at 03:18:50PM +0100, Thomas Gleixner wrote:
> > > Now the problem with this device is that it is not a per cpu
> > > device. It's a global device, so this update can conflict with a
> > > parallel access on the other CPU. Now the disable_irq() only prevents
> > > that the other CPU can handle a device interrupt from that timer. But
> > > it does not prevent any parallel access from e.g. the idle code path
> > > which will try to reprogram it.
> >
> > Does that mean interrupts need to be disabled globally? Also, does the
>
> Globally disabling interrupts is not going to work, except you want to
> use stomp_machine(). But that would be overkill.
>
> > cpuidle path depend on interrupts or can it interfere no matter what?
>
> It can interfere no matter what. The broadcast is modified for the cpu
> which loses its per cpu timer due to the idle state via
>
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ...);
>
> > > Soren, is that timer used as the broadcast device ?
> >
> > Yes, this is the only broadcast capable timer on Zynq, AFAIK. Other than
> > the TTC we only have the arm_global_timer and smp_twd timers, which both
> > are per_cpu devices and thus not broadcast capable.
>
> There is a solution to this. We can identify the broadcast device in
> the core and serialize all callers including interrupts on a different
> cpu against the update. So no need for the disable/enable_irq() dance.
IIUC, and please correct me if I'm wrong, with the patch I'd simply call
'clockevents_update_freq() without having to disable IRQs. But I'm not
sure whether periodic mode is covered. I found, that I had to reprogram
the timer interval in my clock notifier callback when the timer
frequency changes. I think 'clockevents_update_freq()' only handles
oneshot mode. For that reason I call 'ttc_set_interval()' in the clock
notifier in case the timer is in periodic mode. For that call we'd still
have possible races. I guess the best solution would be to move that
functionality into 'clockevents_update_freq()'?
Sören
next prev parent reply other threads:[~2013-12-06 22:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 1:04 [PATCH v2 0/9] arm: zynq: Add support for cpufreq Soren Brinkmann
2013-11-27 1:04 ` [PATCH v2 1/9] arm: dt: zynq: Remove 'clock-ranges' from TTC nodes Soren Brinkmann
2013-12-12 8:53 ` Michal Simek
2013-12-12 17:01 ` Sören Brinkmann
2013-12-12 19:07 ` Michal Simek
2013-11-27 1:04 ` [PATCH v2 2/9] arm: dt: zynq: Add 'cpus' node Soren Brinkmann
2013-11-27 1:04 ` [PATCH v2 3/9] clocksource/cadence_ttc: Store timer frequency in driver data Soren Brinkmann
2013-12-17 19:21 ` Sören Brinkmann
2013-12-18 14:53 ` Daniel Lezcano
2013-12-18 16:47 ` Sören Brinkmann
2013-12-18 21:58 ` Daniel Lezcano
2013-12-19 18:32 ` Sören Brinkmann
2013-12-19 20:53 ` Daniel Lezcano
2013-12-19 21:23 ` Sören Brinkmann
2013-12-19 21:39 ` Daniel Lezcano
2013-11-27 1:04 ` [PATCH v2 4/9] clocksource/cadence_ttc: Use enable/disable_irq Soren Brinkmann
2013-11-28 11:55 ` Daniel Lezcano
2013-11-28 14:18 ` Thomas Gleixner
2013-11-28 18:36 ` Sören Brinkmann
2013-11-28 19:07 ` Thomas Gleixner
2013-12-06 22:47 ` Sören Brinkmann [this message]
2013-12-07 10:56 ` Thomas Gleixner
2013-12-10 0:34 ` [PATCH 0/2] clockevents Soren Brinkmann
2013-12-10 0:34 ` [PATCH 1/2] time: Serialize calls to 'clockevents_update_freq' in the timing core Soren Brinkmann
2013-12-11 14:32 ` Daniel Lezcano
2013-12-11 20:09 ` Sören Brinkmann
2013-12-12 12:07 ` Daniel Lezcano
2013-12-10 0:34 ` [PATCH 2/2] time: clockevents: Adjust timer interval when frequency changes Soren Brinkmann
2013-11-27 1:04 ` [PATCH v2 5/9] clocksource/cadence_ttc: Adjust interval in clock notifier Soren Brinkmann
2013-12-12 12:15 ` Daniel Lezcano
2013-12-12 18:44 ` Sören Brinkmann
2013-11-27 1:04 ` [PATCH v2 6/9] clocksource/cadence_ttc: Overhaul clocksource frequency adjustment Soren Brinkmann
2013-11-27 1:04 ` [PATCH v2 7/9] clocksource/cadence_ttc: Use only one counter Soren Brinkmann
2013-11-27 1:04 ` [PATCH v2 8/9] arm: zynq: Don't use arm_global_timer with cpufreq Soren Brinkmann
2013-11-27 1:04 ` [PATCH v2 9/9] arm: zynq: Add support for cpufreq Soren 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=f6d25456-8e30-4792-b184-21eb02dfaa1c@AM1EHSMHS001.ehs.local \
--to=soren.brinkmann@xilinx.com \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=michal.simek@xilinx.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.org \
--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
all inboxes | Powered by JetHome®