[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160611104100.7475689e@arm.com>
Date: Sat, 11 Jun 2016 10:41:00 +0100
From: Marc Zyngier <marc.zyngier@....com>
To: David Daney <ddaney.cavm@...il.com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Andrew Lunn <andrew@...n.ch>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Liu Gang <Gang.Liu@....com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Florian Fainelli <f.fainelli@...il.com>,
Kevin Hilman <khilman@...libre.com>,
Hou Zhiqiang <B48286@...escale.com>,
Michal Simek <michal.simek@...inx.com>,
Kukjin Kim <kgene@...nel.org>,
bcm-kernel-feedback-list@...adcom.com,
linux-arm-kernel@...ts.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Jason Cooper <jason@...edaemon.net>,
Ray Jui <rjui@...adcom.com>,
Tirumalesh Chalamarla <tchalamarla@...ium.com>,
linux-samsung-soc@...r.kernel.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,
Mingkai Hu <Mingkai.Hu@...escale.com>,
Sören Brinkmann <soren.brinkmann@...inx.com>,
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 Fri, 10 Jun 2016 10:39:22 -0700
David Daney <ddaney.cavm@...il.com> wrote:
> On 06/10/2016 12:29 AM, Marc Zyngier wrote:
> > On Thu, 09 Jun 2016 14:10:48 -0700
> > David Daney <ddaney.cavm@...il.com> wrote:
> >
> >> On 06/06/2016 10:56 AM, Marc Zyngier wrote:
> >>> The ARM architected timer produces level-triggered interrupts (this
> >>> is mandated by the architecture). Unfortunately, most device-trees
> >>> get this wrong, and expose an edge-triggered interrupt.
> >>>
> >>> Until now, this wasn't too much an issue, as the programming of the
> >>> trigger would fail (the corresponding PPI cannot be reconfigured),
> >>> and the kernel would be happy with this. But we're about to change
> >>> this, and trust DT a lot if the driver doesn't provide its own
> >>> trigger information. In that context, the timer breaks badly.
> >>>
> >>> While we do need to fix the DTs, there is also some userspace out
> >>> there (kvmtool) that generates the same kind of broken DT on the
> >>> fly, and that will completely break with newer kernels.
> >>>
> >>> As a safety measure, and to keep buggy software alive as well as
> >>> buying us some time to fix DTs all over the place, let's check
> >>> what trigger configuration has been given us by the firmware.
> >>> If this is not a level configuration, then we know that the
> >>> DT/ACPI configuration is bust, and we pick some defaults which
> >>> won't be worse than the existing setup.
> >>>
> >>> Signed-off-by: Marc Zyngier <marc.zyngier@....com>
> >>
> >>
> >> I tried to test this patch, but there is a problem somewhere that I have
> >> not yet tracked down. On Cavium Thunder (gic-v3 based) I have tested
> >> with the device tree interrupt type of both 4 and 8 and get the same result:
> >>
> >>
> >> [ 0.000000] arm_arch_timer: WARNING: Invalid trigger for IRQ2,
> >> assuming level low
> >> [ 0.000000] arm_arch_timer: WARNING: Please fix your firmware
> >> [ 0.000000] arm_arch_timer: WARNING: Invalid trigger for IRQ3,
> >> assuming level low
> >> [ 0.000000] arm_arch_timer: WARNING: Please fix your firmware
> >> [ 0.000000] arm_arch_timer: Architected cp15 timer(s) running at
> >> 100.00MHz (phys).
> >> [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> >> max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
> >> [ 0.000002] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps
> >> every 4398046511100ns
> >>
> >> It could be that the gic-v3 irq mapping code is broken. I will try to
> >> look into it, but there may be other fixes needed before we would
> >> consider this patch to be an improvement.
> >
> > That's because the core kernel has other bugs which are going to be
> > addressed in 4.8. So far, we cannot set the trigger of a per-cpu
> > interrupt from the device tree, and we end-up with whatever is the
> > default (edge). You can put whatever you want in the DT, it will be
> > ignored.
>
> Yes, after looking into it, I see what you mean.
>
> >
> > This series in preparation of these fixes landing in 4.8, where we'll
> > be able to do the right thing, and will start noticing stupid things
> > coming from the DT.
> >
>
> I don't object to the patch, but would suggest a couple of things:
>
> o We need to test it *after* the irq configuration issues are corrected.
>
> o The merging order be such that we never get the WARNING messages.
What do you prefer? A benign warning message? or a broken system? You
sound more afraid of the former than the later (and yes, things *are*
broken at the moment).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
Powered by blists - more mailing lists