From: Paul Burton <paul.burton@imgtec.com>
To: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
James Hogan <james.hogan@imgtec.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] irqchip/mips-gic: Fix Local compare interrupt
Date: Tue, 11 Apr 2017 10:56:42 -0700 [thread overview]
Message-ID: <1787874.Cz8gmWEnDJ@np-p-burton> (raw)
Message-ID: <20170411175642.dDCqF4R5vgdvUXF5ISedkrbXYJilZoWyhcPB8Scp7a8@z> (raw)
In-Reply-To: <a71e58d4-b223-7bc7-803a-937e3b6837bb@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 3007 bytes --]
Hi Matt,
On Tuesday, 11 April 2017 01:20:35 PDT Matt Redfearn wrote:
> On 10/04/17 23:06, Paul Burton wrote:
> > On Friday, 31 March 2017 04:05:32 PDT Matt Redfearn wrote:
> >> Commit 4cfffcfa5106 ("irqchip/mips-gic: Fix local interrupts") added
> >> mapping of several local interrupts during initialisation of the gic
> >> driver. This associates virq numbers with these interrupts.
> >> Unfortunately, as not all of the interrupts are mapped in hardware
> >> order, when drivers subsequently request these interrupts they conflict
> >> with the mappings that have already been set up. For example, this
> >> manifests itself in the gic clocksource driver, which fails to probe
> >> with the message:
> >>
> >> clocksource: GIC: mask: 0xffffffffffffffff max_cycles: 0x7350c9738,
> >> max_idle_ns: 440795203769 ns
> >> GIC timer IRQ 25 setup failed: -22
> >>
> >> This is because virq 25 (the correct IRQ number specified via device
> >> tree) was allocated to the PERFCTR interrupt (and 24 to the timer, 26 to
> >> the FDC).
> >
> > I'm confused by this - the DT doesn't specify VIRQs, it specifies hardware
> > IRQ numbers. Which VIRQ is used should be irrelevant. Is this on a system
> > using gic_clocksource_init() from platform code? (Malta?) and therefore
> > relying on MIPS_GIC_IRQ_BASE?
>
> Yes, this is on Malta, which as you say, uses MIPS_GIC_IRQ_BASE. On
> Malta that ends up, through the definition of I8259A_IRQ_BASE and
> MIPS_CPU_IRQ_BASE, to be 24. Therefore hardware interrupt 1 of the GIC
> ends up expecting to be allocated at virq 25. But since 4cfffcfa5106,
> that virq number was allocated to the PERFCTR interrupt. Everything
> about the order-dependent and hardcoded bases of Maltas IRQs seems bad
> and needs looking at but this was the easiest fix for this cycle.
>
> > If so I think this would be much more cleanly fixed by moving to probe the
> > clocksource using DT
>
> Not sure that would help if Maltas expected virq for this source had
> already been allocated?
Well the problem is that Malta expects a particular VIRQ - if it instead
probed the clock event driver via DT, which specifies a hardware interrupt
number, then that problem goes away & it doesn't matter which VIRQ is used.
For example the generic platform (including the Malta board support for it in
the downstream engineering kernels) ought to work fine without this because
there isn't an expectation for a particular VIRQ. Hopefully I'll have time to
submit some more of that code for the v4.13 cycle & we can eventually scrap
all of these hardcoded VIRQs along with the mti-malta board code that commits
the sins.
An alternative might be to have the Malta board code use irq_create_mapping()
to map the hardware IRQ to a VIRQ rather than hardcoding the VIRQ, which would
be an improvement but would then require that the board code have access to
the GIC's struct irq_domain. Given that we want to move Malta towards DT
anyway that doesn't seem worth much effort.
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-04-11 17:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 11:05 [PATCH 0/2] Fix v4.11 malta_defconfig regressions Matt Redfearn
2017-03-31 11:05 ` Matt Redfearn
2017-03-31 11:05 ` [PATCH 1/2] MIPS: Malta: Fix i8259 irqchip setup Matt Redfearn
2017-03-31 11:05 ` Matt Redfearn
2017-03-31 12:49 ` Ralf Baechle
2017-03-31 12:53 ` Matt Redfearn
2017-03-31 12:53 ` Matt Redfearn
2017-03-31 11:05 ` [PATCH 2/2] irqchip/mips-gic: Fix Local compare interrupt Matt Redfearn
2017-03-31 11:05 ` Matt Redfearn
2017-03-31 12:46 ` Ralf Baechle
2017-04-10 22:06 ` Paul Burton
2017-04-10 22:06 ` Paul Burton
2017-04-11 8:20 ` Matt Redfearn
2017-04-11 8:20 ` Matt Redfearn
2017-04-11 17:56 ` Paul Burton [this message]
2017-04-11 17:56 ` Paul Burton
2017-03-31 12:04 ` [PATCH 0/2] Fix v4.11 malta_defconfig regressions Marc Zyngier
2017-03-31 12:55 ` Matt Redfearn
2017-03-31 12:55 ` Matt Redfearn
2017-03-31 13:28 ` Marc Zyngier
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=1787874.Cz8gmWEnDJ@np-p-burton \
--to=paul.burton@imgtec.com \
--cc=james.hogan@imgtec.com \
--cc=jason@lakedaemon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=marc.zyngier@arm.com \
--cc=matt.redfearn@imgtec.com \
--cc=ralf@linux-mips.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;
as well as URLs for NNTP newsgroup(s).