From: jonathanh@nvidia.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] irqchip: gic: Add a cpu map for each GIC instance
Date: Wed, 29 Jul 2015 20:27:53 +0100 [thread overview]
Message-ID: <55B92939.5040101@nvidia.com> (raw)
In-Reply-To: <20150729183321.GP7557@n2100.arm.linux.org.uk>
On 29/07/15 19:33, Russell King - ARM Linux wrote:
> On Wed, Jul 29, 2015 at 03:43:04PM +0100, Jon Hunter wrote:
>> The gic_init_bases() function initialises an array that stores the mapping
>> between the GIC and CPUs. This array is a global array that is
>> unconditionally initialised on every call to gic_init_bases(). Although,
>> it is not common for there to be more than one GIC instance, there are
>> some devices that do support nested GIC controllers and gic_init_bases()
>> can be called more than once.
>>
>> A 2nd call to gic_init_bases() will clear the previous CPU mapping and
>> will only setup the mapping again for CPU0. This is because for child GIC
>> controllers there is most likely only one recipient of the interrupt.
>>
>> Fix this by moving the CPU mapping array to the GIC chip data structure
>> so that it is initialised for each GIC instance separately. It is assumed
>> that the bL switcher code is only interested in the root or primary GIC
>> instance.
>
> Does it make sense to expose the per-CPU-ness of the non-primary GIC?
> If they are chained off a primary GIC SPI interrupt, then all IRQs on
> the secondary GIC are routed to the same CPU that the SPI on the primary
> GIC is routed to.
I am looking at a use-case where there is a secondary GIC and the secondary
GIC is used as a interrupt router between the main CPU cluster and another
CPU. So in this case the mapping of a secondary is still of interest. This
patch does not address setting up the secondary mapping, but avoids a
secondary GIC overwriting the primary map (which we don't want).
> Other features like the PPIs and SGIs in the secondary CPU should also
> be ignored - they probably aren't used anyway.
Yes, agree.
> I have to say though... are the 1020 IRQs that the primary GIC provides
> really not enough? What insane hardware needs more than 1020 IRQs?
Ha. I guess some realview boards for a start ...
# grep -r "gic_init(1" arch/arm/
arch/arm/mach-realview/realview_pb1176.c: gic_init(1, IRQ_PB1176_GIC_START,
arch/arm/mach-realview/realview_eb.c: gic_init(1, 96, __io_address(REALVIEW_EB_GIC_DIST_BASE),
arch/arm/mach-realview/realview_pb11mp.c: gic_init(1, IRQ_PB11MP_GIC_START,
Jon
next prev parent reply other threads:[~2015-07-29 19:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 14:43 [PATCH] irqchip: gic: Add a cpu map for each GIC instance Jon Hunter
2015-07-29 15:39 ` Nicolas Pitre
2015-07-29 16:10 ` Thomas Gleixner
2015-07-30 7:19 ` Marc Zyngier
2015-07-30 8:08 ` Jon Hunter
2015-07-30 9:02 ` Marc Zyngier
2015-07-29 18:33 ` Russell King - ARM Linux
2015-07-29 19:27 ` Jon Hunter [this message]
2015-07-30 8:20 ` Marc Zyngier
2015-07-30 8:33 ` Jon Hunter
2015-07-30 9:04 ` Marc Zyngier
2015-07-30 9:30 ` Jon Hunter
2015-07-30 9:38 ` Marc Zyngier
2015-07-30 12:14 ` Stefan Agner
2015-07-30 12:19 ` Nicolas Pitre
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=55B92939.5040101@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).