[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20160612111240.7dc99322@arm.com>
Date: Sun, 12 Jun 2016 11:12:40 +0100
From: Marc Zyngier <marc.zyngier@....com>
To: Ben Dooks <bjdooks@...glemail.com>
Cc: David Daney <ddaney.cavm@...il.com>,
Mark Rutland <mark.rutland@....com>,
Andrew Lunn <andrew@...n.ch>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Hou Zhiqiang <B48286@...escale.com>,
Liu Gang <Gang.Liu@....com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Mingkai Hu <Mingkai.Hu@...escale.com>,
Florian Fainelli <f.fainelli@...il.com>,
Kevin Hilman <khilman@...libre.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Michal Simek <michal.simek@...inx.com>,
linux-samsung-soc@...r.kernel.org, Kukjin Kim <kgene@...nel.org>,
bcm-kernel-feedback-list@...adcom.com,
Sören Brinkmann <soren.brinkmann@...inx.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Jason Cooper <jason@...edaemon.net>,
Ray Jui <rjui@...adcom.com>,
Tirumalesh Chalamarla <tchalamarla@...ium.com>,
Rob Herring <robh+dt@...nel.org>, Yuan Yao <yao.yuan@....com>,
Wenbin Song <Wenbin.Song@...escale.com>,
Jan Glauber <jglauber@...ium.com>,
Gregory Clement <gregory.clement@...e-electrons.com>,
linux-amlogic@...ts.infradead.org,
Thomas Gleixner <tglx@...utronix.de>,
linux-arm-kernel@...ts.infradead.org,
Rajesh Bhagat <rajesh.bhagat@...escale.com>,
Scott Branden <sbranden@...adcom.com>,
Duc Dang <dhdang@....com>, linux-kernel@...r.kernel.org,
Carlo Caione <carlo@...one.org>,
Dinh Nguyen <dinguyen@...nsource.altera.com>
Subject: Re: [PATCH v3 1/2] clocksource/arm_arch_timer: Force per-CPU
interrupt to be level-triggered
On Sat, 11 Jun 2016 13:02:44 +0100
Ben Dooks <bjdooks@...glemail.com> wrote:
> out of interest, do you have a list of what the problems are?
The trigger configuration for per-cpu interrupts silently fails
(because set_irq_type cannot deal with them). Which means we're relying
on whatever configuration the firmware has left in there. Also, the
kernel defaults to considering the interrupt as edge.
What saves most platforms so far is that they are using a GIC:
1) Most GIC implementations have their PPI configuration as RO, which
means that we can't get it wrong.
2) If using a fasteoi handler, there is no significant difference in the
flow between edge and level (we're relying on the HW dealing with it,
so (1) is critical).
If your GIC allows PPI configuration to be written and firmware gets it
wrong, you'll miss interrupts. If you don't have a GIC, all bets are
off.
I've queued a number of patches to solve this, which I hope to send to
tglx tomorrow (after looking at this weekend test run).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
Powered by blists - more mailing lists