From: Hanjun Guo <[email protected]>
With platform msi support landed in the kernel, and the introduction
of IORT for GICv3 ITS (PCI MSI) and SMMU, 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).
v8 -> v9:
- Rebased on top of 4.11-rc1 and retest;
- Some of patch's commit message was updated by Lorenzo and
it's clearer (thanks!)
No update in the code, hope it's the final revision.
v7 -> v8:
- Using _CRS instead of _PRS for Interrupt resources for mbigen
- reshuffle the patch slightly to introduce iort_node_map_platform_id()
first and then retrieve the dev id for platform MSI, no functional
change
- Fix the compile error with patch "irqchip: gicv3-its: platform-msi:
scan MADT to create platform msi domain", which forgot to add
<include/acpi_iort.h> (added in later patches in last version).
- renew some commit message which suggested by Lorenzo
- address some othe minor issues which commented by Lorenzo
- Add review and test tag as it's no functional change except
the last patch of mbigen
- rebase on top of 4.10-rc4 and test it on x86, ia64 and ARM64
platforms (also with Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
Add IRQ combiner driver" and Lorenzo's patch
https://patchwork.kernel.org/patch/9507041/)
v6 -> v7:
- Introduce iort_node_map_platform_id() to retrieve the
dev id for both NC (named component) -> ITS/SMMU and
NC -> SMMU -> ITS cases, suggested by Lorenzo;
- Reorder the patches and rewrite some commit message;
- Remove the test tags because it has major changes
to retrieve the dev id, Sinan, Majun, Xinwei, could
you please test them again on your platform?
- rebased on top of 4.10-rc3 and Lorenzo's patch
https://patchwork.kernel.org/patch/9507041/
- Tested against Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
Add IRQ combiner driver"
v5 -> v6:
- Call acpi_configure_pmsi_domain() for platform devices in
acpi_platform_notify() as it's cleaner (suggested by Rafael)
- Remove the "u8 type" for iort_id_map() because it's unused
- Rebase on top of 4.10-rc2
- Collect test and review tags
v4 -> v5:
- Add mbigen support back with tested on with Agustin's patchset,
and it's a good example of how ACPI platform MSI works
- rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling)
v3 -> v4:
- Drop mbi-gen patches to just submit platform msi support because
will rebase mbi-gen patches on top of Agustin's patchset, and discusion
is going there.
- Add a patch to support device topology such as NC(named componant, paltform device)
->SMMU->ITS which suggested by Lorenzo;
- rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
- rebased on top of 4.9-rc7
v2 -> v3:
- Drop RFC tag
- Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU support [1]
- Add 3 cleanup patches (patch 1, 2, 3)
- Drop arch_init call patch from last version
- Introduce a callback for platform device to set msi domain
- Introduce a new API to get paltform device's domain instead of
reusing the PCI one in previous version
- Add a patch to rework iort_node_get_id()
[1]: http://www.mail-archive.com/[email protected]/msg1251993.html
v1 -> 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.
Hanjun Guo (13):
ACPI/IORT: Fix the indentation in iort_scan_node()
ACPI/IORT: Add missing comment for iort_dev_find_its_id()
ACPI/IORT: Rework iort_match_node_callback() return value handling
irqchip: gic-v3-its: keep the include header files in alphabetic
order
irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
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/IORT: Rename iort_node_map_rid() to make it generic
ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
ACPI: platform-msi: retrieve dev id from IORT
ACPI: platform: setup MSI domain for ACPI based platform device
msi: platform: make platform_msi_create_device_domain() ACPI aware
irqchip: mbigen: Add ACPI support
Kefeng Wang (2):
irqchip: mbigen: drop module owner
irqchip: mbigen: introduce mbigen_of_create_domain()
drivers/acpi/arm64/iort.c | 158 +++++++++++++++++++++-----
drivers/acpi/glue.c | 6 +
drivers/base/platform-msi.c | 3 +-
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++++++++++++----
drivers/irqchip/irq-gic-v3-its.c | 2 +-
drivers/irqchip/irq-mbigen.c | 110 +++++++++++++++---
include/linux/acpi_iort.h | 8 ++
7 files changed, 317 insertions(+), 76 deletions(-)
--
1.7.12.4
From: Hanjun Guo <[email protected]>
Add missing req_id parameter to the iort_dev_find_its_id() function
kernel-doc comment.
Signed-off-by: Hanjun Guo <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
---
drivers/acpi/arm64/iort.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 2e368a6..abc5774 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -450,6 +450,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
/**
* iort_dev_find_its_id() - Find the ITS identifier for a device
* @dev: The device.
+ * @req_id: Device's requester ID
* @idx: Index of the ITS identifier list.
* @its_id: ITS identifier.
*
--
1.7.12.4
From: Hanjun Guo <[email protected]>
The return value handling in iort_match_node_callback() is
too convoluted; update the iort_match_node_callback() return
value handling to make code easier to read.
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
---
drivers/acpi/arm64/iort.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index abc5774..a6b807d 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -253,17 +253,15 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
void *context)
{
struct device *dev = context;
- acpi_status status;
+ acpi_status status = AE_NOT_FOUND;
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
struct acpi_iort_named_component *ncomp;
- if (!adev) {
- status = AE_NOT_FOUND;
+ if (!adev)
goto out;
- }
status = acpi_get_name(adev->handle, ACPI_FULL_PATHNAME, &buf);
if (ACPI_FAILURE(status)) {
@@ -289,8 +287,6 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
*/
status = pci_rc->pci_segment_number == pci_domain_nr(bus) ?
AE_OK : AE_NOT_FOUND;
- } else {
- status = AE_NOT_FOUND;
}
out:
return status;
--
1.7.12.4
From: Hanjun Guo <[email protected]>
Introduce its_pmsi_init_one() to separate firmware dependent
code (ie OF dependent code) and firmware agnostic code so
that gic3-its code can be made to support other firmware
bindings easily.
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 45 ++++++++++++++++-----------
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 3c94278..3d9efd1 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -82,34 +82,43 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
{},
};
-static int __init its_pmsi_init(void)
+static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
+ const char *name)
{
- struct device_node *np;
struct irq_domain *parent;
+ parent = irq_find_matching_fwnode(fwnode, DOMAIN_BUS_NEXUS);
+ if (!parent || !msi_get_domain_info(parent)) {
+ pr_err("%s: unable to locate ITS domain\n", name);
+ return -ENXIO;
+ }
+
+ if (!platform_msi_create_irq_domain(fwnode, &its_pmsi_domain_info,
+ parent)) {
+ pr_err("%s: unable to create platform domain\n", name);
+ return -ENXIO;
+ }
+
+ pr_info("Platform MSI: %s domain created\n", name);
+ return 0;
+}
+
+static void __init its_pmsi_of_init(void)
+{
+ struct device_node *np;
+
for (np = of_find_matching_node(NULL, its_device_id); np;
np = of_find_matching_node(np, its_device_id)) {
if (!of_property_read_bool(np, "msi-controller"))
continue;
- parent = irq_find_matching_host(np, DOMAIN_BUS_NEXUS);
- if (!parent || !msi_get_domain_info(parent)) {
- pr_err("%s: unable to locate ITS domain\n",
- np->full_name);
- continue;
- }
-
- if (!platform_msi_create_irq_domain(of_node_to_fwnode(np),
- &its_pmsi_domain_info,
- parent)) {
- pr_err("%s: unable to create platform domain\n",
- np->full_name);
- continue;
- }
-
- pr_info("Platform MSI: %s domain created\n", np->full_name);
+ its_pmsi_init_one(of_node_to_fwnode(np), np->full_name);
}
+}
+static int __init its_pmsi_init(void)
+{
+ its_pmsi_of_init();
return 0;
}
early_initcall(its_pmsi_init);
--
1.7.12.4
From: Hanjun Guo <[email protected]>
Rearrange header file includes in alphabetic order.
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: fixed commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 2320100..6fc287fb 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -16,13 +16,13 @@
*/
#include <linux/acpi.h>
+#include <linux/acpi_iort.h>
#include <linux/bitmap.h>
#include <linux/cpu.h>
#include <linux/delay.h>
#include <linux/dma-iommu.h>
#include <linux/interrupt.h>
#include <linux/irqdomain.h>
-#include <linux/acpi_iort.h>
#include <linux/log2.h>
#include <linux/mm.h>
#include <linux/msi.h>
--
1.7.12.4
From: Hanjun Guo <[email protected]>
By adding ACPI support for platform MSI, the gicv3 driver has to
provide code to retrieve the dev id through ACPI instead of device
tree bindings; given that its_pmsi_prepare() allows already to get
the dev id but it is OF dependent, factor OF related code out into
a single function to make its_pmsi_prepare() ready to be used with
other firmware interfaces.
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 470b4aa..3c94278 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -24,15 +24,11 @@
.name = "ITS-pMSI",
};
-static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
- int nvec, msi_alloc_info_t *info)
+static int of_pmsi_get_dev_id(struct irq_domain *domain, struct device *dev,
+ u32 *dev_id)
{
- struct msi_domain_info *msi_info;
- u32 dev_id;
int ret, index = 0;
- msi_info = msi_get_domain_info(domain->parent);
-
/* Suck the DeviceID out of the msi-parent property */
do {
struct of_phandle_args args;
@@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
if (args.np == irq_domain_get_of_node(domain)) {
if (WARN_ON(args.args_count != 1))
return -EINVAL;
- dev_id = args.args[0];
+ *dev_id = args.args[0];
break;
}
} while (!ret);
+ return ret;
+}
+
+static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
+ int nvec, msi_alloc_info_t *info)
+{
+ struct msi_domain_info *msi_info;
+ u32 dev_id;
+ int ret;
+
+ msi_info = msi_get_domain_info(domain->parent);
+
+ ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
if (ret)
return ret;
--
1.7.12.4
From: Kefeng Wang <[email protected]>
Introduce mbigen_of_create_domain() to consolidate OF related
code and prepare for ACPI later, no funtional change.
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Hanjun Guo <[email protected]>
Reviewed-by: Ma Jun <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/irqchip/irq-mbigen.c | 43 ++++++++++++++++++++++++++++---------------
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index c01ab41..3756408 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -236,27 +236,15 @@ static int mbigen_irq_domain_alloc(struct irq_domain *domain,
.free = irq_domain_free_irqs_common,
};
-static int mbigen_device_probe(struct platform_device *pdev)
+static int mbigen_of_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
{
- struct mbigen_device *mgn_chip;
+ struct device *parent;
struct platform_device *child;
struct irq_domain *domain;
struct device_node *np;
- struct device *parent;
- struct resource *res;
u32 num_pins;
- mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
- if (!mgn_chip)
- return -ENOMEM;
-
- mgn_chip->pdev = pdev;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(mgn_chip->base))
- return PTR_ERR(mgn_chip->base);
-
for_each_child_of_node(pdev->dev.of_node, np) {
if (!of_property_read_bool(np, "interrupt-controller"))
continue;
@@ -280,6 +268,31 @@ static int mbigen_device_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ return 0;
+}
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+ struct mbigen_device *mgn_chip;
+ struct resource *res;
+ int err;
+
+ mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
+ if (!mgn_chip)
+ return -ENOMEM;
+
+ mgn_chip->pdev = pdev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mgn_chip->base = devm_ioremap(&pdev->dev, res->start,
+ resource_size(res));
+ if (IS_ERR(mgn_chip->base))
+ return PTR_ERR(mgn_chip->base);
+
+ err = mbigen_of_create_domain(pdev, mgn_chip);
+ if (err)
+ return err;
+
platform_set_drvdata(pdev, mgn_chip);
return 0;
}
--
1.7.12.4
From: Hanjun Guo <[email protected]>
The irqdomain creation that is carried out in:
platform_msi_create_device_domain()
relies on the fwnode_handle interrupt controller token to associate the
interrupt controller with a specific irqdomain. Current code relies on
the OF layer to retrieve a fwnode_handle for the device representing the
interrupt controller from its device->of_node pointer. This makes
platform_msi_create_device_domain() DT specific whilst it really is not
because after the merge of commit f94277af03ea ("of/platform: Initialise
dev->fwnode appropriately") the fwnode_handle can easily be retrieved
from the dev->fwnode pointer in a firmware agnostic way.
Update platform_msi_create_device_domain() to retrieve the interrupt
controller fwnode_handle from the dev->fwnode pointer so that it can
be used seamlessly in ACPI and DT systems.
Signed-off-by: Hanjun Guo <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Greg KH <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/base/platform-msi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index 0fc7c4d..d35e9a2 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -345,8 +345,7 @@ struct irq_domain *
data->host_data = host_data;
domain = irq_domain_create_hierarchy(dev->msi_domain, 0, nvec,
- of_node_to_fwnode(dev->of_node),
- ops, data);
+ dev->fwnode, ops, data);
if (!domain)
goto free_priv;
--
1.7.12.4
From: Hanjun Guo <[email protected]>
The indentation in the iort_scan_node() function is wrong, fix it.
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: massaged commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
---
drivers/acpi/arm64/iort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 4a5bb96..2e368a6 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -225,7 +225,7 @@ static struct acpi_iort_node *iort_scan_node(enum acpi_iort_node_type type,
if (iort_node->type == type &&
ACPI_SUCCESS(callback(iort_node, context)))
- return iort_node;
+ return iort_node;
iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
iort_node->length);
--
1.7.12.4
From: Hanjun Guo <[email protected]>
With the preparation of platform msi support and interrupt producer
in DSDT, we can add mbigen ACPI support now.
We are using Interrupt resource type in _CRS methd to indicate number
of irq pins instead of num_pins in DT to avoid _DSD usage in this case.
For mbigen,
Device(MBI0) {
Name(_HID, "HISI0152")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
Interrupt(ResourceProducer,...) {12,14,....}
})
}
For devices,
Device(COM0) {
Name(_HID, "ACPIIDxx")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
})
}
With the help of platform msi and interrupt producer, then devices
will get the virq from mbigen's irqdomain.
Signed-off-by: Hanjun Guo <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Ma Jun <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 67 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 3756408..e6bb503 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -16,6 +16,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/interrupt.h>
#include <linux/irqchip.h>
#include <linux/module.h>
@@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
unsigned long *hwirq,
unsigned int *type)
{
- if (is_of_node(fwspec->fwnode)) {
+ if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
if (fwspec->param_count != 2)
return -EINVAL;
@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
return 0;
}
+#ifdef CONFIG_ACPI
+static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
+ void *context)
+{
+ struct acpi_resource_extended_irq *ext_irq;
+ u32 *num_irqs = context;
+
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ ext_irq = &ares->data.extended_irq;
+ *num_irqs += ext_irq->interrupt_count;
+ break;
+ default:
+ break;
+ }
+
+ return AE_OK;
+}
+
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
+{
+ struct irq_domain *domain;
+ u32 num_msis = 0;
+ acpi_status status;
+
+ status = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__CRS,
+ mbigen_acpi_process_resource, &num_msis);
+ if (ACPI_FAILURE(status) || num_msis == 0)
+ return -EINVAL;
+
+ domain = platform_msi_create_device_domain(&pdev->dev, num_msis,
+ mbigen_write_msg,
+ &mbigen_domain_ops,
+ mgn_chip);
+ if (!domain)
+ return -ENOMEM;
+
+ return 0;
+}
+#else
+static inline int mbigen_acpi_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
+{
+ return -ENODEV;
+}
+#endif
+
static int mbigen_device_probe(struct platform_device *pdev)
{
struct mbigen_device *mgn_chip;
@@ -289,9 +338,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
- err = mbigen_of_create_domain(pdev, mgn_chip);
- if (err)
+ if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+ err = mbigen_of_create_domain(pdev, mgn_chip);
+ else if (ACPI_COMPANION(&pdev->dev))
+ err = mbigen_acpi_create_domain(pdev, mgn_chip);
+ else
+ err = -EINVAL;
+
+ if (err) {
+ dev_err(&pdev->dev, "Failed to create mbi-gen@%p irqdomain", mgn_chip->base);
return err;
+ }
platform_set_drvdata(pdev, mgn_chip);
return 0;
@@ -303,10 +360,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
};
MODULE_DEVICE_TABLE(of, mbigen_of_match);
+static const struct acpi_device_id mbigen_acpi_match[] = {
+ { "HISI0152", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
+
static struct platform_driver mbigen_platform_driver = {
.driver = {
.name = "Hisilicon MBIGEN-V2",
.of_match_table = mbigen_of_match,
+ .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
},
.probe = mbigen_device_probe,
};
--
1.7.12.4
From: Hanjun Guo <[email protected]>
iort_node_map_rid() was designed to take an input id (that is not
necessarily a PCI requester id) and map it to an output id (eg an SMMU
streamid or an ITS deviceid) according to the mappings provided by an
IORT node mapping entries. This means that the iort_node_map_rid() input
id is not always a PCI requester id as its name, parameters and local
variables suggest, which is misleading.
Apply the s/rid/id substitution to the iort_node_map_rid() mapping
function and its users to make sure its intended usage is clearer.
Suggested-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Hanjun Guo <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
---
drivers/acpi/arm64/iort.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index a6b807d..28d0088 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -355,11 +355,11 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
return NULL;
}
-static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
- u32 rid_in, u32 *rid_out,
- u8 type_mask)
+static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,
+ u32 id_in, u32 *id_out,
+ u8 type_mask)
{
- u32 rid = rid_in;
+ u32 id = id_in;
/* Parse the ID mapping tree to find specified node type */
while (node) {
@@ -367,8 +367,8 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
int i;
if (IORT_TYPE_MASK(node->type) & type_mask) {
- if (rid_out)
- *rid_out = rid;
+ if (id_out)
+ *id_out = id;
return node;
}
@@ -385,9 +385,9 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
goto fail_map;
}
- /* Do the RID translation */
+ /* Do the ID translation */
for (i = 0; i < node->mapping_count; i++, map++) {
- if (!iort_id_map(map, node->type, rid, &rid))
+ if (!iort_id_map(map, node->type, id, &id))
break;
}
@@ -399,9 +399,9 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
}
fail_map:
- /* Map input RID to output RID unchanged on mapping failure*/
- if (rid_out)
- *rid_out = rid_in;
+ /* Map input ID to output ID unchanged on mapping failure */
+ if (id_out)
+ *id_out = id_in;
return NULL;
}
@@ -439,7 +439,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
if (!node)
return req_id;
- iort_node_map_rid(node, req_id, &dev_id, IORT_MSI_TYPE);
+ iort_node_map_id(node, req_id, &dev_id, IORT_MSI_TYPE);
return dev_id;
}
@@ -462,7 +462,7 @@ static int iort_dev_find_its_id(struct device *dev, u32 req_id,
if (!node)
return -ENXIO;
- node = iort_node_map_rid(node, req_id, NULL, IORT_MSI_TYPE);
+ node = iort_node_map_id(node, req_id, NULL, IORT_MSI_TYPE);
if (!node)
return -ENXIO;
@@ -591,8 +591,8 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
if (!node)
return NULL;
- parent = iort_node_map_rid(node, rid, &streamid,
- IORT_IOMMU_TYPE);
+ parent = iort_node_map_id(node, rid, &streamid,
+ IORT_IOMMU_TYPE);
ops = iort_iommu_xlate(dev, parent, streamid);
--
1.7.12.4
From: Hanjun Guo <[email protected]>
With the introduction of its_pmsi_init_one(), support for ACPI
firmware interface can be plugged into the gicv3 ITS driver.
Add code to scan the MADT table to get the ITS entry(ies), then use
the information to create the platform msi domain for devices
connected to it, mirroring the ITS PCI MSI code path.
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 37 +++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 3d9efd1..e4ba9f4 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -15,6 +15,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi_iort.h>
#include <linux/device.h>
#include <linux/msi.h>
#include <linux/of.h>
@@ -103,6 +104,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
return 0;
}
+#ifdef CONFIG_ACPI
+static int __init
+its_pmsi_parse_madt(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_translator *its_entry;
+ struct fwnode_handle *domain_handle;
+ const char *node_name;
+ int err = -ENXIO;
+
+ its_entry = (struct acpi_madt_generic_translator *)header;
+ node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
+ (long)its_entry->base_address);
+ domain_handle = iort_find_domain_token(its_entry->translation_id);
+ if (!domain_handle) {
+ pr_err("%s: Unable to locate ITS domain handle\n", node_name);
+ goto out;
+ }
+
+ err = its_pmsi_init_one(domain_handle, node_name);
+
+out:
+ kfree(node_name);
+ return err;
+}
+
+static void __init its_pmsi_acpi_init(void)
+{
+ acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
+ its_pmsi_parse_madt, 0);
+}
+#else
+static inline void its_pmsi_acpi_init(void) { }
+#endif
+
static void __init its_pmsi_of_init(void)
{
struct device_node *np;
@@ -119,6 +155,7 @@ static void __init its_pmsi_of_init(void)
static int __init its_pmsi_init(void)
{
its_pmsi_of_init();
+ its_pmsi_acpi_init();
return 0;
}
early_initcall(its_pmsi_init);
--
1.7.12.4
From: Hanjun Guo <[email protected]>
For devices connecting to ITS, the devices need to identify themself
through a dev id; this dev id is represented in the IORT table in named
component node [1] for platform devices, so this patch adds code that
scans the IORT table to retrieve the devices' dev id.
Leveraging the iort_node_map_platform_id() IORT API, add a new function
call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
retrieving dev id in ACPI platforms.
[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
include/linux/acpi_iort.h | 5 +++++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 83cd59d..fb95ceb 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
}
/**
+ * iort_pmsi_get_dev_id() - Get the device id for a device
+ * @dev: The device for which the mapping is to be done.
+ * @dev_id: The device ID found.
+ *
+ * Returns: 0 for successful find a dev id, -ENODEV on error
+ */
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+ int i;
+ struct acpi_iort_node *node;
+
+ node = iort_find_dev_node(dev);
+ if (!node)
+ return -ENODEV;
+
+ for (i = 0; i < node->mapping_count; i++) {
+ if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))
+ return 0;
+ }
+
+ return -ENODEV;
+}
+
+/**
* iort_dev_find_its_id() - Find the ITS identifier for a device
* @dev: The device.
* @req_id: Device's requester ID
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index e4ba9f4..e801fc0 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -57,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
msi_info = msi_get_domain_info(domain->parent);
- ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
+ ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
+ iort_pmsi_get_dev_id(dev, &dev_id);
if (ret)
return ret;
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 77e0809..d074c77 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -34,6 +34,7 @@
bool iort_node_match(u8 type);
u32 iort_msi_map_rid(struct device *dev, u32 req_id);
struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
/* IOMMU interface */
void iort_set_dma_mask(struct device *dev);
const struct iommu_ops *iort_iommu_configure(struct device *dev);
@@ -45,6 +46,10 @@ static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
{ return NULL; }
+
+static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{ return -ENODEV; }
+
/* IOMMU interface */
static inline void iort_set_dma_mask(struct device *dev) { }
static inline
--
1.7.12.4
From: Kefeng Wang <[email protected]>
Module owner will be set by driver core, so drop it.
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Hanjun Guo <[email protected]>
Reviewed-by: Ma Jun <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Thomas Gleixner <[email protected]>
---
drivers/irqchip/irq-mbigen.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 03b79b0..c01ab41 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device *pdev)
static struct platform_driver mbigen_platform_driver = {
.driver = {
.name = "Hisilicon MBIGEN-V2",
- .owner = THIS_MODULE,
.of_match_table = mbigen_of_match,
},
.probe = mbigen_device_probe,
--
1.7.12.4
From: Hanjun Guo <[email protected]>
By allowing platform MSI domain to be created on ACPI platforms,
a platform device MSI domain can be set-up when it is probed.
In order to do that, the MSI domain the platform device connects
to should be retrieved, so the iort_get_platform_device_domain() is
introduced to retrieve the domain from the IORT kernel layer.
With the domain retrieved, we need a proper way to set the
domain to platform device.
Given that some platform devices (irqchips) require the MSI irqdomain
to be their interrupt parent domain, the MSI irqdomain should be
determined before platform device is probed but after the platform
device is allocated which means that the code setting up the MSI
irqdomain, ie acpi_configure_pmsi_domain() should be called in
acpi_platform_notify() (that is triggered after adding a device but
before the respective driver is probed) for the platform MSI domain
code set-up path to work properly.
Acked-by: Rafael J. Wysocki <[email protected]> [for glue.c]
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
---
drivers/acpi/arm64/iort.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/acpi/glue.c | 6 ++++++
include/linux/acpi_iort.h | 3 +++
3 files changed, 59 insertions(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index fb95ceb..22e08d2 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -548,6 +548,56 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
}
+/**
+ * iort_get_platform_device_domain() - Find MSI domain related to a
+ * platform device
+ * @dev: the dev pointer associated with the platform device
+ *
+ * Returns: the MSI domain for this device, NULL otherwise
+ */
+static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
+{
+ struct acpi_iort_node *node, *msi_parent;
+ struct fwnode_handle *iort_fwnode;
+ struct acpi_iort_its_group *its;
+ int i;
+
+ /* find its associated iort node */
+ node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
+ iort_match_node_callback, dev);
+ if (!node)
+ return NULL;
+
+ /* then find its msi parent node */
+ for (i = 0; i < node->mapping_count; i++) {
+ msi_parent = iort_node_map_platform_id(node, NULL,
+ IORT_MSI_TYPE, i);
+ if (msi_parent)
+ break;
+ }
+
+ if (!msi_parent)
+ return NULL;
+
+ /* Move to ITS specific data */
+ its = (struct acpi_iort_its_group *)msi_parent->node_data;
+
+ iort_fwnode = iort_find_domain_token(its->identifiers[0]);
+ if (!iort_fwnode)
+ return NULL;
+
+ return irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);
+}
+
+void acpi_configure_pmsi_domain(struct device *dev)
+{
+ struct irq_domain *msi_domain;
+
+ msi_domain = iort_get_platform_device_domain(dev);
+ if (msi_domain)
+ dev_set_msi_domain(dev, msi_domain);
+}
+
static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
{
u32 *rid = data;
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index fb19e1c..ec31b43 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -6,6 +6,8 @@
*
* This file is released under the GPLv2.
*/
+
+#include <linux/acpi_iort.h>
#include <linux/export.h>
#include <linux/init.h>
#include <linux/list.h>
@@ -14,6 +16,7 @@
#include <linux/rwsem.h>
#include <linux/acpi.h>
#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
#include "internal.h"
@@ -322,6 +325,9 @@ static int acpi_platform_notify(struct device *dev)
if (!adev)
goto out;
+ if (dev->bus == &platform_bus_type)
+ acpi_configure_pmsi_domain(dev);
+
if (type && type->setup)
type->setup(dev);
else if (adev->handler && adev->handler->bind)
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index d074c77..06b182e 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -34,6 +34,7 @@
bool iort_node_match(u8 type);
u32 iort_msi_map_rid(struct device *dev, u32 req_id);
struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
+void acpi_configure_pmsi_domain(struct device *dev);
int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
/* IOMMU interface */
void iort_set_dma_mask(struct device *dev);
@@ -47,6 +48,8 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
{ return NULL; }
+static inline void acpi_configure_pmsi_domain(struct device *dev) { }
+
static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
{ return -ENODEV; }
--
1.7.12.4
From: Hanjun Guo <[email protected]>
To retrieve dev id for IORT named components nodes there are
two steps involved (second is optional):
(1) Retrieve the initial id (this may well provide the final mapping)
(2) Map the id (optional if (1) represents the map type we need), this
is needed for use cases such as NC (named component) -> SMMU -> ITS
mappings.
the iort_node_get_id() function was created for step (1) above and
iort_node_map_rid() for step (2).
Create a wrapper, named iort_node_map_platform_id(), that encompasses
the two steps at once to retrieve the dev id to provide steps (1)-(2)
functionality.
iort_node_map_platform_id() will handle the parent type so type handling
in iort_node_get_id() is duplicated, remove it and update current
iort_node_get_id() users to move them over to iort_node_map_platform_id().
Suggested-by: Lorenzo Pieralisi <[email protected]>
Suggested-by: Tomasz Nowicki <[email protected]>
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
---
drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 28d0088..83cd59d 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -318,8 +318,7 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
static
struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
- u32 *id_out, u8 type_mask,
- int index)
+ u32 *id_out, int index)
{
struct acpi_iort_node *parent;
struct acpi_iort_id_mapping *map;
@@ -341,9 +340,6 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
map->output_reference);
- if (!(IORT_TYPE_MASK(parent->type) & type_mask))
- return NULL;
-
if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
@@ -406,6 +402,34 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,
return NULL;
}
+static
+struct acpi_iort_node *iort_node_map_platform_id(struct acpi_iort_node *node,
+ u32 *id_out, u8 type_mask,
+ int index)
+{
+ struct acpi_iort_node *parent;
+ u32 id;
+
+ /* step 1: retrieve the initial dev id */
+ parent = iort_node_get_id(node, &id, index);
+ if (!parent)
+ return NULL;
+
+ /*
+ * optional step 2: map the initial dev id if its parent is not
+ * the target type we want, map it again for the use cases such
+ * as NC (named component) -> SMMU -> ITS. If the type is matched,
+ * return the initial dev id and its parent pointer directly.
+ */
+ if (!(IORT_TYPE_MASK(parent->type) & type_mask))
+ parent = iort_node_map_id(parent, id, id_out, type_mask);
+ else
+ if (id_out)
+ *id_out = id;
+
+ return parent;
+}
+
static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
{
struct pci_bus *pbus;
@@ -604,14 +628,15 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
if (!node)
return NULL;
- parent = iort_node_get_id(node, &streamid,
- IORT_IOMMU_TYPE, i++);
+ parent = iort_node_map_platform_id(node, &streamid,
+ IORT_IOMMU_TYPE, i++);
while (parent) {
ops = iort_iommu_xlate(dev, parent, streamid);
- parent = iort_node_get_id(node, &streamid,
- IORT_IOMMU_TYPE, i++);
+ parent = iort_node_map_platform_id(node, &streamid,
+ IORT_IOMMU_TYPE,
+ i++);
}
}
--
1.7.12.4
On Tue, Mar 07, 2017 at 08:39:55PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <[email protected]>
>
> With platform msi support landed in the kernel, and the introduction
> of IORT for GICv3 ITS (PCI MSI) and SMMU, 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).
>
> v8 -> v9:
> - Rebased on top of 4.11-rc1 and retest;
> - Some of patch's commit message was updated by Lorenzo and
> it's clearer (thanks!)
>
> No update in the code, hope it's the final revision.
I will be off the radar till -rc3 but I do not expect major changes
to the series in its current form given that dependencies were merged
in the merge window (ACPI IRQ probe deferral and IORT fixes).
Thanks,
Lorenzo
> v7 -> v8:
> - Using _CRS instead of _PRS for Interrupt resources for mbigen
>
> - reshuffle the patch slightly to introduce iort_node_map_platform_id()
> first and then retrieve the dev id for platform MSI, no functional
> change
>
> - Fix the compile error with patch "irqchip: gicv3-its: platform-msi:
> scan MADT to create platform msi domain", which forgot to add
> <include/acpi_iort.h> (added in later patches in last version).
>
> - renew some commit message which suggested by Lorenzo
>
> - address some othe minor issues which commented by Lorenzo
>
> - Add review and test tag as it's no functional change except
> the last patch of mbigen
>
> - rebase on top of 4.10-rc4 and test it on x86, ia64 and ARM64
> platforms (also with Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
> Add IRQ combiner driver" and Lorenzo's patch
> https://patchwork.kernel.org/patch/9507041/)
>
> v6 -> v7:
> - Introduce iort_node_map_platform_id() to retrieve the
> dev id for both NC (named component) -> ITS/SMMU and
> NC -> SMMU -> ITS cases, suggested by Lorenzo;
>
> - Reorder the patches and rewrite some commit message;
>
> - Remove the test tags because it has major changes
> to retrieve the dev id, Sinan, Majun, Xinwei, could
> you please test them again on your platform?
>
> - rebased on top of 4.10-rc3 and Lorenzo's patch
> https://patchwork.kernel.org/patch/9507041/
>
> - Tested against Agustin's patch [1-2/3] "[PATCH V9 0/3] irqchip: qcom:
> Add IRQ combiner driver"
>
> v5 -> v6:
> - Call acpi_configure_pmsi_domain() for platform devices in
> acpi_platform_notify() as it's cleaner (suggested by Rafael)
> - Remove the "u8 type" for iort_id_map() because it's unused
> - Rebase on top of 4.10-rc2
> - Collect test and review tags
>
> v4 -> v5:
> - Add mbigen support back with tested on with Agustin's patchset,
> and it's a good example of how ACPI platform MSI works
> - rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling)
>
> v3 -> v4:
> - Drop mbi-gen patches to just submit platform msi support because
> will rebase mbi-gen patches on top of Agustin's patchset, and discusion
> is going there.
> - Add a patch to support device topology such as NC(named componant, paltform device)
> ->SMMU->ITS which suggested by Lorenzo;
> - rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
> - rebased on top of 4.9-rc7
>
> v2 -> v3:
> - Drop RFC tag
> - Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU support [1]
> - Add 3 cleanup patches (patch 1, 2, 3)
> - Drop arch_init call patch from last version
> - Introduce a callback for platform device to set msi domain
> - Introduce a new API to get paltform device's domain instead of
> reusing the PCI one in previous version
> - Add a patch to rework iort_node_get_id()
>
> [1]: http://www.mail-archive.com/[email protected]/msg1251993.html
>
> v1 -> 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.
>
> Hanjun Guo (13):
> ACPI/IORT: Fix the indentation in iort_scan_node()
> ACPI/IORT: Add missing comment for iort_dev_find_its_id()
> ACPI/IORT: Rework iort_match_node_callback() return value handling
> irqchip: gic-v3-its: keep the include header files in alphabetic
> order
> irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
> 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/IORT: Rename iort_node_map_rid() to make it generic
> ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
> ACPI: platform-msi: retrieve dev id from IORT
> ACPI: platform: setup MSI domain for ACPI based platform device
> msi: platform: make platform_msi_create_device_domain() ACPI aware
> irqchip: mbigen: Add ACPI support
>
> Kefeng Wang (2):
> irqchip: mbigen: drop module owner
> irqchip: mbigen: introduce mbigen_of_create_domain()
>
> drivers/acpi/arm64/iort.c | 158 +++++++++++++++++++++-----
> drivers/acpi/glue.c | 6 +
> drivers/base/platform-msi.c | 3 +-
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++++++++++++----
> drivers/irqchip/irq-gic-v3-its.c | 2 +-
> drivers/irqchip/irq-mbigen.c | 110 +++++++++++++++---
> include/linux/acpi_iort.h | 8 ++
> 7 files changed, 317 insertions(+), 76 deletions(-)
>
> --
> 1.7.12.4
>
On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <[email protected]>
>
> For devices connecting to ITS, the devices need to identify themself
> through a dev id; this dev id is represented in the IORT table in named
> component node [1] for platform devices, so this patch adds code that
> scans the IORT table to retrieve the devices' dev id.
>
> Leveraging the iort_node_map_platform_id() IORT API, add a new function
> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
> retrieving dev id in ACPI platforms.
>
> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>
> Signed-off-by: Hanjun Guo <[email protected]>
> [[email protected]: rewrote commit log]
> Signed-off-by: Lorenzo Pieralisi <[email protected]>
> Tested-by: Ming Lei <[email protected]>
> Tested-by: Wei Xu <[email protected]>
> Tested-by: Sinan Kaya <[email protected]>
> Cc: Marc Zyngier <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
> Cc: Tomasz Nowicki <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> ---
> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
> include/linux/acpi_iort.h | 5 +++++
> 3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 83cd59d..fb95ceb 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> }
>
> /**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, -ENODEV on error
> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + int i;
> + struct acpi_iort_node *node;
> +
> + node = iort_find_dev_node(dev);
> + if (!node)
> + return -ENODEV;
I think that when specs are updated so that we can enable SMMU MSIs we
shall have to find a way to get the acpi_iort_node for a device that is
not a named component here (ie SMMU), I reckon we can use the
fwnode_handle but I have to have a deeper look.
This does not affect the patchset in its current form, just scanning
the code to make sure we will be able to support SMMU MSIs too when
time comes.
Thanks,
Lorenzo
> +
> + for (i = 0; i < node->mapping_count; i++) {
> + if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))
> + return 0;
> + }
> +
> + return -ENODEV;
> +}
> +
> +/**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> * @req_id: Device's requester ID
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index e4ba9f4..e801fc0 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -57,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>
> msi_info = msi_get_domain_info(domain->parent);
>
> - ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
> + iort_pmsi_get_dev_id(dev, &dev_id);
> if (ret)
> return ret;
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 77e0809..d074c77 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -34,6 +34,7 @@
> bool iort_node_match(u8 type);
> u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> @@ -45,6 +46,10 @@ static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> u32 req_id)
> { return NULL; }
> +
> +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{ return -ENODEV; }
> +
> /* IOMMU interface */
> static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> --
> 1.7.12.4
>
Hi Marc,
On 2017/3/7 22:43, Lorenzo Pieralisi wrote:
> On Tue, Mar 07, 2017 at 08:39:55PM +0800, Hanjun Guo wrote:
>> From: Hanjun Guo <[email protected]>
>>
>> With platform msi support landed in the kernel, and the introduction
>> of IORT for GICv3 ITS (PCI MSI) and SMMU, 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).
>>
>> v8 -> v9:
>> - Rebased on top of 4.11-rc1 and retest;
>> - Some of patch's commit message was updated by Lorenzo and
>> it's clearer (thanks!)
>>
>> No update in the code, hope it's the final revision.
>
> I will be off the radar till -rc3 but I do not expect major changes
> to the series in its current form given that dependencies were merged
> in the merge window (ACPI IRQ probe deferral and IORT fixes).
What's your opinion on this patch set? especially for the last 3
patches for mbigen driver, please comment on it to see if I need
to take further steps.
Thanks
Hanjun
On 2017/3/7 22:35, Lorenzo Pieralisi wrote:
> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
>> From: Hanjun Guo <[email protected]>
>>
>> For devices connecting to ITS, the devices need to identify themself
>> through a dev id; this dev id is represented in the IORT table in named
>> component node [1] for platform devices, so this patch adds code that
>> scans the IORT table to retrieve the devices' dev id.
>>
>> Leveraging the iort_node_map_platform_id() IORT API, add a new function
>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
>> retrieving dev id in ACPI platforms.
>>
>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>>
>> Signed-off-by: Hanjun Guo <[email protected]>
>> [[email protected]: rewrote commit log]
>> Signed-off-by: Lorenzo Pieralisi <[email protected]>
>> Tested-by: Ming Lei <[email protected]>
>> Tested-by: Wei Xu <[email protected]>
>> Tested-by: Sinan Kaya <[email protected]>
>> Cc: Marc Zyngier <[email protected]>
>> Cc: Lorenzo Pieralisi <[email protected]>
>> Cc: Tomasz Nowicki <[email protected]>
>> Cc: Thomas Gleixner <[email protected]>
>> ---
>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
>> include/linux/acpi_iort.h | 5 +++++
>> 3 files changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index 83cd59d..fb95ceb 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
>> }
>>
>> /**
>> + * iort_pmsi_get_dev_id() - Get the device id for a device
>> + * @dev: The device for which the mapping is to be done.
>> + * @dev_id: The device ID found.
>> + *
>> + * Returns: 0 for successful find a dev id, -ENODEV on error
>> + */
>> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>> +{
>> + int i;
>> + struct acpi_iort_node *node;
>> +
>> + node = iort_find_dev_node(dev);
>> + if (!node)
>> + return -ENODEV;
> I think that when specs are updated so that we can enable SMMU MSIs we
> shall have to find a way to get the acpi_iort_node for a device that is
> not a named component here (ie SMMU), I reckon we can use the
> fwnode_handle but I have to have a deeper look.
Seems we can do this as follows:
---
drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 22e08d2..c794219 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -121,6 +121,31 @@ static inline void iort_delete_fwnode(struct acpi_iort_node *node)
spin_unlock(&iort_fwnode_lock);
}
+/**
+ * iort_get_iort_node() - Retrieve iort_node associated with an fwnode
+ *
+ * @fwnode: fwnode associated with device to be looked-up
+ *
+ * Returns: iort_node pointer on success, NULL on failure
+ */
+static inline
+struct acpi_iort_node *iort_get_iort_node(struct fwnode_handle *fwnode)
+{
+ struct iort_fwnode *curr;
+ struct acpi_iort_node *iort_node = NULL;
+
+ spin_lock(&iort_fwnode_lock);
+ list_for_each_entry(curr, &iort_fwnode_list, list) {
+ if (curr->fwnode == fwnode) {
+ iort_node = curr->iort_node;
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+
+ return iort_node;
+}
+
typedef acpi_status (*iort_find_node_callback)
(struct acpi_iort_node *node, void *context);
@@ -434,9 +459,25 @@ static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
{
struct pci_bus *pbus;
- if (!dev_is_pci(dev))
+ if (!dev_is_pci(dev)) {
+ struct acpi_iort_node *node;
+ /*
+ * scan iort_fwnode_list to see if it's an iort platform
+ * device (such as SMMU, PMCG),its iort node already cached
+ * and associated with fwnode when iort platform devices
+ * were initialized.
+ */
+ node = iort_get_iort_node(dev->fwnode);
+ if (node)
+ return node;
+
+ /*
+ * if not, then it should be a platform device defined in
+ * DSDT (with Named Component node in IORT)
+ */
return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
iort_match_node_callback, dev);
+ }
/* Find a PCI root bus */
pbus = to_pci_dev(dev)->bus;
>
> This does not affect the patchset in its current form, just scanning
> the code to make sure we will be able to support SMMU MSIs too when
> time comes.
Sure, thanks!
Hanjun
On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <[email protected]>
>
> With the preparation of platform msi support and interrupt producer
> in DSDT, we can add mbigen ACPI support now.
>
> We are using Interrupt resource type in _CRS methd to indicate number
> of irq pins instead of num_pins in DT to avoid _DSD usage in this case.
>
> For mbigen,
> Device(MBI0) {
> Name(_HID, "HISI0152")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> Interrupt(ResourceProducer,...) {12,14,....}
What do these interrupt numbers represent ? This looks wrong to me.
An interrupt descriptor is there to describe the interrupts a device
can generate; you are using it just to add a "standard" (that is
not standard at all) way of counting the number of vectors allocated
to this specific chip and that's just wrong.
Can't you use something like Agustin did in the QCOM combiner:
drivers/irqchip/qcom-irq-combiner.c
to detect the MSI vector length (ie by describing the MBIgen through
generic registers and use the bit width to compute the vector
lenght) ? I am not sure how feasible it is given that my knowledge
of MBIgen is pretty poor.
I understand we want to avoid _DSD properties but we should not
work around standard bindings to achieve that goal.
Side effect: IIUC the kernel will allocate an array of resources for
your MBIgen interrupts whose size equal the Interrupt descriptor,
which is as bad as it can get given that those resources are to
the best of my knowledge unused.
Lorenzo
> })
> }
>
> For devices,
> Device(COM0) {
> Name(_HID, "ACPIIDxx")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
> Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
> })
> }
>
> With the help of platform msi and interrupt producer, then devices
> will get the virq from mbigen's irqdomain.
>
> Signed-off-by: Hanjun Guo <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
> Cc: Ma Jun <[email protected]>
> Cc: Marc Zyngier <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> ---
> drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 3756408..e6bb503 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -16,6 +16,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi.h>
> #include <linux/interrupt.h>
> #include <linux/irqchip.h>
> #include <linux/module.h>
> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
> unsigned long *hwirq,
> unsigned int *type)
> {
> - if (is_of_node(fwspec->fwnode)) {
> + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
> if (fwspec->param_count != 2)
> return -EINVAL;
>
> @@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
> + void *context)
> +{
> + struct acpi_resource_extended_irq *ext_irq;
> + u32 *num_irqs = context;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = &ares->data.extended_irq;
> + *num_irqs += ext_irq->interrupt_count;
> + break;
> + default:
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> + struct mbigen_device *mgn_chip)
> +{
> + struct irq_domain *domain;
> + u32 num_msis = 0;
> + acpi_status status;
> +
> + status = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__CRS,
> + mbigen_acpi_process_resource, &num_msis);
> + if (ACPI_FAILURE(status) || num_msis == 0)
> + return -EINVAL;
> +
> + domain = platform_msi_create_device_domain(&pdev->dev, num_msis,
> + mbigen_write_msg,
> + &mbigen_domain_ops,
> + mgn_chip);
> + if (!domain)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +#else
> +static inline int mbigen_acpi_create_domain(struct platform_device *pdev,
> + struct mbigen_device *mgn_chip)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> static int mbigen_device_probe(struct platform_device *pdev)
> {
> struct mbigen_device *mgn_chip;
> @@ -289,9 +338,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
> if (IS_ERR(mgn_chip->base))
> return PTR_ERR(mgn_chip->base);
>
> - err = mbigen_of_create_domain(pdev, mgn_chip);
> - if (err)
> + if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
> + err = mbigen_of_create_domain(pdev, mgn_chip);
> + else if (ACPI_COMPANION(&pdev->dev))
> + err = mbigen_acpi_create_domain(pdev, mgn_chip);
> + else
> + err = -EINVAL;
> +
> + if (err) {
> + dev_err(&pdev->dev, "Failed to create mbi-gen@%p irqdomain", mgn_chip->base);
> return err;
> + }
>
> platform_set_drvdata(pdev, mgn_chip);
> return 0;
> @@ -303,10 +360,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
> };
> MODULE_DEVICE_TABLE(of, mbigen_of_match);
>
> +static const struct acpi_device_id mbigen_acpi_match[] = {
> + { "HISI0152", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
> +
> static struct platform_driver mbigen_platform_driver = {
> .driver = {
> .name = "Hisilicon MBIGEN-V2",
> .of_match_table = mbigen_of_match,
> + .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
> },
> .probe = mbigen_device_probe,
> };
> --
> 1.7.12.4
>
On 21/03/2017 14:45, Lorenzo Pieralisi wrote:
> On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote:
>> From: Hanjun Guo <[email protected]>
>>
>> With the preparation of platform msi support and interrupt producer
>> in DSDT, we can add mbigen ACPI support now.
>>
>> We are using Interrupt resource type in _CRS methd to indicate number
>> of irq pins instead of num_pins in DT to avoid _DSD usage in this case.
>>
>> For mbigen,
>> Device(MBI0) {
>> Name(_HID, "HISI0152")
>> Name(_UID, Zero)
>> Name(_CRS, ResourceTemplate() {
>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>> Interrupt(ResourceProducer,...) {12,14,....}
>
> What do these interrupt numbers represent ? This looks wrong to me.
> An interrupt descriptor is there to describe the interrupts a device
> can generate; you are using it just to add a "standard" (that is
> not standard at all) way of counting the number of vectors allocated
> to this specific chip and that's just wrong.
>
As I understand, the count of interrupts we are declaring for the mbigen
is the same as the sum of interrupts for that mbigen's children.
So at the point we probe the mbigen, can we just deference the children
to count their interrupts, and use this as the #msis?
> Can't you use something like Agustin did in the QCOM combiner:
>
> drivers/irqchip/qcom-irq-combiner.c
>
> to detect the MSI vector length (ie by describing the MBIgen through
> generic registers and use the bit width to compute the vector
> lenght) ? I am not sure how feasible it is given that my knowledge
> of MBIgen is pretty poor.
>
> I understand we want to avoid _DSD properties but we should not
> work around standard bindings to achieve that goal.
>
We use "num-pins" for dt solution, but it is not so welcome here.
> Side effect: IIUC the kernel will allocate an array of resources for
> your MBIgen interrupts whose size equal the Interrupt descriptor,
> which is as bad as it can get given that those resources are to
> the best of my knowledge unused.
>
Much appreciated,
John
> Lorenzo
>
>> })
>> }
>>
>> For devices,
>> Device(COM0) {
>> Name(_HID, "ACPIIDxx")
>> Name(_UID, Zero)
>> Name(_CRS, ResourceTemplate() {
>> Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
>> Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
>> })
>> }
>>
>> With the help of platform msi and interrupt producer, then devices
>> will get the virq from mbigen's irqdomain.
>>
>> Signed-off-by: Hanjun Guo <[email protected]>
>> Cc: Lorenzo Pieralisi <[email protected]>
>> Cc: Ma Jun <[email protected]>
>> Cc: Marc Zyngier <[email protected]>
>> Cc: Thomas Gleixner <[email protected]>
>> ---
>> drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 67 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>> index 3756408..e6bb503 100644
>> --- a/drivers/irqchip/irq-mbigen.c
>> +++ b/drivers/irqchip/irq-mbigen.c
>> @@ -16,6 +16,7 @@
>> * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> */
>>
>> +#include <linux/acpi.h>
>> #include <linux/interrupt.h>
>> #include <linux/irqchip.h>
>> #include <linux/module.h>
>> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
>> unsigned long *hwirq,
>> unsigned int *type)
>> {
>> - if (is_of_node(fwspec->fwnode)) {
>> + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
>> if (fwspec->param_count != 2)
>> return -EINVAL;
>>
>> @@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_ACPI
>> +static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
>> + void *context)
>> +{
>> + struct acpi_resource_extended_irq *ext_irq;
>> + u32 *num_irqs = context;
>> +
>> + switch (ares->type) {
>> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
>> + ext_irq = &ares->data.extended_irq;
>> + *num_irqs += ext_irq->interrupt_count;
>> + break;
>> + default:
>> + break;
>> + }
>> +
>> + return AE_OK;
>> +}
>> +
>> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
>> + struct mbigen_device *mgn_chip)
>> +{
>> + struct irq_domain *domain;
>> + u32 num_msis = 0;
>> + acpi_status status;
>> +
>> + status = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__CRS,
>> + mbigen_acpi_process_resource, &num_msis);
>> + if (ACPI_FAILURE(status) || num_msis == 0)
>> + return -EINVAL;
>> +
>> + domain = platform_msi_create_device_domain(&pdev->dev, num_msis,
>> + mbigen_write_msg,
>> + &mbigen_domain_ops,
>> + mgn_chip);
>> + if (!domain)
>> + return -ENOMEM;
>> +
>> + return 0;
>> +}
>> +#else
>> +static inline int mbigen_acpi_create_domain(struct platform_device *pdev,
>> + struct mbigen_device *mgn_chip)
>> +{
>> + return -ENODEV;
>> +}
>> +#endif
>> +
>> static int mbigen_device_probe(struct platform_device *pdev)
>> {
>> struct mbigen_device *mgn_chip;
>> @@ -289,9 +338,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
>> if (IS_ERR(mgn_chip->base))
>> return PTR_ERR(mgn_chip->base);
>>
>> - err = mbigen_of_create_domain(pdev, mgn_chip);
>> - if (err)
>> + if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
>> + err = mbigen_of_create_domain(pdev, mgn_chip);
>> + else if (ACPI_COMPANION(&pdev->dev))
>> + err = mbigen_acpi_create_domain(pdev, mgn_chip);
>> + else
>> + err = -EINVAL;
>> +
>> + if (err) {
>> + dev_err(&pdev->dev, "Failed to create mbi-gen@%p irqdomain", mgn_chip->base);
>> return err;
>> + }
>>
>> platform_set_drvdata(pdev, mgn_chip);
>> return 0;
>> @@ -303,10 +360,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
>> };
>> MODULE_DEVICE_TABLE(of, mbigen_of_match);
>>
>> +static const struct acpi_device_id mbigen_acpi_match[] = {
>> + { "HISI0152", 0 },
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
>> +
>> static struct platform_driver mbigen_platform_driver = {
>> .driver = {
>> .name = "Hisilicon MBIGEN-V2",
>> .of_match_table = mbigen_of_match,
>> + .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
>> },
>> .probe = mbigen_device_probe,
>> };
>> --
>> 1.7.12.4
>>
> _______________________________________________
> linuxarm mailing list
> [email protected]
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
Hanjun, John,
On 22/03/17 14:12, John Garry wrote:
> On 21/03/2017 14:45, Lorenzo Pieralisi wrote:
>> On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote:
>>> From: Hanjun Guo <[email protected]>
>>>
>>> With the preparation of platform msi support and interrupt producer
>>> in DSDT, we can add mbigen ACPI support now.
>>>
>>> We are using Interrupt resource type in _CRS methd to indicate number
>>> of irq pins instead of num_pins in DT to avoid _DSD usage in this case.
>>>
>>> For mbigen,
>>> Device(MBI0) {
>>> Name(_HID, "HISI0152")
>>> Name(_UID, Zero)
>>> Name(_CRS, ResourceTemplate() {
>>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>>> Interrupt(ResourceProducer,...) {12,14,....}
>>
>> What do these interrupt numbers represent ? This looks wrong to me.
>> An interrupt descriptor is there to describe the interrupts a device
>> can generate; you are using it just to add a "standard" (that is
>> not standard at all) way of counting the number of vectors allocated
>> to this specific chip and that's just wrong.
>>
>
> As I understand, the count of interrupts we are declaring for the mbigen
> is the same as the sum of interrupts for that mbigen's children.
>
> So at the point we probe the mbigen, can we just deference the children
> to count their interrupts, and use this as the #msis?
>
>> Can't you use something like Agustin did in the QCOM combiner:
>>
>> drivers/irqchip/qcom-irq-combiner.c
>>
>> to detect the MSI vector length (ie by describing the MBIgen through
>> generic registers and use the bit width to compute the vector
>> lenght) ? I am not sure how feasible it is given that my knowledge
>> of MBIgen is pretty poor.
>>
>> I understand we want to avoid _DSD properties but we should not
>> work around standard bindings to achieve that goal.
>>
>
> We use "num-pins" for dt solution, but it is not so welcome here.
Well, this device is already completely out of any standard description
on the ACPI side. And given that it bloats both the ACPI tables and the
kernel data structures, I can only suggest that you take advantage of
_DSD here, as misusing the standard properties is not something that we
should condone. It will also make the driver more manageable, as it will
use similar properties on both firmware implementations.
I feel like I need to stress the urgency here. We're at -rc4, and still
with unsolved issues. None of us want to miss the next merge window.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Hi Marc Many thanks for your comments
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Marc Zyngier
> Sent: 27 March 2017 09:47
> To: John Garry; Lorenzo Pieralisi; Guohanjun (Hanjun Guo)
> Cc: Rafael J. Wysocki; Yimin (Leo); Greg KH; Linuxarm; linux-
> [email protected]; Sinan Kaya; [email protected]; Hanjun
> Guo; Tomasz Nowicki; Thomas Gleixner; linux-arm-
> [email protected]
> Subject: Re: [PATCH v9 15/15] irqchip: mbigen: Add ACPI support
>
> Hanjun, John,
>
> On 22/03/17 14:12, John Garry wrote:
> > On 21/03/2017 14:45, Lorenzo Pieralisi wrote:
> >> On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote:
> >>> From: Hanjun Guo <[email protected]>
> >>>
> >>> With the preparation of platform msi support and interrupt producer
> >>> in DSDT, we can add mbigen ACPI support now.
> >>>
> >>> We are using Interrupt resource type in _CRS methd to indicate
> number
> >>> of irq pins instead of num_pins in DT to avoid _DSD usage in this
> case.
> >>>
> >>> For mbigen,
> >>> Device(MBI0) {
> >>> Name(_HID, "HISI0152")
> >>> Name(_UID, Zero)
> >>> Name(_CRS, ResourceTemplate() {
> >>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> >>> Interrupt(ResourceProducer,...) {12,14,....}
> >>
> >> What do these interrupt numbers represent ? This looks wrong to me.
> >> An interrupt descriptor is there to describe the interrupts a device
> >> can generate; you are using it just to add a "standard" (that is
> >> not standard at all) way of counting the number of vectors allocated
> >> to this specific chip and that's just wrong.
> >>
> >
> > As I understand, the count of interrupts we are declaring for the
> mbigen
> > is the same as the sum of interrupts for that mbigen's children.
> >
> > So at the point we probe the mbigen, can we just deference the
> children
> > to count their interrupts, and use this as the #msis?
> >
> >> Can't you use something like Agustin did in the QCOM combiner:
> >>
> >> drivers/irqchip/qcom-irq-combiner.c
> >>
> >> to detect the MSI vector length (ie by describing the MBIgen through
> >> generic registers and use the bit width to compute the vector
> >> lenght) ? I am not sure how feasible it is given that my knowledge
> >> of MBIgen is pretty poor.
> >>
> >> I understand we want to avoid _DSD properties but we should not
> >> work around standard bindings to achieve that goal.
> >>
> >
> > We use "num-pins" for dt solution, but it is not so welcome here.
>
> Well, this device is already completely out of any standard description
> on the ACPI side. And given that it bloats both the ACPI tables and the
> kernel data structures, I can only suggest that you take advantage of
> _DSD here, as misusing the standard properties is not something that we
> should condone. It will also make the driver more manageable, as it
> will
> use similar properties on both firmware implementations.
>
> I feel like I need to stress the urgency here. We're at -rc4, and still
> with unsolved issues. None of us want to miss the next merge window.
>
As follow up our guys would work on a solution whose ACPI table looks
like the following one:
For mbigen,
Device(MBI0) {
Name(_HID, "HISI0152")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
})
Name(_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"num-pins", xxx}
}
})
}
For devices,
Device(COM0) {
Name(_HID, "ACPIIDxx")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
})
}
Marc, Lorenzo if you are ok with the above we will submit v10 based on this...
Many Thanks
Gab
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
> _______________________________________________
> linuxarm mailing list
> [email protected]
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
[+Al,Darren to comment on _DSD review process]
On Mon, Mar 27, 2017 at 12:24:45PM +0000, Gabriele Paoloni wrote:
> Hi Marc Many thanks for your comments
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > On Behalf Of Marc Zyngier
> > Sent: 27 March 2017 09:47
> > To: John Garry; Lorenzo Pieralisi; Guohanjun (Hanjun Guo)
> > Cc: Rafael J. Wysocki; Yimin (Leo); Greg KH; Linuxarm; linux-
> > [email protected]; Sinan Kaya; [email protected]; Hanjun
> > Guo; Tomasz Nowicki; Thomas Gleixner; linux-arm-
> > [email protected]
> > Subject: Re: [PATCH v9 15/15] irqchip: mbigen: Add ACPI support
> >
> > Hanjun, John,
> >
> > On 22/03/17 14:12, John Garry wrote:
> > > On 21/03/2017 14:45, Lorenzo Pieralisi wrote:
> > >> On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote:
> > >>> From: Hanjun Guo <[email protected]>
> > >>>
> > >>> With the preparation of platform msi support and interrupt producer
> > >>> in DSDT, we can add mbigen ACPI support now.
> > >>>
> > >>> We are using Interrupt resource type in _CRS methd to indicate
> > number
> > >>> of irq pins instead of num_pins in DT to avoid _DSD usage in this
> > case.
> > >>>
> > >>> For mbigen,
> > >>> Device(MBI0) {
> > >>> Name(_HID, "HISI0152")
> > >>> Name(_UID, Zero)
> > >>> Name(_CRS, ResourceTemplate() {
> > >>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> > >>> Interrupt(ResourceProducer,...) {12,14,....}
> > >>
> > >> What do these interrupt numbers represent ? This looks wrong to me.
> > >> An interrupt descriptor is there to describe the interrupts a device
> > >> can generate; you are using it just to add a "standard" (that is
> > >> not standard at all) way of counting the number of vectors allocated
> > >> to this specific chip and that's just wrong.
> > >>
> > >
> > > As I understand, the count of interrupts we are declaring for the
> > mbigen
> > > is the same as the sum of interrupts for that mbigen's children.
> > >
> > > So at the point we probe the mbigen, can we just deference the
> > children
> > > to count their interrupts, and use this as the #msis?
> > >
> > >> Can't you use something like Agustin did in the QCOM combiner:
> > >>
> > >> drivers/irqchip/qcom-irq-combiner.c
> > >>
> > >> to detect the MSI vector length (ie by describing the MBIgen through
> > >> generic registers and use the bit width to compute the vector
> > >> lenght) ? I am not sure how feasible it is given that my knowledge
> > >> of MBIgen is pretty poor.
> > >>
> > >> I understand we want to avoid _DSD properties but we should not
> > >> work around standard bindings to achieve that goal.
> > >>
> > >
> > > We use "num-pins" for dt solution, but it is not so welcome here.
> >
> > Well, this device is already completely out of any standard description
> > on the ACPI side. And given that it bloats both the ACPI tables and the
> > kernel data structures, I can only suggest that you take advantage of
> > _DSD here, as misusing the standard properties is not something that we
> > should condone. It will also make the driver more manageable, as it
> > will
> > use similar properties on both firmware implementations.
> >
> > I feel like I need to stress the urgency here. We're at -rc4, and still
> > with unsolved issues. None of us want to miss the next merge window.
> >
>
> As follow up our guys would work on a solution whose ACPI table looks
> like the following one:
>
> For mbigen,
> Device(MBI0) {
> Name(_HID, "HISI0152")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> })
>
> Name(_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package ()
> {
> Package () {"num-pins", xxx}
> }
> })
> }
>
> For devices,
> Device(COM0) {
> Name(_HID, "ACPIIDxx")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
> Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
> })
> }
>
>
> Marc, Lorenzo if you are ok with the above we will submit v10 based on this...
I am ok with it. I am not 100% up-to-date on what's the status on _DSD
bindings/review/guidelines but it would be certainly a good idea to
kickstart the process for MBIgen which basically means following this
as far as I know (and post to the relevant mailing list):
https://github.com/ahs3/dsd/blob/master/documentation/process_rules.txt
Al and Darren may add to that as they have more insights.
I would like to send IORT patches to Catalin as soon as possible so
as Marc pointed out the sooner we sort this out the better.
Thanks,
Lorenzo
On 03/27/2017 09:27 AM, Lorenzo Pieralisi wrote:
> [+Al,Darren to comment on _DSD review process]
>
> On Mon, Mar 27, 2017 at 12:24:45PM +0000, Gabriele Paoloni wrote:
>> Hi Marc Many thanks for your comments
>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]]
>>> On Behalf Of Marc Zyngier
>>> Sent: 27 March 2017 09:47
>>> To: John Garry; Lorenzo Pieralisi; Guohanjun (Hanjun Guo)
>>> Cc: Rafael J. Wysocki; Yimin (Leo); Greg KH; Linuxarm; linux-
>>> [email protected]; Sinan Kaya; [email protected]; Hanjun
>>> Guo; Tomasz Nowicki; Thomas Gleixner; linux-arm-
>>> [email protected]
>>> Subject: Re: [PATCH v9 15/15] irqchip: mbigen: Add ACPI support
>>>
>>> Hanjun, John,
>>>
>>> On 22/03/17 14:12, John Garry wrote:
>>>> On 21/03/2017 14:45, Lorenzo Pieralisi wrote:
>>>>> On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote:
>>>>>> From: Hanjun Guo <[email protected]>
>>>>>>
>>>>>> With the preparation of platform msi support and interrupt producer
>>>>>> in DSDT, we can add mbigen ACPI support now.
>>>>>>
>>>>>> We are using Interrupt resource type in _CRS methd to indicate
>>> number
>>>>>> of irq pins instead of num_pins in DT to avoid _DSD usage in this
>>> case.
>>>>>>
>>>>>> For mbigen,
>>>>>> Device(MBI0) {
>>>>>> Name(_HID, "HISI0152")
>>>>>> Name(_UID, Zero)
>>>>>> Name(_CRS, ResourceTemplate() {
>>>>>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>>>>>> Interrupt(ResourceProducer,...) {12,14,....}
>>>>>
>>>>> What do these interrupt numbers represent ? This looks wrong to me.
>>>>> An interrupt descriptor is there to describe the interrupts a device
>>>>> can generate; you are using it just to add a "standard" (that is
>>>>> not standard at all) way of counting the number of vectors allocated
>>>>> to this specific chip and that's just wrong.
>>>>>
>>>>
>>>> As I understand, the count of interrupts we are declaring for the
>>> mbigen
>>>> is the same as the sum of interrupts for that mbigen's children.
>>>>
>>>> So at the point we probe the mbigen, can we just deference the
>>> children
>>>> to count their interrupts, and use this as the #msis?
>>>>
>>>>> Can't you use something like Agustin did in the QCOM combiner:
>>>>>
>>>>> drivers/irqchip/qcom-irq-combiner.c
>>>>>
>>>>> to detect the MSI vector length (ie by describing the MBIgen through
>>>>> generic registers and use the bit width to compute the vector
>>>>> lenght) ? I am not sure how feasible it is given that my knowledge
>>>>> of MBIgen is pretty poor.
>>>>>
>>>>> I understand we want to avoid _DSD properties but we should not
>>>>> work around standard bindings to achieve that goal.
>>>>>
>>>>
>>>> We use "num-pins" for dt solution, but it is not so welcome here.
>>>
>>> Well, this device is already completely out of any standard description
>>> on the ACPI side. And given that it bloats both the ACPI tables and the
>>> kernel data structures, I can only suggest that you take advantage of
>>> _DSD here, as misusing the standard properties is not something that we
>>> should condone. It will also make the driver more manageable, as it
>>> will
>>> use similar properties on both firmware implementations.
>>>
>>> I feel like I need to stress the urgency here. We're at -rc4, and still
>>> with unsolved issues. None of us want to miss the next merge window.
>>>
>>
>> As follow up our guys would work on a solution whose ACPI table looks
>> like the following one:
>>
>> For mbigen,
>> Device(MBI0) {
>> Name(_HID, "HISI0152")
>> Name(_UID, Zero)
>> Name(_CRS, ResourceTemplate() {
>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>> })
>>
>> Name(_DSD, Package () {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package ()
>> {
>> Package () {"num-pins", xxx}
>> }
>> })
>> }
Please fix the indentation here; the ASL parser doesn't care, but I don't
see '}'s as clearly as it does :). In particular, _DSD usage *must* be for
a device and it does not look like that if one doesn't carefully count all
the parentheses and braces.
>>
>> For devices,
>> Device(COM0) {
>> Name(_HID, "ACPIIDxx")
>> Name(_UID, Zero)
>> Name(_CRS, ResourceTemplate() {
>> Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
>> Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
>> })
>> }
>>
>>
>> Marc, Lorenzo if you are ok with the above we will submit v10 based on this...
>
> I am ok with it. I am not 100% up-to-date on what's the status on _DSD
> bindings/review/guidelines but it would be certainly a good idea to
> kickstart the process for MBIgen which basically means following this
> as far as I know (and post to the relevant mailing list):
>
> https://github.com/ahs3/dsd/blob/master/documentation/process_rules.txt
So, let's correct this bit: consider that URL deprecated, please, and refer
instead to the text that was agreed upon and in the kernel tree:
Documentation/acpi/DSD-properties-rules.txt
> Al and Darren may add to that as they have more insights.
Since this use of _DSD is very specific to this device, and this device
only, I don't have any real objections. I will say that "num-pins" is
not terribly descriptive so it would be really good to either use a much
more descriptive name or add plenty of commentary in the code -- and
preferably both. I would recommend including the ASL in the code comments,
with a description of how the property is to be used and what it means.
> I would like to send IORT patches to Catalin as soon as possible so
> as Marc pointed out the sooner we sort this out the better.
>
> Thanks,
> Lorenzo
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
[email protected]
-----------------------------------
Hi Al,
Thanks for your feedback, reply inline.
On 03/28/2017 02:56 AM, Al Stone wrote:
> On 03/27/2017 09:27 AM, Lorenzo Pieralisi wrote:
>> [+Al,Darren to comment on _DSD review process]
>>
>> On Mon, Mar 27, 2017 at 12:24:45PM +0000, Gabriele Paoloni wrote:
>>> Hi Marc Many thanks for your comments
>>>> Hanjun, John,
>>>>
>>>> On 22/03/17 14:12, John Garry wrote:
>>>>> On 21/03/2017 14:45, Lorenzo Pieralisi wrote:
>>>>>> On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote:
>>>>>>> From: Hanjun Guo <[email protected]>
>>>>>>>
>>>>>>> With the preparation of platform msi support and interrupt producer
>>>>>>> in DSDT, we can add mbigen ACPI support now.
>>>>>>>
>>>>>>> We are using Interrupt resource type in _CRS methd to indicate
>>>> number
>>>>>>> of irq pins instead of num_pins in DT to avoid _DSD usage in this
>>>> case.
>>>>>>>
>>>>>>> For mbigen,
>>>>>>> Device(MBI0) {
>>>>>>> Name(_HID, "HISI0152")
>>>>>>> Name(_UID, Zero)
>>>>>>> Name(_CRS, ResourceTemplate() {
>>>>>>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>>>>>>> Interrupt(ResourceProducer,...) {12,14,....}
>>>>>>
>>>>>> What do these interrupt numbers represent ? This looks wrong to me.
>>>>>> An interrupt descriptor is there to describe the interrupts a device
>>>>>> can generate; you are using it just to add a "standard" (that is
>>>>>> not standard at all) way of counting the number of vectors allocated
>>>>>> to this specific chip and that's just wrong.
>>>>>>
>>>>>
>>>>> As I understand, the count of interrupts we are declaring for the
>>>> mbigen
>>>>> is the same as the sum of interrupts for that mbigen's children.
>>>>>
>>>>> So at the point we probe the mbigen, can we just deference the
>>>> children
>>>>> to count their interrupts, and use this as the #msis?
>>>>>
>>>>>> Can't you use something like Agustin did in the QCOM combiner:
>>>>>>
>>>>>> drivers/irqchip/qcom-irq-combiner.c
>>>>>>
>>>>>> to detect the MSI vector length (ie by describing the MBIgen through
>>>>>> generic registers and use the bit width to compute the vector
>>>>>> lenght) ? I am not sure how feasible it is given that my knowledge
>>>>>> of MBIgen is pretty poor.
>>>>>>
>>>>>> I understand we want to avoid _DSD properties but we should not
>>>>>> work around standard bindings to achieve that goal.
>>>>>>
>>>>>
>>>>> We use "num-pins" for dt solution, but it is not so welcome here.
>>>>
>>>> Well, this device is already completely out of any standard description
>>>> on the ACPI side. And given that it bloats both the ACPI tables and the
>>>> kernel data structures, I can only suggest that you take advantage of
>>>> _DSD here, as misusing the standard properties is not something that we
>>>> should condone. It will also make the driver more manageable, as it
>>>> will
>>>> use similar properties on both firmware implementations.
>>>>
>>>> I feel like I need to stress the urgency here. We're at -rc4, and still
>>>> with unsolved issues. None of us want to miss the next merge window.
>>>>
>>>
>>> As follow up our guys would work on a solution whose ACPI table looks
>>> like the following one:
>>>
>>> For mbigen,
>>> Device(MBI0) {
>>> Name(_HID, "HISI0152")
>>> Name(_UID, Zero)
>>> Name(_CRS, ResourceTemplate() {
>>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>>> })
>>>
>>> Name(_DSD, Package () {
>>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>> Package ()
>>> {
>>> Package () {"num-pins", xxx}
>>> }
>>> })
>>> }
>
> Please fix the indentation here; the ASL parser doesn't care, but I don't
> see '}'s as clearly as it does :). In particular, _DSD usage *must* be for
> a device and it does not look like that if one doesn't carefully count all
> the parentheses and braces.
I will fix it :)
>
>>>
>>> For devices,
>>> Device(COM0) {
>>> Name(_HID, "ACPIIDxx")
>>> Name(_UID, Zero)
>>> Name(_CRS, ResourceTemplate() {
>>> Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
>>> Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
>>> })
>>> }
>>>
>>>
>>> Marc, Lorenzo if you are ok with the above we will submit v10 based on this...
>>
>> I am ok with it. I am not 100% up-to-date on what's the status on _DSD
>> bindings/review/guidelines but it would be certainly a good idea to
>> kickstart the process for MBIgen which basically means following this
>> as far as I know (and post to the relevant mailing list):
>>
>> https://github.com/ahs3/dsd/blob/master/documentation/process_rules.txt
>
> So, let's correct this bit: consider that URL deprecated, please, and refer
> instead to the text that was agreed upon and in the kernel tree:
>
> Documentation/acpi/DSD-properties-rules.txt
>
>> Al and Darren may add to that as they have more insights.
>
> Since this use of _DSD is very specific to this device, and this device
> only, I don't have any real objections.
Thanks for the confirmation.
> I will say that "num-pins" is
> not terribly descriptive so it would be really good to either use a much
> more descriptive name or add plenty of commentary in the code -- and
> preferably both. I would recommend including the ASL in the code comments,
> with a description of how the property is to be used and what it means.
"num-pins" is used for mbigen DT support:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
I think we can use the name unchanged and adding more comments
as you suggested, will cc you for this updated patch.
Thanks
Hanjun
Hi Hanjun, Marc,
On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <[email protected]>
>
> For devices connecting to ITS, the devices need to identify themself
> through a dev id; this dev id is represented in the IORT table in named
> component node [1] for platform devices, so this patch adds code that
> scans the IORT table to retrieve the devices' dev id.
>
> Leveraging the iort_node_map_platform_id() IORT API, add a new function
> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
> retrieving dev id in ACPI platforms.
>
> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>
> Signed-off-by: Hanjun Guo <[email protected]>
> [[email protected]: rewrote commit log]
> Signed-off-by: Lorenzo Pieralisi <[email protected]>
> Tested-by: Ming Lei <[email protected]>
> Tested-by: Wei Xu <[email protected]>
> Tested-by: Sinan Kaya <[email protected]>
> Cc: Marc Zyngier <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
> Cc: Tomasz Nowicki <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> ---
> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
> include/linux/acpi_iort.h | 5 +++++
> 3 files changed, 31 insertions(+), 1 deletion(-)
To simplify merging ACPI/IRQCHIP changes via different trees it
would be good to split this patch; I am not sure what's the best
way of handling it though given that we would end up in a merge
ordering dependency anyway (ie we can create an empty stub
for iort_pmsi_get_dev_id() but that would create a dependency
between ARM64 and irqchip trees anyway).
Please let me know what's your preferred way of handling this.
Thanks,
Lorenzo
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 83cd59d..fb95ceb 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> }
>
> /**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, -ENODEV on error
> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + int i;
> + struct acpi_iort_node *node;
> +
> + node = iort_find_dev_node(dev);
> + if (!node)
> + return -ENODEV;
> +
> + for (i = 0; i < node->mapping_count; i++) {
> + if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))
> + return 0;
> + }
> +
> + return -ENODEV;
> +}
> +
> +/**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> * @req_id: Device's requester ID
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index e4ba9f4..e801fc0 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -57,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>
> msi_info = msi_get_domain_info(domain->parent);
>
> - ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
> + iort_pmsi_get_dev_id(dev, &dev_id);
> if (ret)
> return ret;
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 77e0809..d074c77 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -34,6 +34,7 @@
> bool iort_node_match(u8 type);
> u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> @@ -45,6 +46,10 @@ static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> u32 req_id)
> { return NULL; }
> +
> +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{ return -ENODEV; }
> +
> /* IOMMU interface */
> static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> --
> 1.7.12.4
>
Hi Lorenzo,
On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
> Hi Hanjun, Marc,
>
> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
>> From: Hanjun Guo <[email protected]>
>>
>> For devices connecting to ITS, the devices need to identify themself
>> through a dev id; this dev id is represented in the IORT table in named
>> component node [1] for platform devices, so this patch adds code that
>> scans the IORT table to retrieve the devices' dev id.
>>
>> Leveraging the iort_node_map_platform_id() IORT API, add a new function
>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
>> retrieving dev id in ACPI platforms.
>>
>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>>
>> Signed-off-by: Hanjun Guo <[email protected]>
>> [[email protected]: rewrote commit log]
>> Signed-off-by: Lorenzo Pieralisi <[email protected]>
>> Tested-by: Ming Lei <[email protected]>
>> Tested-by: Wei Xu <[email protected]>
>> Tested-by: Sinan Kaya <[email protected]>
>> Cc: Marc Zyngier <[email protected]>
>> Cc: Lorenzo Pieralisi <[email protected]>
>> Cc: Tomasz Nowicki <[email protected]>
>> Cc: Thomas Gleixner <[email protected]>
>> ---
>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
>> include/linux/acpi_iort.h | 5 +++++
>> 3 files changed, 31 insertions(+), 1 deletion(-)
>
> To simplify merging ACPI/IRQCHIP changes via different trees it
> would be good to split this patch; I am not sure what's the best
> way of handling it though given that we would end up in a merge
> ordering dependency anyway (ie we can create an empty stub
> for iort_pmsi_get_dev_id() but that would create a dependency
> between ARM64 and irqchip trees anyway).
The first 12 patches for ACPI platform MSI and later 3 patches
for mbigen have no "physical" dependency, which means they can
be merged and compiled independently, they only have functional
dependency only.
We already had SAS, XGE, USB and even UART drivers depend on
the mbigen ACPI support, so I don't think the dependency of ACPI
platform MSI and mbigen patches cares much if those two parts are
merged in one merge window, even they are merged independently via
different tree.
>
> Please let me know what's your preferred way of handling this.
So in my opinion, they can be merged independently via ARM64 and
irqchip tree with no ordering dependency, is it OK?
Thanks
Hanjun
On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
> >Hi Hanjun, Marc,
> >
> >On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> >>From: Hanjun Guo <[email protected]>
> >>
> >>For devices connecting to ITS, the devices need to identify themself
> >>through a dev id; this dev id is represented in the IORT table in named
> >>component node [1] for platform devices, so this patch adds code that
> >>scans the IORT table to retrieve the devices' dev id.
> >>
> >>Leveraging the iort_node_map_platform_id() IORT API, add a new function
> >>call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
> >>retrieving dev id in ACPI platforms.
> >>
> >>[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
> >>
> >>Signed-off-by: Hanjun Guo <[email protected]>
> >>[[email protected]: rewrote commit log]
> >>Signed-off-by: Lorenzo Pieralisi <[email protected]>
> >>Tested-by: Ming Lei <[email protected]>
> >>Tested-by: Wei Xu <[email protected]>
> >>Tested-by: Sinan Kaya <[email protected]>
> >>Cc: Marc Zyngier <[email protected]>
> >>Cc: Lorenzo Pieralisi <[email protected]>
> >>Cc: Tomasz Nowicki <[email protected]>
> >>Cc: Thomas Gleixner <[email protected]>
> >>---
> >> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
> >> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
> >> include/linux/acpi_iort.h | 5 +++++
> >> 3 files changed, 31 insertions(+), 1 deletion(-)
> >
> >To simplify merging ACPI/IRQCHIP changes via different trees it
> >would be good to split this patch; I am not sure what's the best
> >way of handling it though given that we would end up in a merge
> >ordering dependency anyway (ie we can create an empty stub
> >for iort_pmsi_get_dev_id() but that would create a dependency
> >between ARM64 and irqchip trees anyway).
>
> The first 12 patches for ACPI platform MSI and later 3 patches
> for mbigen have no "physical" dependency, which means they can
> be merged and compiled independently, they only have functional
> dependency only.
>
> We already had SAS, XGE, USB and even UART drivers depend on
> the mbigen ACPI support, so I don't think the dependency of ACPI
> platform MSI and mbigen patches cares much if those two parts are
> merged in one merge window, even they are merged independently via
> different tree.
>
> >
> >Please let me know what's your preferred way of handling this.
>
> So in my opinion, they can be merged independently via ARM64 and
> irqchip tree with no ordering dependency, is it OK?
I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
ACPI/IORT for ARM64, that's why I replied to this patch. I do not
think that's feasible to split patches in two separate branches
without having a dependency between them.
Sure, the last three patches can go via IRQCHIP but that was not
my question :)
Lorenzo
On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
>> Hi Lorenzo,
>>
>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
>>> Hi Hanjun, Marc,
>>>
>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
>>>> From: Hanjun Guo <[email protected]>
>>>>
>>>> For devices connecting to ITS, the devices need to identify themself
>>>> through a dev id; this dev id is represented in the IORT table in named
>>>> component node [1] for platform devices, so this patch adds code that
>>>> scans the IORT table to retrieve the devices' dev id.
>>>>
>>>> Leveraging the iort_node_map_platform_id() IORT API, add a new function
>>>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
>>>> retrieving dev id in ACPI platforms.
>>>>
>>>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>>>>
>>>> Signed-off-by: Hanjun Guo <[email protected]>
>>>> [[email protected]: rewrote commit log]
>>>> Signed-off-by: Lorenzo Pieralisi <[email protected]>
>>>> Tested-by: Ming Lei <[email protected]>
>>>> Tested-by: Wei Xu <[email protected]>
>>>> Tested-by: Sinan Kaya <[email protected]>
>>>> Cc: Marc Zyngier <[email protected]>
>>>> Cc: Lorenzo Pieralisi <[email protected]>
>>>> Cc: Tomasz Nowicki <[email protected]>
>>>> Cc: Thomas Gleixner <[email protected]>
>>>> ---
>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
>>>> include/linux/acpi_iort.h | 5 +++++
>>>> 3 files changed, 31 insertions(+), 1 deletion(-)
>>>
>>> To simplify merging ACPI/IRQCHIP changes via different trees it
>>> would be good to split this patch; I am not sure what's the best
>>> way of handling it though given that we would end up in a merge
>>> ordering dependency anyway (ie we can create an empty stub
>>> for iort_pmsi_get_dev_id() but that would create a dependency
>>> between ARM64 and irqchip trees anyway).
>>
>> The first 12 patches for ACPI platform MSI and later 3 patches
>> for mbigen have no "physical" dependency, which means they can
>> be merged and compiled independently, they only have functional
>> dependency only.
>>
>> We already had SAS, XGE, USB and even UART drivers depend on
>> the mbigen ACPI support, so I don't think the dependency of ACPI
>> platform MSI and mbigen patches cares much if those two parts are
>> merged in one merge window, even they are merged independently via
>> different tree.
>>
>>>
>>> Please let me know what's your preferred way of handling this.
>>
>> So in my opinion, they can be merged independently via ARM64 and
>> irqchip tree with no ordering dependency, is it OK?
>
> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
> ACPI/IORT for ARM64, that's why I replied to this patch. I do not
> think that's feasible to split patches in two separate branches
> without having a dependency between them.
>
> Sure, the last three patches can go via IRQCHIP but that was not
> my question :)
Sorry, I misunderstood that :(
Since it's not feasible to split patches, the best way I got is that
we get Marc's ack then merge it.
Marc, Lorenzo, is this OK?
Thanks
Hanjun
On 29/03/17 14:00, Hanjun Guo wrote:
> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
>>> Hi Lorenzo,
>>>
>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
>>>> Hi Hanjun, Marc,
>>>>
>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
>>>>> From: Hanjun Guo <[email protected]>
>>>>>
>>>>> For devices connecting to ITS, the devices need to identify themself
>>>>> through a dev id; this dev id is represented in the IORT table in named
>>>>> component node [1] for platform devices, so this patch adds code that
>>>>> scans the IORT table to retrieve the devices' dev id.
>>>>>
>>>>> Leveraging the iort_node_map_platform_id() IORT API, add a new function
>>>>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
>>>>> retrieving dev id in ACPI platforms.
>>>>>
>>>>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>>>>>
>>>>> Signed-off-by: Hanjun Guo <[email protected]>
>>>>> [[email protected]: rewrote commit log]
>>>>> Signed-off-by: Lorenzo Pieralisi <[email protected]>
>>>>> Tested-by: Ming Lei <[email protected]>
>>>>> Tested-by: Wei Xu <[email protected]>
>>>>> Tested-by: Sinan Kaya <[email protected]>
>>>>> Cc: Marc Zyngier <[email protected]>
>>>>> Cc: Lorenzo Pieralisi <[email protected]>
>>>>> Cc: Tomasz Nowicki <[email protected]>
>>>>> Cc: Thomas Gleixner <[email protected]>
>>>>> ---
>>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
>>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
>>>>> include/linux/acpi_iort.h | 5 +++++
>>>>> 3 files changed, 31 insertions(+), 1 deletion(-)
>>>>
>>>> To simplify merging ACPI/IRQCHIP changes via different trees it
>>>> would be good to split this patch; I am not sure what's the best
>>>> way of handling it though given that we would end up in a merge
>>>> ordering dependency anyway (ie we can create an empty stub
>>>> for iort_pmsi_get_dev_id() but that would create a dependency
>>>> between ARM64 and irqchip trees anyway).
>>>
>>> The first 12 patches for ACPI platform MSI and later 3 patches
>>> for mbigen have no "physical" dependency, which means they can
>>> be merged and compiled independently, they only have functional
>>> dependency only.
>>>
>>> We already had SAS, XGE, USB and even UART drivers depend on
>>> the mbigen ACPI support, so I don't think the dependency of ACPI
>>> platform MSI and mbigen patches cares much if those two parts are
>>> merged in one merge window, even they are merged independently via
>>> different tree.
>>>
>>>>
>>>> Please let me know what's your preferred way of handling this.
>>>
>>> So in my opinion, they can be merged independently via ARM64 and
>>> irqchip tree with no ordering dependency, is it OK?
>>
>> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
>> ACPI/IORT for ARM64, that's why I replied to this patch. I do not
>> think that's feasible to split patches in two separate branches
>> without having a dependency between them.
>>
>> Sure, the last three patches can go via IRQCHIP but that was not
>> my question :)
>
> Sorry, I misunderstood that :(
>
> Since it's not feasible to split patches, the best way I got is that
> we get Marc's ack then merge it.
I believe there is a way to make this work without too much hassle. I
suggest we drop the ITS change from this patch entirely, and I instead
queue this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
That way, no dependency between the two trees. Lorenzo takes all the
patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and
everything should be perfectly standalone.
Thoughts?
M.
--
Jazz is not dead. It just smells funny...
On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
> On 29/03/17 14:00, Hanjun Guo wrote:
> > On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
> >> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
> >>> Hi Lorenzo,
> >>>
> >>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
> >>>> Hi Hanjun, Marc,
> >>>>
> >>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> >>>>> From: Hanjun Guo <[email protected]>
> >>>>>
> >>>>> For devices connecting to ITS, the devices need to identify themself
> >>>>> through a dev id; this dev id is represented in the IORT table in named
> >>>>> component node [1] for platform devices, so this patch adds code that
> >>>>> scans the IORT table to retrieve the devices' dev id.
> >>>>>
> >>>>> Leveraging the iort_node_map_platform_id() IORT API, add a new function
> >>>>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
> >>>>> retrieving dev id in ACPI platforms.
> >>>>>
> >>>>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
> >>>>>
> >>>>> Signed-off-by: Hanjun Guo <[email protected]>
> >>>>> [[email protected]: rewrote commit log]
> >>>>> Signed-off-by: Lorenzo Pieralisi <[email protected]>
> >>>>> Tested-by: Ming Lei <[email protected]>
> >>>>> Tested-by: Wei Xu <[email protected]>
> >>>>> Tested-by: Sinan Kaya <[email protected]>
> >>>>> Cc: Marc Zyngier <[email protected]>
> >>>>> Cc: Lorenzo Pieralisi <[email protected]>
> >>>>> Cc: Tomasz Nowicki <[email protected]>
> >>>>> Cc: Thomas Gleixner <[email protected]>
> >>>>> ---
> >>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
> >>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
> >>>>> include/linux/acpi_iort.h | 5 +++++
> >>>>> 3 files changed, 31 insertions(+), 1 deletion(-)
> >>>>
> >>>> To simplify merging ACPI/IRQCHIP changes via different trees it
> >>>> would be good to split this patch; I am not sure what's the best
> >>>> way of handling it though given that we would end up in a merge
> >>>> ordering dependency anyway (ie we can create an empty stub
> >>>> for iort_pmsi_get_dev_id() but that would create a dependency
> >>>> between ARM64 and irqchip trees anyway).
> >>>
> >>> The first 12 patches for ACPI platform MSI and later 3 patches
> >>> for mbigen have no "physical" dependency, which means they can
> >>> be merged and compiled independently, they only have functional
> >>> dependency only.
> >>>
> >>> We already had SAS, XGE, USB and even UART drivers depend on
> >>> the mbigen ACPI support, so I don't think the dependency of ACPI
> >>> platform MSI and mbigen patches cares much if those two parts are
> >>> merged in one merge window, even they are merged independently via
> >>> different tree.
> >>>
> >>>>
> >>>> Please let me know what's your preferred way of handling this.
> >>>
> >>> So in my opinion, they can be merged independently via ARM64 and
> >>> irqchip tree with no ordering dependency, is it OK?
> >>
> >> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
> >> ACPI/IORT for ARM64, that's why I replied to this patch. I do not
> >> think that's feasible to split patches in two separate branches
> >> without having a dependency between them.
> >>
> >> Sure, the last three patches can go via IRQCHIP but that was not
> >> my question :)
> >
> > Sorry, I misunderstood that :(
> >
> > Since it's not feasible to split patches, the best way I got is that
> > we get Marc's ack then merge it.
>
> I believe there is a way to make this work without too much hassle. I
> suggest we drop the ITS change from this patch entirely, and I instead
> queue this patch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
>
> That way, no dependency between the two trees. Lorenzo takes all the
> patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and
> everything should be perfectly standalone.
>
> Thoughts?
Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
this patch and post the resulting branch for everyone to have a final
test.
Ok ?
Thanks !
Lorenzo
On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
> > On 29/03/17 14:00, Hanjun Guo wrote:
> > > On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
> > >> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
> > >>> Hi Lorenzo,
> > >>>
> > >>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
> > >>>> Hi Hanjun, Marc,
> > >>>>
> > >>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> > >>>>> From: Hanjun Guo <[email protected]>
> > >>>>>
> > >>>>> For devices connecting to ITS, the devices need to identify themself
> > >>>>> through a dev id; this dev id is represented in the IORT table in named
> > >>>>> component node [1] for platform devices, so this patch adds code that
> > >>>>> scans the IORT table to retrieve the devices' dev id.
> > >>>>>
> > >>>>> Leveraging the iort_node_map_platform_id() IORT API, add a new function
> > >>>>> call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
> > >>>>> retrieving dev id in ACPI platforms.
> > >>>>>
> > >>>>> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
> > >>>>>
> > >>>>> Signed-off-by: Hanjun Guo <[email protected]>
> > >>>>> [[email protected]: rewrote commit log]
> > >>>>> Signed-off-by: Lorenzo Pieralisi <[email protected]>
> > >>>>> Tested-by: Ming Lei <[email protected]>
> > >>>>> Tested-by: Wei Xu <[email protected]>
> > >>>>> Tested-by: Sinan Kaya <[email protected]>
> > >>>>> Cc: Marc Zyngier <[email protected]>
> > >>>>> Cc: Lorenzo Pieralisi <[email protected]>
> > >>>>> Cc: Tomasz Nowicki <[email protected]>
> > >>>>> Cc: Thomas Gleixner <[email protected]>
> > >>>>> ---
> > >>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
> > >>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
> > >>>>> include/linux/acpi_iort.h | 5 +++++
> > >>>>> 3 files changed, 31 insertions(+), 1 deletion(-)
> > >>>>
> > >>>> To simplify merging ACPI/IRQCHIP changes via different trees it
> > >>>> would be good to split this patch; I am not sure what's the best
> > >>>> way of handling it though given that we would end up in a merge
> > >>>> ordering dependency anyway (ie we can create an empty stub
> > >>>> for iort_pmsi_get_dev_id() but that would create a dependency
> > >>>> between ARM64 and irqchip trees anyway).
> > >>>
> > >>> The first 12 patches for ACPI platform MSI and later 3 patches
> > >>> for mbigen have no "physical" dependency, which means they can
> > >>> be merged and compiled independently, they only have functional
> > >>> dependency only.
> > >>>
> > >>> We already had SAS, XGE, USB and even UART drivers depend on
> > >>> the mbigen ACPI support, so I don't think the dependency of ACPI
> > >>> platform MSI and mbigen patches cares much if those two parts are
> > >>> merged in one merge window, even they are merged independently via
> > >>> different tree.
> > >>>
> > >>>>
> > >>>> Please let me know what's your preferred way of handling this.
> > >>>
> > >>> So in my opinion, they can be merged independently via ARM64 and
> > >>> irqchip tree with no ordering dependency, is it OK?
> > >>
> > >> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
> > >> ACPI/IORT for ARM64, that's why I replied to this patch. I do not
> > >> think that's feasible to split patches in two separate branches
> > >> without having a dependency between them.
> > >>
> > >> Sure, the last three patches can go via IRQCHIP but that was not
> > >> my question :)
> > >
> > > Sorry, I misunderstood that :(
> > >
> > > Since it's not feasible to split patches, the best way I got is that
> > > we get Marc's ack then merge it.
> >
> > I believe there is a way to make this work without too much hassle. I
> > suggest we drop the ITS change from this patch entirely, and I instead
> > queue this patch:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
> >
> > That way, no dependency between the two trees. Lorenzo takes all the
> > patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and
> > everything should be perfectly standalone.
> >
> > Thoughts?
>
> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
> this patch and post the resulting branch for everyone to have a final
> test.
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12
Please have a look and let me know if that's ok, I planned to send
a PR to Catalin by the end of the week (first 7 patches up to
7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
device")).
Lorenzo
On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:
> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
>>> On 29/03/17 14:00, Hanjun Guo wrote:
>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
>>>>>> Hi Lorenzo,
>>>>>>
>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
>>>>>>> Hi Hanjun, Marc,
>>>>>>>
>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
[...]
>>>>>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
>>>>>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
>>>>>>>> include/linux/acpi_iort.h | 5 +++++
>>>>>>>> 3 files changed, 31 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> To simplify merging ACPI/IRQCHIP changes via different trees it
>>>>>>> would be good to split this patch; I am not sure what's the best
>>>>>>> way of handling it though given that we would end up in a merge
>>>>>>> ordering dependency anyway (ie we can create an empty stub
>>>>>>> for iort_pmsi_get_dev_id() but that would create a dependency
>>>>>>> between ARM64 and irqchip trees anyway).
>>>>>>
>>>>>> The first 12 patches for ACPI platform MSI and later 3 patches
>>>>>> for mbigen have no "physical" dependency, which means they can
>>>>>> be merged and compiled independently, they only have functional
>>>>>> dependency only.
>>>>>>
>>>>>> We already had SAS, XGE, USB and even UART drivers depend on
>>>>>> the mbigen ACPI support, so I don't think the dependency of ACPI
>>>>>> platform MSI and mbigen patches cares much if those two parts are
>>>>>> merged in one merge window, even they are merged independently via
>>>>>> different tree.
>>>>>>
>>>>>>>
>>>>>>> Please let me know what's your preferred way of handling this.
>>>>>>
>>>>>> So in my opinion, they can be merged independently via ARM64 and
>>>>>> irqchip tree with no ordering dependency, is it OK?
>>>>>
>>>>> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
>>>>> ACPI/IORT for ARM64, that's why I replied to this patch. I do not
>>>>> think that's feasible to split patches in two separate branches
>>>>> without having a dependency between them.
>>>>>
>>>>> Sure, the last three patches can go via IRQCHIP but that was not
>>>>> my question :)
>>>>
>>>> Sorry, I misunderstood that :(
>>>>
>>>> Since it's not feasible to split patches, the best way I got is that
>>>> we get Marc's ack then merge it.
>>>
>>> I believe there is a way to make this work without too much hassle. I
>>> suggest we drop the ITS change from this patch entirely, and I instead
>>> queue this patch:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
>>>
>>> That way, no dependency between the two trees. Lorenzo takes all the
>>> patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and
>>> everything should be perfectly standalone.
>>>
>>> Thoughts?
>>
>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>> this patch and post the resulting branch for everyone to have a final
>> test.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12
>
> Please have a look and let me know if that's ok, I planned to send
> a PR to Catalin by the end of the week (first 7 patches up to
> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
> device")).
Perfect for me too, Lorenzo, Marc, Thank you very much.
I'm currently in paternity leave and can't reach the machine,
I had a detail review with the patches, they looks good to me,
Ma Jun and Wei Xu will test on Hisilicon machines and give the
feedback.
Thanks
Hanjun
Hi all:
在 2017/3/30 11:07, Hanjun Guo 写道:
> On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:
>> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
>>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
>>>> On 29/03/17 14:00, Hanjun Guo wrote:
>>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
>>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
>>>>>>> Hi Lorenzo,
>>>>>>>
>>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
>>>>>>>> Hi Hanjun, Marc,
>>>>>>>>
>>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> [...]
>>>>>>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
>>>>>>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
[...]
>>>>
>>>> Thoughts?
>>>
>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>> this patch and post the resulting branch for everyone to have a final
>>> test.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12
>>
>> Please have a look and let me know if that's ok, I planned to send
>> a PR to Catalin by the end of the week (first 7 patches up to
>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
>> device")).
>
> Perfect for me too, Lorenzo, Marc, Thank you very much.
>
> I'm currently in paternity leave and can't reach the machine,
> I had a detail review with the patches, they looks good to me,
> Ma Jun and Wei Xu will test on Hisilicon machines and give the
> feedback.
The sas/xge/uart are working fine on my hisilicon board with
Lorenzo's branch (arm64-acpi-4.12)
Thanks
Majun
>
> Thanks
> Hanjun
>
> .
>
Hi All,
On 2017/3/30 4:07, Hanjun Guo wrote:
> On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:
>> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
>>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
>>>> On 29/03/17 14:00, Hanjun Guo wrote:
>>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
>>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
>>>>>>> Hi Lorenzo,
>>>>>>>
>>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
>>>>>>>> Hi Hanjun, Marc,
>>>>>>>>
>>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> [...]
>>>>>>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
>>>>>>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
>>>>>>>>> include/linux/acpi_iort.h | 5 +++++
>>>>>>>>> 3 files changed, 31 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> To simplify merging ACPI/IRQCHIP changes via different trees it
>>>>>>>> would be good to split this patch; I am not sure what's the best
>>>>>>>> way of handling it though given that we would end up in a merge
>>>>>>>> ordering dependency anyway (ie we can create an empty stub
>>>>>>>> for iort_pmsi_get_dev_id() but that would create a dependency
>>>>>>>> between ARM64 and irqchip trees anyway).
>>>>>>>
>>>>>>> The first 12 patches for ACPI platform MSI and later 3 patches
>>>>>>> for mbigen have no "physical" dependency, which means they can
>>>>>>> be merged and compiled independently, they only have functional
>>>>>>> dependency only.
>>>>>>>
>>>>>>> We already had SAS, XGE, USB and even UART drivers depend on
>>>>>>> the mbigen ACPI support, so I don't think the dependency of ACPI
>>>>>>> platform MSI and mbigen patches cares much if those two parts are
>>>>>>> merged in one merge window, even they are merged independently via
>>>>>>> different tree.
>>>>>>>
>>>>>>>>
>>>>>>>> Please let me know what's your preferred way of handling this.
>>>>>>>
>>>>>>> So in my opinion, they can be merged independently via ARM64 and
>>>>>>> irqchip tree with no ordering dependency, is it OK?
>>>>>>
>>>>>> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
>>>>>> ACPI/IORT for ARM64, that's why I replied to this patch. I do not
>>>>>> think that's feasible to split patches in two separate branches
>>>>>> without having a dependency between them.
>>>>>>
>>>>>> Sure, the last three patches can go via IRQCHIP but that was not
>>>>>> my question :)
>>>>>
>>>>> Sorry, I misunderstood that :(
>>>>>
>>>>> Since it's not feasible to split patches, the best way I got is that
>>>>> we get Marc's ack then merge it.
>>>>
>>>> I believe there is a way to make this work without too much hassle. I
>>>> suggest we drop the ITS change from this patch entirely, and I instead
>>>> queue this patch:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
>>>>
>>>> That way, no dependency between the two trees. Lorenzo takes all the
>>>> patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and
>>>> everything should be perfectly standalone.
>>>>
>>>> Thoughts?
>>>
>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>> this patch and post the resulting branch for everyone to have a final
>>> test.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12
>>
>> Please have a look and let me know if that's ok, I planned to send
>> a PR to Catalin by the end of the week (first 7 patches up to
>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
>> device")).
>
> Perfect for me too, Lorenzo, Marc, Thank you very much.
>
> I'm currently in paternity leave and can't reach the machine,
> I had a detail review with the patches, they looks good to me,
> Ma Jun and Wei Xu will test on Hisilicon machines and give the
> feedback.
Thanks to all of you!
Tested on D05 board with this branch, the SAS disks and XGE port are working fine.
The log is as below:
estuary:/$ dmesg
[ 0.000000] Booting Linux on physical CPU 0x10000
[ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017
[ 0.000000] Boot CPU: AArch64 Processor [410fd082]
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.60 by EDK II
[ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098
[ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000
estuary:/$ ping 192.168.1.107
PING 192.168.1.107 (192.168.1.107): 56 data bytes
64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms
64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms
64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms
64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms
^C
--- 192.168.1.107 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.098/0.144/0.273 ms
estuary:/$ lspci -mk
30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
estuary:/$ cat /dev/sd
sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl
sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1
Best Regards,
Wei
>
> Thanks
> Hanjun
>
> .
>
On Thu, Mar 30, 2017 at 09:32:57AM +0100, Wei Xu wrote:
> Hi All,
>
> On 2017/3/30 4:07, Hanjun Guo wrote:
> > On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:
> >> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
> >>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
> >>>> On 29/03/17 14:00, Hanjun Guo wrote:
> >>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
> >>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
> >>>>>>> Hi Lorenzo,
> >>>>>>>
> >>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
> >>>>>>>> Hi Hanjun, Marc,
> >>>>>>>>
> >>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> > [...]
> >>>>>>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
> >>>>>>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
> >>>>>>>>> include/linux/acpi_iort.h | 5 +++++
> >>>>>>>>> 3 files changed, 31 insertions(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> To simplify merging ACPI/IRQCHIP changes via different trees it
> >>>>>>>> would be good to split this patch; I am not sure what's the best
> >>>>>>>> way of handling it though given that we would end up in a merge
> >>>>>>>> ordering dependency anyway (ie we can create an empty stub
> >>>>>>>> for iort_pmsi_get_dev_id() but that would create a dependency
> >>>>>>>> between ARM64 and irqchip trees anyway).
> >>>>>>>
> >>>>>>> The first 12 patches for ACPI platform MSI and later 3 patches
> >>>>>>> for mbigen have no "physical" dependency, which means they can
> >>>>>>> be merged and compiled independently, they only have functional
> >>>>>>> dependency only.
> >>>>>>>
> >>>>>>> We already had SAS, XGE, USB and even UART drivers depend on
> >>>>>>> the mbigen ACPI support, so I don't think the dependency of ACPI
> >>>>>>> platform MSI and mbigen patches cares much if those two parts are
> >>>>>>> merged in one merge window, even they are merged independently via
> >>>>>>> different tree.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Please let me know what's your preferred way of handling this.
> >>>>>>>
> >>>>>>> So in my opinion, they can be merged independently via ARM64 and
> >>>>>>> irqchip tree with no ordering dependency, is it OK?
> >>>>>>
> >>>>>> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
> >>>>>> ACPI/IORT for ARM64, that's why I replied to this patch. I do not
> >>>>>> think that's feasible to split patches in two separate branches
> >>>>>> without having a dependency between them.
> >>>>>>
> >>>>>> Sure, the last three patches can go via IRQCHIP but that was not
> >>>>>> my question :)
> >>>>>
> >>>>> Sorry, I misunderstood that :(
> >>>>>
> >>>>> Since it's not feasible to split patches, the best way I got is that
> >>>>> we get Marc's ack then merge it.
> >>>>
> >>>> I believe there is a way to make this work without too much hassle. I
> >>>> suggest we drop the ITS change from this patch entirely, and I instead
> >>>> queue this patch:
> >>>>
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
> >>>>
> >>>> That way, no dependency between the two trees. Lorenzo takes all the
> >>>> patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and
> >>>> everything should be perfectly standalone.
> >>>>
> >>>> Thoughts?
> >>>
> >>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
> >>> this patch and post the resulting branch for everyone to have a final
> >>> test.
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12
> >>
> >> Please have a look and let me know if that's ok, I planned to send
> >> a PR to Catalin by the end of the week (first 7 patches up to
> >> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
> >> device")).
> >
> > Perfect for me too, Lorenzo, Marc, Thank you very much.
> >
> > I'm currently in paternity leave and can't reach the machine,
> > I had a detail review with the patches, they looks good to me,
> > Ma Jun and Wei Xu will test on Hisilicon machines and give the
> > feedback.
>
> Thanks to all of you!
> Tested on D05 board with this branch, the SAS disks and XGE port are working fine.
Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull
request to Catalin tomorrow, please carry out last few checks before
I send it:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12
You should try to merge it with Marc's branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12
and test the resulting branch, that's how they will go upstream.
Please let me know, thank you for your help !
Lorenzo
> The log is as below:
>
> estuary:/$ dmesg
> [ 0.000000] Booting Linux on physical CPU 0x10000
> [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017
> [ 0.000000] Boot CPU: AArch64 Processor [410fd082]
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: EFI v2.60 by EDK II
> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098
> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000
>
>
> estuary:/$ ping 192.168.1.107
> PING 192.168.1.107 (192.168.1.107): 56 data bytes
> 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms
> 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms
> 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms
> 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms
> ^C
> --- 192.168.1.107 ping statistics ---
> 4 packets transmitted, 4 packets received, 0% packet loss
> round-trip min/avg/max = 0.098/0.144/0.273 ms
>
> estuary:/$ lspci -mk
> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>
> estuary:/$ cat /dev/sd
> sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl
> sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1
>
> Best Regards,
> Wei
>
> >
> > Thanks
> > Hanjun
> >
> > .
> >
>
>>>>>
>>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>>>> this patch and post the resulting branch for everyone to have a final
>>>>> test.
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12
>>>>
>>>> Please have a look and let me know if that's ok, I planned to send
>>>> a PR to Catalin by the end of the week (first 7 patches up to
>>>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
>>>> device")).
>>>
>>> Perfect for me too, Lorenzo, Marc, Thank you very much.
>>>
>>> I'm currently in paternity leave and can't reach the machine,
>>> I had a detail review with the patches, they looks good to me,
>>> Ma Jun and Wei Xu will test on Hisilicon machines and give the
>>> feedback.
>>
>> Thanks to all of you!
>> Tested on D05 board with this branch, the SAS disks and XGE port are working fine.
>
> Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull
> request to Catalin tomorrow, please carry out last few checks before
> I send it:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12
>
> You should try to merge it with Marc's branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12
>
> and test the resulting branch, that's how they will go upstream.
>
> Please let me know, thank you for your help !
>
Hi Lorenzo,
xuwei is away now, and it is night time with majun, so I tested. majun
can retest tomorrow again to triple-check. I did not touch the ITS patch
Marc made which had the weak version of iort_pmis_get_dev_id(), but it
should not affect anything in my test.
After merging your tag to Marc's branch, here is the git log:
git log --oneline
8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12
d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
ae7c183 ACPI: platform-msi: retrieve devid from IORT
e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
d11349c irqchip: mbigen: Add ACPI support
aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
964bac1 irqchip: mbigen: drop module owner
b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform
msi domain
baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to
prepare for ACPI
fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
cc9eb0d irqchip: gic-v3-its: keep the include header files in alphabetic
order
ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
3382357 dt-bindings: mediatek: multiple bases support for sysirq
4015616 irqchip: replace moxa with ftintc010
532278c irqchip: faraday: fix the trigger types
923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
c02ed2e Linux 4.11-rc4
And some testing:
dmesg snippet:
[ 0.000000] Booting Linux on physical CPU 0x10000
[ 0.000000] Linux version 4.11.0-rc4-00420-g8b6f3f8
(johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 4.8.5 (Linaro GCC
4.8-2015.06) ) #4 SMP PREEMPT Thu Mar 30 16:40:36 BST 2017
[ 0.000000] Boot CPU: AArch64 Processor [410fd082]
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.60 by EDK II
[ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000
ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3cc86018
[ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x0000000039BC0014 000024 (v02 HISI )
[ 0.000000] ACPI: XSDT 0x0000000039BB00E8 00006C (v01 HISI HIP07
00000000 01000013)
[ 0.000000] ACPI: FACP 0x0000000039A80000 00010C (v05 HISI HIP07
00000000 INTL 20151124)
[ 0.000000] ACPI: DSDT 0x0000000039A40000 0074E2 (v02 HISI HIP07
00000000 INTL 20151218)
[ 0.000000] ACPI: MCFG 0x0000000039AD0000 0000AC (v01 HISI HIP07
00000000 INTL 20151124)
[ 0.000000] ACPI: SLIT 0x0000000039AC0000 00003C (v01 HISI HIP07
00000000 INTL 20151124)
[ 0.000000] ACPI: SPCR 0x0000000039AB0000 000050 (v02 HISI HIP07
00000000 INTL 20151124)
[ 0.000000] ACPI: SRAT 0x0000000039AA0000 000500 (v03 HISI HIP07
00000000 INTL 20151124)
[ 0.000000] ACPI: GTDT 0x0000000039A70000 000098 (v02 HISI HIP07
00000000 INTL 20151124)
[ 0.000000] ACPI: APIC 0x0000000039A60000 0013E4 (v01 HISI HIP07
00000000 INTL 20151124)
[ 0.000000] ACPI: IORT 0x0000000039A50000 000514 (v00 HISI HIP07
00000000 INTL 20151218)
[ 0.000000] ACPI: iBFT 0x0000000031870000 000800 (v01 HISI HIP07
00000000 00000000)
PCI:
root@(none)$ lspci -mk
30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
Integrated NIC:
root@(none)$ ifconfig eth1 172.18.45.80 up
root@(none)$ [ 345.449591] hns-nic HISI00C2:01 eth1: link up
root@(none)$ ping 172.18.45.23
PING 172.18.45.23 (172.18.45.23): 56 data bytes
64 bytes from 172.18.45.23: seq=0 ttl=64 time=2026.837 ms
64 bytes from 172.18.45.23: seq=1 ttl=64 time=1026.843 ms
64 bytes from 172.18.45.23: seq=2 ttl=64 time=26.834 ms
64 bytes from 172.18.45.23: seq=3 ttl=64 time=0.075 ms
64 bytes from 172.18.45.23: seq=4 ttl=64 time=0.079 ms
^C
--- 172.18.45.23 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.075/616.133/2026.837 ms
Integrated Storage controller:
root@(none)$ fdisk -l
Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdb9f5cd0
Device Boot Start End Blocks Id System
/dev/sdb1 2048 209717247 104857600 83 Linux
/dev/sdb2 209717248 419432447 104857600 83 Linux
Disk /dev/sda: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes
Disk /dev/sdc: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes
Disk /dev/sdd: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes
Disk /dev/sde: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes
Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 131072 bytes
root@(none)$
Looks ok
@majun, please test as well.
Thanks,
John
> Lorenzo
>
>> The log is as below:
>>
>> estuary:/$ dmesg
>> [ 0.000000] Booting Linux on physical CPU 0x10000
>> [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017
>> [ 0.000000] Boot CPU: AArch64 Processor [410fd082]
>> [ 0.000000] efi: Getting EFI parameters from FDT:
>> [ 0.000000] efi: EFI v2.60 by EDK II
>> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098
>> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000
>>
>>
>> estuary:/$ ping 192.168.1.107
>> PING 192.168.1.107 (192.168.1.107): 56 data bytes
>> 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms
>> 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms
>> 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms
>> 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms
>> ^C
>> --- 192.168.1.107 ping statistics ---
>> 4 packets transmitted, 4 packets received, 0% packet loss
>> round-trip min/avg/max = 0.098/0.144/0.273 ms
>>
>> estuary:/$ lspci -mk
>> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
>> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>
>> estuary:/$ cat /dev/sd
>> sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl
>> sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1
>>
>> Best Regards,
>> Wei
>>
>>>
>>> Thanks
>>> Hanjun
>>>
>>> .
>>>
>>
> _______________________________________________
> linuxarm mailing list
> [email protected]
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote:
>
> >>>>>
> >>>>>Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
> >>>>>this patch and post the resulting branch for everyone to have a final
> >>>>>test.
> >>>>
> >>>>git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12
> >>>>
> >>>>Please have a look and let me know if that's ok, I planned to send
> >>>>a PR to Catalin by the end of the week (first 7 patches up to
> >>>>7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
> >>>>device")).
> >>>
> >>>Perfect for me too, Lorenzo, Marc, Thank you very much.
> >>>
> >>>I'm currently in paternity leave and can't reach the machine,
> >>>I had a detail review with the patches, they looks good to me,
> >>>Ma Jun and Wei Xu will test on Hisilicon machines and give the
> >>>feedback.
> >>
> >>Thanks to all of you!
> >>Tested on D05 board with this branch, the SAS disks and XGE port are working fine.
> >
> >Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull
> >request to Catalin tomorrow, please carry out last few checks before
> >I send it:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12
> >
> >You should try to merge it with Marc's branch:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12
> >
> >and test the resulting branch, that's how they will go upstream.
> >
> >Please let me know, thank you for your help !
> >
>
> Hi Lorenzo,
>
> xuwei is away now, and it is night time with majun, so I tested.
> majun can retest tomorrow again to triple-check. I did not touch the
> ITS patch Marc made which had the weak version of
> iort_pmis_get_dev_id(), but it should not affect anything in my
> test.
>
> After merging your tag to Marc's branch, here is the git log:
> git log --oneline
> 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12
> d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
> ae7c183 ACPI: platform-msi: retrieve devid from IORT
> e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
> 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
> 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
> d11349c irqchip: mbigen: Add ACPI support
> aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
> 964bac1 irqchip: mbigen: drop module owner
> b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
> d264edb irqchip: gicv3-its: platform-msi: scan MADT to create
> platform msi domain
> baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init()
> to prepare for ACPI
> fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
> cc9eb0d irqchip: gic-v3-its: keep the include header files in
> alphabetic order
> ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
> ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
> 3382357 dt-bindings: mediatek: multiple bases support for sysirq
> 4015616 irqchip: replace moxa with ftintc010
> 532278c irqchip: faraday: fix the trigger types
> 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
> 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
> c02ed2e Linux 4.11-rc4
>
> And some testing:
>
> dmesg snippet:
> [ 0.000000] Booting Linux on physical CPU 0x10000
> [ 0.000000] Linux version 4.11.0-rc4-00420-g8b6f3f8
> (johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 4.8.5 (Linaro
> GCC 4.8-2015.06) ) #4 SMP PREEMPT Thu Mar 30 16:40:36 BST 2017
> [ 0.000000] Boot CPU: AArch64 Processor [410fd082]
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: EFI v2.60 by EDK II
> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000
> ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3cc86018
> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000
> [ 0.000000] ACPI: Early table checksum verification disabled
> [ 0.000000] ACPI: RSDP 0x0000000039BC0014 000024 (v02 HISI )
> [ 0.000000] ACPI: XSDT 0x0000000039BB00E8 00006C (v01 HISI
> HIP07 00000000 01000013)
> [ 0.000000] ACPI: FACP 0x0000000039A80000 00010C (v05 HISI
> HIP07 00000000 INTL 20151124)
> [ 0.000000] ACPI: DSDT 0x0000000039A40000 0074E2 (v02 HISI
> HIP07 00000000 INTL 20151218)
> [ 0.000000] ACPI: MCFG 0x0000000039AD0000 0000AC (v01 HISI
> HIP07 00000000 INTL 20151124)
> [ 0.000000] ACPI: SLIT 0x0000000039AC0000 00003C (v01 HISI
> HIP07 00000000 INTL 20151124)
> [ 0.000000] ACPI: SPCR 0x0000000039AB0000 000050 (v02 HISI
> HIP07 00000000 INTL 20151124)
> [ 0.000000] ACPI: SRAT 0x0000000039AA0000 000500 (v03 HISI
> HIP07 00000000 INTL 20151124)
> [ 0.000000] ACPI: GTDT 0x0000000039A70000 000098 (v02 HISI
> HIP07 00000000 INTL 20151124)
> [ 0.000000] ACPI: APIC 0x0000000039A60000 0013E4 (v01 HISI
> HIP07 00000000 INTL 20151124)
> [ 0.000000] ACPI: IORT 0x0000000039A50000 000514 (v00 HISI
> HIP07 00000000 INTL 20151218)
> [ 0.000000] ACPI: iBFT 0x0000000031870000 000800 (v01 HISI
> HIP07 00000000 00000000)
>
> PCI:
> root@(none)$ lspci -mk
> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>
> Integrated NIC:
> root@(none)$ ifconfig eth1 172.18.45.80 up
> root@(none)$ [ 345.449591] hns-nic HISI00C2:01 eth1: link up
> root@(none)$ ping 172.18.45.23
> PING 172.18.45.23 (172.18.45.23): 56 data bytes
> 64 bytes from 172.18.45.23: seq=0 ttl=64 time=2026.837 ms
> 64 bytes from 172.18.45.23: seq=1 ttl=64 time=1026.843 ms
> 64 bytes from 172.18.45.23: seq=2 ttl=64 time=26.834 ms
> 64 bytes from 172.18.45.23: seq=3 ttl=64 time=0.075 ms
> 64 bytes from 172.18.45.23: seq=4 ttl=64 time=0.079 ms
> ^C
> --- 172.18.45.23 ping statistics ---
> 5 packets transmitted, 5 packets received, 0% packet loss
> round-trip min/avg/max = 0.075/616.133/2026.837 ms
>
>
>
> Integrated Storage controller:
> root@(none)$ fdisk -l
> Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0xdb9f5cd0
>
> Device Boot Start End Blocks Id System
> /dev/sdb1 2048 209717247 104857600 83 Linux
> /dev/sdb2 209717248 419432447 104857600 83 Linux
>
>
> Disk /dev/sda: 186.3 GiB, 200049647616 bytes, 390721968 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>
> Disk /dev/sdc: 186.3 GiB, 200049647616 bytes, 390721968 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>
> Disk /dev/sdd: 186.3 GiB, 200049647616 bytes, 390721968 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>
> Disk /dev/sde: 186.3 GiB, 200049647616 bytes, 390721968 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>
> Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>
> root@(none)$
>
> Looks ok
Great, thanks !
> @majun, please test as well.
Yes, final test, PR is ready to be sent, I reviewed Hanjun patches
but I just want to avoid breaking them given that we had to carry
out changes for the split PR.
Thanks,
Lorenzo
>
> Thanks,
> John
>
> >Lorenzo
> >
> >>The log is as below:
> >>
> >> estuary:/$ dmesg
> >> [ 0.000000] Booting Linux on physical CPU 0x10000
> >> [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017
> >> [ 0.000000] Boot CPU: AArch64 Processor [410fd082]
> >> [ 0.000000] efi: Getting EFI parameters from FDT:
> >> [ 0.000000] efi: EFI v2.60 by EDK II
> >> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098
> >> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000
> >>
> >>
> >> estuary:/$ ping 192.168.1.107
> >> PING 192.168.1.107 (192.168.1.107): 56 data bytes
> >> 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms
> >> 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms
> >> 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms
> >> 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms
> >> ^C
> >> --- 192.168.1.107 ping statistics ---
> >> 4 packets transmitted, 4 packets received, 0% packet loss
> >> round-trip min/avg/max = 0.098/0.144/0.273 ms
> >>
> >> estuary:/$ lspci -mk
> >> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
> >> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
> >>
> >> estuary:/$ cat /dev/sd
> >> sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl
> >> sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1
> >>
> >>Best Regards,
> >>Wei
> >>
> >>>
> >>>Thanks
> >>>Hanjun
> >>>
> >>>.
> >>>
> >>
> >_______________________________________________
> >linuxarm mailing list
> >[email protected]
> >http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
> >
> >.
> >
>
>
Hi Lorenzo:
在 2017/3/31 0:54, Lorenzo Pieralisi 写道:
> On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote:
>>
>>>>>>>
>>>>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>>>>>> this patch and post the resulting branch for everyone to have a final
>>>>>>> test.
[...]
>>>>
>>>> Thanks to all of you!
>>>> Tested on D05 board with this branch, the SAS disks and XGE port are working fine.
>>>
>>> Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull
>>> request to Catalin tomorrow, please carry out last few checks before
>>> I send it:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12
>>>
>>> You should try to merge it with Marc's branch:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12
>>>
>>> and test the resulting branch, that's how they will go upstream.
>>>
>>> Please let me know, thank you for your help !
>>>
>>
>> Hi Lorenzo,
>>
>> xuwei is away now, and it is night time with majun, so I tested.
>> majun can retest tomorrow again to triple-check. I did not touch the
>> ITS patch Marc made which had the weak version of
>> iort_pmis_get_dev_id(), but it should not affect anything in my
>> test.
>>
>> After merging your tag to Marc's branch, here is the git log:
>> git log --oneline
>> 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12
>> d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
>> ae7c183 ACPI: platform-msi: retrieve devid from IORT
>> e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
>> 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
>> 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
>> d11349c irqchip: mbigen: Add ACPI support
>> aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
>> 964bac1 irqchip: mbigen: drop module owner
>> b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
>> d264edb irqchip: gicv3-its: platform-msi: scan MADT to create
>> platform msi domain
>> baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init()
>> to prepare for ACPI
>> fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>> cc9eb0d irqchip: gic-v3-its: keep the include header files in
>> alphabetic order
>> ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
>> ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
>> 3382357 dt-bindings: mediatek: multiple bases support for sysirq
>> 4015616 irqchip: replace moxa with ftintc010
>> 532278c irqchip: faraday: fix the trigger types
>> 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
>> 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
>> c02ed2e Linux 4.11-rc4
>>
>> And some testing:
>>
[...]
>>
>> Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>>
>> root@(none)$
>>
>> Looks ok
>
> Great, thanks !
>
>> @majun, please test as well.
>
> Yes, final test, PR is ready to be sent, I reviewed Hanjun patches
> but I just want to avoid breaking them given that we had to carry
> out changes for the split PR.
>
I tested these patches again as you suggested, all of the related devices，
xge/sas/usb/uart, are working fine on my hisilicon board just like before.
The git log is:
565fdf3 Merge tag 'acpi-arm64-for-v4.12' into marc-irq-4.12
d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
ae7c183 ACPI: platform-msi: retrieve devid from IORT
e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
d11349c irqchip: mbigen: Add ACPI support
aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
964bac1 irqchip: mbigen: drop module owner
b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
cc9eb0d irqchip: gic-v3-its: keep the include header files in alphabetic order
ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
3382357 dt-bindings: mediatek: multiple bases support for sysirq
4015616 irqchip: replace moxa with ftintc010
532278c irqchip: faraday: fix the trigger types
923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
c02ed2e Linux 4.11-rc4
Thanks
Ma Jun
> Thanks,
> Lorenzo
>
>>
>> Thanks,
>> John
>>
>>> Lorenzo
>>>
>>>> The log is as below:
>>>>
>>>> estuary:/$ dmesg
>>>> [ 0.000000] Booting Linux on physical CPU 0x10000
>>>> [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017
>>>> [ 0.000000] Boot CPU: AArch64 Processor [410fd082]
>>>> [ 0.000000] efi: Getting EFI parameters from FDT:
>>>> [ 0.000000] efi: EFI v2.60 by EDK II
>>>> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098
>>>> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000
>>>>
>>>>
>>>> estuary:/$ ping 192.168.1.107
>>>> PING 192.168.1.107 (192.168.1.107): 56 data bytes
>>>> 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms
>>>> 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms
>>>> 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms
>>>> 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms
>>>> ^C
>>>> --- 192.168.1.107 ping statistics ---
>>>> 4 packets transmitted, 4 packets received, 0% packet loss
>>>> round-trip min/avg/max = 0.098/0.144/0.273 ms
>>>>
>>>> estuary:/$ lspci -mk
>>>> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000"
>>>> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport"
>>>>
>>>> estuary:/$ cat /dev/sd
>>>> sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl
>>>> sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1
>>>>
>>>> Best Regards,
>>>> Wei
>>>>
>>>>>
>>>>> Thanks
>>>>> Hanjun
>>>>>
>>>>> .
>>>>>
>>>>
>>> _______________________________________________
>>> linuxarm mailing list
>>> [email protected]
>>> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>>>
>>> .
>>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>