With the helpe of platform msi and interrupt producer, then devices
will get the virq from mbi-gen's irqdomain.
Signed-off-by: Hanjun Guo <email address hidden>
Cc: Marc Zyngier <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Ma Jun <email address hidden>
[ CKT: Changes irq-mbigen, which is a driver specific to the platform
in question:
obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
]
Introduce mbigen_of_create_domain() to consolidate OF related
code and prepare for ACPI later.
Signed-off-by: Kefeng Wang <email address hidden>
Signed-off-by: Hanjun Guo <email address hidden>
Cc: Marc Zyngier <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Ma Jun <email address hidden>
[ CKT: Changes irq-mbigen, which is a driver specific to the platform
in question:
obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
]
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. In the
real world, we have irqchip such as mbi-gen which connecting to
a group of wired interrupts and then issue msi to the ITS, devices
connecting to such interrupt controller fit this scope.
For now the irq for ACPI only pointer to the main interrupt
controller's irqdomain, for devices not connecting to those
irqdomains, which need to present its irq parent, we can use
following ASL code to represent it:
then we can parse the interrupt producer with the full
path name "\_SB.IRQP".
In order to do that, we introduce a pointer interrupt_producer
in struct acpi_device, and fill it when scanning irq resources
for acpi device if it specifies the interrupt producer.
But for now when parsing the resources for acpi devices, we don't
pass the acpi device for acpi_walk_resoures() in drivers/acpi/resource.c,
so introduce a adev in struct res_proc_context to pass it as a context
to scan the interrupt resources, then finally pass to acpi_register_gsi()
to find its interrupt producer to get the virq from diffrent domains.
With steps above ready, rework acpi_register_gsi() to get other
interrupt producer if devices not connecting to main interrupt
controller.
Since we often pass NULL to acpi_register_gsi() and there is no interrupt
producer for devices connect to gicd on ARM or io-apic on X86, so it will
use the default irqdomain for those deivces and no functional changes to
those devices.
Signed-off-by: Hanjun Guo <email address hidden>
Cc: Rafael J. Wysocki <email address hidden>
Cc: Marc Zyngier <email address hidden>
Cc: Agustin Vega-Frias <email address hidden>
Cc: Lorenzo Pieralisi <email address hidden>
[ CKT: Touches generic code. The code path for existing systems looks
functionally the same, just reorganized. The new code should only run on
systems that support this HW. But, I'd suggest someone w/ more ACPI
experience than me take a look. ]
msi: platform: make platform_msi_create_device_domain() ACPI aware
With the platform msi domain created for ITS, irqchip such as
mbi-gen connecting ITS, which needs ctreate its own irqdomain.
Fortunately with the platform msi support upstreamed by Marc,
we just need to add minor code to make it run properly.
platform_msi_create_device_domain() is almost ready for ACPI use
except of_node_to_fwnode() is for dt only, make it ACPI aware then
things will work in both DTS and ACPI.
Signed-off-by: Hanjun Guo <email address hidden>
Cc: Marc Zyngier <email address hidden>
Cc: Greg KH <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Greg KH <email address hidden>
[ CKT: This touches generic platform-msi code. However, it is a one-line
change that seems obviously correct to me. By looking at of_node_to_fwnode(),
you can see that it is just returning dev->fwnode. ]
ACPI: platform: setup MSI domain for ACPI based platform device
With the platform msi domain created, we can set up the msi domain
for a platform device when it's probed.
In order to do that, we need to get the domain that the platform
device connecting to, so the iort_get_platform_device_domain() is
introduced to retrieve the domain from iort.
After the domain is retrieved, we need a proper way to set the
domain to paltform device, as some platform devices such as an
irqchip needs the msi irqdomain to be the interrupt parent domain,
we need to get irqdomain before platform device is probed but after
the platform device is allocated, so introduce a callback (pre_add_cb)
in pdevinfo to prepare firmware related information which is needed
for device probe, then set the msi domain in that callback.
Signed-off-by: Hanjun Guo <email address hidden>
Cc: Marc Zyngier <email address hidden>
Cc: Rafael J. Wysocki <email address hidden>
Cc: Greg KH <email address hidden>
Cc: Lorenzo Pieralisi <email address hidden>
Cc: Thomas Gleixner <email address hidden>
[ CKT: This touches the generic acpi-platform code, but it is a no-op
on !arm64. acpi_configure_pmsi_domain() is only implemented when
CONFIG_ACPI_IORT is enabled, and that is an arm64-only Kconfig setting ]
irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
With the introduction of its_pmsi_init_one(), we can add some code
on top for ACPI support of platform MSI.
We are scanning the MADT table to get the ITS entry(ies), then use
the information to create the platform msi domain for devices connect
to it, just like the PCI MSI for ITS did.
Signed-off-by: Hanjun Guo <email address hidden>
Tested-by: Sinan Kaya <email address hidden>
Cc: Marc Zyngier <email address hidden>
Cc: Tomasz Nowicki <email address hidden>
Cc: Thomas Gleixner <email address hidden>
[ CKT: arm64-only (GICv3 requires ARMv8-A compliance) ]
For devices connecting to ITS, it needs dev id to identify
itself, and this dev id is represented in the IORT table in
named componant node [1] for platform devices, so in this
patch we will scan the IORT to retrieve device's dev id.
Introduce iort_pmsi_get_dev_id() with pointer dev passed
in for that purpose.
