From: guohanjun@huawei.com (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 00/11] ACPI platform MSI, interrupt producer/consumer and its example mbi-gen
Date: Wed, 14 Sep 2016 22:21:08 +0800 [thread overview]
Message-ID: <1473862879-7769-1-git-send-email-guohanjun@huawei.com> (raw)
From: Hanjun Guo <hanjun.guo@linaro.org>
With platform msi support landed in the kernel, and the introduction
of IORT for GICv3 ITS (PCI MSI) [1], the framework for platform msi
is ready, this patch set add few patches to enable the ACPI platform
msi support.
For platform device connecting to ITS on arm platform, we have IORT
table with the named componant node to describe the mappings of paltform
device and ITS, so we can retrieve the dev id and find its parent
irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
With acpi platform msi supported, we add the ACPI support for irqchip
mbi-gen, which use this framework to form its stacked irqdomain, below
is the mbi-gen's topology in the system:
| ---------------| |------------------|
| | MSI | | wired interrupt(s)
| ITS |<-----------------| MBI-GEN |<----------------------------- IO device(s)
| | | |<----------------------------- IO device(s)
------------------ -------------------
So with ACPI platform MSI support, we can build the stacked domain for
mbi-gen which represented its mappings with the named componant in IORT,
but we still missing the connectings of devices to mbi-gen as in ACPI
world devices connect to main interrupt controller in MADT in default.
In ACPI 6.1, section 19.6.62, Interrupt Resource Descriptor Macro,
Interrupt (ResourceUsage, EdgeLevel, ActiveLevel, Shared,
ResourceSourceIndex, ResourceSource, DescriptorName)
{ InterruptList } => Buffer
For the arguement ResourceUsage and DescriptorName, which means:
ResourceUsage describes whether the device consumes the specified
interrupt ( ResourceConsumer ) or produces it for use by a child
device ( ResourceProducer ).
If nothing is specified, then ResourceConsumer is assumed.
DescriptorName evaluates to a name string which refers to the
entire resource descriptor.
So it can be used for devices connecting to a specific interrupt
prodcucer instead of the main interrupt controller in MADT, we can
define:
Interrupt(ResourceConsumer,..., "\_SB.IRQP") {12,14,....},
then get the interrupt producer with the full path name "\_SB.IRQP".
v2:
- Fix the bug of if multi Interrupt() resoures in single _PRS,
we need to calculate all the irq numbers (I missed it in previous
version);
- Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5
SMMu patches (also Robin's SMMu patches)
- Add patch irqchip: mbigen: promote mbigen init.
This is the RFC version 2 and we still needs to address:
- we need to deal with the device topology as:
NC (named componant) -> SMMU -> ITS.
Comments are warmly welcomed!
Thanks
Hanjun
Hanjun Guo (9):
irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
ACPI: platform-msi: retrieve dev id from IORT
irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
for ACPI
irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
domain
ACPI: platform: setup MSI domain for ACPI based platform device
msi: platform: make platform_msi_create_device_domain() ACPI aware
ACPI: irq: introduce interrupt producer
irqchip: mbigen: Add ACPI support
irqchip: mbigen: promote mbigen init
Kefeng Wang (2):
irqchip: mbigen: drop module owner
irqchip: mbigen: introduce mbigen_of_create_domain()
drivers/acpi/arm64/iort.c | 31 ++++++-
drivers/acpi/gsi.c | 10 ++-
drivers/acpi/resource.c | 85 +++++++++++++------
drivers/base/platform-msi.c | 20 ++++-
drivers/base/platform.c | 2 +
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 107 ++++++++++++++++++------
drivers/irqchip/irq-mbigen.c | 115 ++++++++++++++++++++++----
include/acpi/acpi_bus.h | 1 +
include/linux/acpi_iort.h | 8 ++
include/linux/msi.h | 1 +
10 files changed, 305 insertions(+), 75 deletions(-)
--
1.7.12.4
next reply other threads:[~2016-09-14 14:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 14:21 Hanjun Guo [this message]
2016-09-14 14:21 ` [RFC PATCH v2 01/11] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare() Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 02/11] ACPI: platform-msi: retrieve dev id from IORT Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 03/11] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 04/11] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 05/11] ACPI: platform: setup MSI domain for ACPI based platform device Hanjun Guo
2016-09-14 15:45 ` Marc Zyngier
2016-09-15 14:05 ` Hanjun Guo
2016-09-15 15:18 ` Marc Zyngier
2016-09-19 9:42 ` Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 06/11] msi: platform: make platform_msi_create_device_domain() ACPI aware Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 07/11] ACPI: irq: introduce interrupt producer Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 08/11] irqchip: mbigen: drop module owner Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 09/11] irqchip: mbigen: introduce mbigen_of_create_domain() Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 10/11] irqchip: mbigen: Add ACPI support Hanjun Guo
2016-09-15 8:49 ` Marc Zyngier
2016-09-19 9:28 ` Hanjun Guo
2016-09-14 14:21 ` [RFC PATCH v2 11/11] irqchip: mbigen: promote mbigen init Hanjun Guo
2016-09-15 15:24 ` Marc Zyngier
2016-09-19 9:49 ` Hanjun Guo
2016-09-19 10:12 ` Marc Zyngier
2016-09-20 2:43 ` Hanjun Guo
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=1473862879-7769-1-git-send-email-guohanjun@huawei.com \
--to=guohanjun@huawei.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).