Let ACPI build ITS PCI MSI domain. ACPI code is responsible for retrieving
inner domain token and passing it on to its_pci_msi_init_one generic
init call.
IORT maintains list of registered domain tokens and allows to find
corresponding domain based on MADT ITS subtable ID info.
Signed-off-by: Tomasz Nowicki <email address hidden>
Acked-by: Marc Zyngier <email address hidden>
Reviewed-by: Hanjun Guo <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit 723344dd0b2aa10ef9d28fe7f35d594d3e64f0f9)
Signed-off-by: dann frazier <email address hidden>
b5f42f5...
by
Tomasz Nowicki <email address hidden>
UBUNTU: SAUCE: irqchip/gicv3-its: Factor out PCI-MSI part that might be reused for ACPI
Firmware agnostic code lands in common functions which do necessary
domain initialization based on unique domain handler. DT specific
code goes to DT specific init call.
Signed-off-by: Tomasz Nowicki <email address hidden>
Acked-by: Marc Zyngier <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit db744aaa279fa1d2a06dd6b95f9599acf3557885)
Signed-off-by: dann frazier <email address hidden>
587056a...
by
Tomasz Nowicki <email address hidden>
UBUNTU: SAUCE: irqchip/gicv3-its: Probe ITS in the ACPI way
ITS is prepared for being initialized different than DT,
therefore we can initialize it in ACPI way. We collect register base
address from MADT table and pass mandatory info to firmware-agnostic
ITS init call.
Use here IORT lib to register ITS domain which then can be found and
used on to build another PCI MSI domain in hierarchical stack domain.
NOTE: Waiting for proper ITS and NUMA node relation description in IORT
table, we pass around NUMA_NO_NODE to the its_probe_one init call.
This means that Cavium ThunderX erratum 23144 (pass1.1 only)
is not supported for ACPI boot method yet.
Signed-off-by: Tomasz Nowicki <email address hidden>
Acked-by: Marc Zyngier <email address hidden>
Reviewed-by: Hanjun Guo <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit 3f010cf197324b6c1e87f472e64b87c5f909735e)
Signed-off-by: dann frazier <email address hidden>
c212217...
by
Tomasz Nowicki <email address hidden>
UBUNTU: SAUCE: irqchip/gicv3-its: Refactor ITS DT init code to prepare for ACPI
In order to add ACPI support we need to isolate ACPI&DT common code and
move DT logic to corresponding functions. To achieve this we are using
firmware agnostic handle which can be unpacked to either DT or ACPI node.
No functional changes other than a very minor one:
1. Terminate its_init call with -ENODEV for non-DT case which allows
to remove hack from its-gic-v3.c.
2. Fix ITS base register address type (from 'unsigned long' to 'phys_addr_t'),
as a bonus we get nice string formatting.
3. Since there is only one of ITS parent domain convert it to static global
variable and drop the parameter from its_probe_one. Users can refer to it
in more convenient way then.
Signed-off-by: Hanjun Guo <email address hidden>
Signed-off-by: Tomasz Nowicki <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit db40f0a7aea5e03ef044ef5dbc51a364e1ff7991)
Signed-off-by: dann frazier <email address hidden>
2b1655f...
by
Tomasz Nowicki <email address hidden>
UBUNTU: SAUCE: irqchip/gicv3-its: Cleanup for ITS domain initialization
There is no point to initialize ITS without having msi-controller
property in corresponding DT node. However, its_probe is checking
msi-controller presence at the end, so we can save our time and do that
check prior to its_probe call. Also, for the code clarity purpose,
we put domain initialization to separate function.
Signed-off-by: Tomasz Nowicki <email address hidden>
Acked-by: Marc Zyngier <email address hidden>
Reviewed-by: Hanjun Guo <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit d14ae5e6bac36e88cd5deeee411104da424bc73d)
Signed-off-by: dann frazier <email address hidden>
da5dddb...
by
Tomasz Nowicki <email address hidden>
UBUNTU: SAUCE: PCI/MSI: Setup MSI domain on a per-device basis using IORT ACPI table
It is possible to provide information about which MSI controller to
use on a per-device basis for DT. This patch supply this with ACPI support.
Currently, IORT is the only one ACPI table which can provide such mapping.
In order to plug IORT into MSI infrastructure we are adding ACPI
equivalents for finding PCI device domain and its RID translation
(pci_msi_domain_get_msi_rid and pci_msi_domain_get_msi_rid calls).
Signed-off-by: Tomasz Nowicki <email address hidden>
Reviewed-by: Hanjun Guo <email address hidden>
Acked-by: Marc Zyngier <email address hidden>
Acked-by: Bjorn Helgaas <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit be2021baeed64d8947a56529fc383308918ecc41)
Signed-off-by: dann frazier <email address hidden>
c5d9f8b...
by
Tomasz Nowicki <email address hidden>
UBUNTU: SAUCE: ACPI: Add new IORT functions to support MSI domain handling
For ITS, MSI functionality consists on building domain stack and
during that process we need to reference to domain stack components
e.g. before we create new DOMAIN_BUS_PCI_MSI domain we need to specify
its DOMAIN_BUS_NEXUS parent domain. In order to manage that process
properly, maintain list which elements contain domain token
(unique for MSI domain stack) and ITS ID: iort_register_domain_token()
and iort_deregister_domain_token(). Then retrieve domain token
any time later with ITS ID being key off: iort_find_domain_token().
With domain token and domain type we are able to find corresponding
IRQ domain.
Since IORT is prepared to describe MSI domain on a per-device basis,
use existing IORT helpers and implement two calls:
1. iort_msi_map_rid() to map MSI RID for a device
2. iort_get_device_domain() to find domain token for a device
Signed-off-by: Tomasz Nowicki <email address hidden>
Acked-by: Rafael J. Wysocki <email address hidden>
Reviewed-by: Hanjun Guo <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit 4bf2efd26d7624372fb7adff8745b4c2e8407004)
Signed-off-by: dann frazier <email address hidden>
314c744...
by
Tomasz Nowicki <email address hidden>
UBUNTU: SAUCE: ACPI: I/O Remapping Table (IORT) initial support
Initial support allows to detect IORT table presence and save its
root pointer obtained through acpi_get_table(). The pointer validity
depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
is not set while using IORT nodes we would dereference unmapped pointers.
For the aforementioned reason call acpi_iort_init() from acpi_init()
which guarantees acpi_gbl_permanent_mmap to be set at that point.
Add generic helpers which are helpful for scanning and retrieving
information from IORT table content. List of the most important helpers:
- iort_find_dev_node() finds IORT node for a given device
- iort_node_map_rid() maps device RID and returns IORT node which provides
final translation
IORT support is placed under drivers/acpi/arm64/ new directory due to its
ARM64 specific nature. The code there is considered only for ARM64.
The long term plan is to keep all ARM64 specific tables support
in this place e.g. GTDT table.
Signed-off-by: Tomasz Nowicki <email address hidden>
Acked-by: Rafael J. Wysocki <email address hidden>
Reviewed-by: Hanjun Guo <email address hidden>
Reviewed-by: Lorenzo Pieralisi <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from linux-next commit 88ef16d888a094587b2ac77de60927df5da5d56d)
Signed-off-by: dann frazier <email address hidden>
