ACPI platform MSI support and its example mbigen

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(-)

drivers/acpi/arm64/iort.c +4 -0

index 83cd59d..fb95ceb 100644
@@ -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.
+ *

drivers/acpi/arm64/iort.c +10 -0

+
+	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

drivers/irqchip/irq-gic-v3-its-platform-msi.c +2 -1

index e4ba9f4..e801fc0 100644
@@ -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;
 

include/linux/acpi_iort.h +5 -0

index 77e0809..d074c77 100644
@@ -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

Signature · 1 line

1.7.12.4

Quoted 47 lines · Hanjun Guo

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]>

[lorenzo.pieralisi at arm.com: 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(-)

drivers/acpi/arm64/iort.c +10 -0

index 83cd59d..fb95ceb 100644
@@ -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;

drivers/acpi/arm64/iort.c u32 iort_msi_map_rid(struct device *dev, u32 req_id) · line 484

Quoted 4 lines

drivers/acpi/arm64/iort.c +4 -0

+
+	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.

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(-)

drivers/acpi/arm64/iort.c +24 -0

index 83cd59d..fb95ceb 100644
@@ -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

drivers/irqchip/irq-gic-v3-its-platform-msi.c +2 -1

index e4ba9f4..e801fc0 100644
@@ -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;
 

include/linux/acpi_iort.h +5 -0

index 77e0809..d074c77 100644
@@ -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

Signature · 1 line

1.7.12.4

Hi Hanjun, Marc,

Quoted 23 lines · Hanjun Guo

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]>

Quoted 5 lines

---
  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.

Hi Lorenzo,

Quoted 32 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

Quoted 23 lines · Hanjun Guo

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]>

Quoted 5 lines

---
 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(-)

Quoted 6 lines

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.

Quoted 1 line

Quoted 1 line

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?

Quoted 54 lines · Hanjun Guo

Hi Lorenzo,

Quoted 32 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

Quoted 23 lines · Hanjun Guo

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]>

Quoted 5 lines

---
  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(-)

Quoted 6 lines

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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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 :)

Quoted 65 lines · Lorenzo Pieralisi

Quoted 54 lines · Hanjun Guo

Hi Lorenzo,

Quoted 32 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

Quoted 23 lines · Hanjun Guo

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]>

Quoted 5 lines

---
  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(-)

Quoted 6 lines

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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 66 lines · Hanjun Guo

Quoted 65 lines · Lorenzo Pieralisi

Quoted 54 lines · Hanjun Guo

Hi Lorenzo,

Quoted 32 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

Quoted 23 lines · Hanjun Guo

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]>

Quoted 5 lines

---
  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(-)

Quoted 6 lines

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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 2 lines

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?

Quoted 85 lines · Marc Zyngier

Quoted 66 lines · Hanjun Guo

Quoted 65 lines · Lorenzo Pieralisi

Quoted 54 lines · Hanjun Guo

Hi Lorenzo,

Quoted 32 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

Quoted 23 lines · Hanjun Guo

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]>

Quoted 5 lines

---
  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(-)

Quoted 6 lines

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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 10 lines · Lorenzo Pieralisi

Quoted 9 lines · Marc Zyngier

Quoted 8 lines · Hanjun Guo

Quoted 7 lines · Lorenzo Pieralisi

Quoted 6 lines · Hanjun Guo

Hi Lorenzo,

Quoted 3 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

Quoted 52 lines

Quoted 52 lines

Quoted 34 lines

Quoted 34 lines

Quoted 24 lines

Quoted 11 lines

Quoted 4 lines

   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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 5 lines

Quoted 1 line

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")).

Quoted 11 lines · Lorenzo Pieralisi

Quoted 10 lines · Marc Zyngier

Quoted 9 lines · Hanjun Guo

Quoted 8 lines · Lorenzo Pieralisi

Quoted 7 lines · Hanjun Guo

Quoted 6 lines

Hi Lorenzo,

Quoted 3 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

[...]

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

   drivers/acpi/arm64/iort.c                     | 24 ++++++++++++++++++++++++
   drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

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

.

Quoted 11 lines · Lorenzo Pieralisi

Quoted 10 lines · Lorenzo Pieralisi

Quoted 9 lines · Marc Zyngier

Quoted 8 lines · Hanjun Guo

Quoted 7 lines · Lorenzo Pieralisi

Quoted 6 lines · Hanjun Guo

Hi Lorenzo,

Quoted 3 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

[...]

Quoted 58 lines

Quoted 52 lines

Quoted 52 lines

Quoted 34 lines

Quoted 34 lines

Quoted 24 lines

Quoted 11 lines

Quoted 4 lines

   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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 5 lines

Quoted 1 line

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.

Quoted 6 lines

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,

Quoted 80 lines · Hanjun Guo

Quoted 11 lines · Lorenzo Pieralisi

Quoted 10 lines · Lorenzo Pieralisi

Quoted 9 lines · Marc Zyngier

Quoted 8 lines · Hanjun Guo

Quoted 7 lines · Lorenzo Pieralisi

Quoted 6 lines · Hanjun Guo

Hi Lorenzo,

Quoted 3 lines · Lorenzo Pieralisi

Hi Hanjun, Marc,

On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:

[...]

Quoted 58 lines

Quoted 52 lines

Quoted 52 lines

Quoted 34 lines

Quoted 34 lines

Quoted 24 lines

Quoted 11 lines

Quoted 4 lines

   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.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 5 lines

Quoted 1 line

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.

Quoted 6 lines

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.

Quoted 4 lines

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

Quoted 6 lines

Thanks
Hanjun

.

Quoted 15 lines

Quoted 15 lines

Quoted 6 lines

Quoted 5 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

Quoted 4 lines

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

Quoted 34 lines

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 at 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"

Quoted 14 lines

	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

Quoted 6 lines

Thanks
Hanjun

.

_______________________________________________
linuxarm mailing list
linuxarm at huawei.com
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

.

Quoted 29 lines

Quoted 15 lines

Quoted 15 lines

Quoted 6 lines

Quoted 5 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

Quoted 4 lines

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

Quoted 8 lines

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

Quoted 57 lines

Lorenzo

Quoted 34 lines

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"

Quoted 14 lines

	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

Quoted 6 lines

Thanks
Hanjun

.

_______________________________________________
linuxarm mailing list
[email protected]
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 57 lines

Quoted 10 lines

Quoted 3 lines

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

Quoted 8 lines

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:

Quoted 9 lines

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 !

Quoted 1 line

@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

Quoted 63 lines

Thanks,
John

Quoted 57 lines

Lorenzo

Quoted 34 lines

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 at 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"

Quoted 14 lines

	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

Quoted 6 lines

Thanks
Hanjun

.

_______________________________________________
linuxarm mailing list
linuxarm at huawei.com
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 majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

.

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(-)

drivers/irqchip/irq-mbigen.c +67 -3

index 3756408..e6bb503 100644
@@ -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,
 };

Signature · 1 line

1.7.12.4

Quoted 8 lines · Hanjun Guo

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.

Quoted 7 lines

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

Quoted 140 lines

          })
    }

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(-)

drivers/irqchip/irq-mbigen.c +67 -4

index 3756408..e6bb503 100644
@@ -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,
 };
--

Quoted 2 lines

1.7.12.4

_______________________________________________
linuxarm mailing list
[email protected]
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

.

Quoted 17 lines · Lorenzo Pieralisi

Quoted 8 lines · Hanjun Guo

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.

Quoted 7 lines

For mbigen,

    Device(MBI0) {
          Name(_HID, "HISI0152")
          Name(_UID, Zero)
          Name(_CRS, ResourceTemplate() {
                  Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
		  Interrupt(ResourceProducer,...) {12,14,....}

Quoted 6 lines

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?

Quoted 9 lines

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.

Quoted 3 lines

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.

-----Original Message-----
From: linuxarm-bounces at huawei.com [mailto:linuxarm-bounces at huawei.com] 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- kernel at vger.kernel.org; Sinan Kaya; linux-acpi at vger.kernel.org; Hanjun Guo; Tomasz Nowicki; Thomas Gleixner; linux-arm-
kernel at lists.infradead.org
Subject: Re: [PATCH v9 15/15] irqchip: mbigen: Add ACPI support

Hanjun, John,

Quoted 8 lines · John Garry

Quoted 7 lines · Lorenzo Pieralisi

Quoted 6 lines · Hanjun Guo

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

of irq pins instead of num_pins in DT to avoid _DSD usage in this

case.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

For mbigen,

    Device(MBI0) {
          Name(_HID, "HISI0152")
          Name(_UID, Zero)
          Name(_CRS, ResourceTemplate() {
                  Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
		  Interrupt(ResourceProducer,...) {12,14,....}

Quoted 8 lines

Quoted 6 lines

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

Quoted 3 lines

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

Quoted 11 lines

to count their interrupts, and use this as the #msis?

Quoted 9 lines

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.

Quoted 5 lines

Quoted 3 lines

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...
_______________________________________________
linuxarm mailing list
linuxarm at huawei.com
http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Hi Marc Many thanks for your comments

Quoted 72 lines

-----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,

Quoted 8 lines · John Garry

Quoted 7 lines · Lorenzo Pieralisi

Quoted 6 lines · Hanjun Guo

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

of irq pins instead of num_pins in DT to avoid _DSD usage in this

case.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

For mbigen,

    Device(MBI0) {
          Name(_HID, "HISI0152")
          Name(_UID, Zero)
          Name(_CRS, ResourceTemplate() {
                  Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
		  Interrupt(ResourceProducer,...) {12,14,....}

Quoted 8 lines

Quoted 6 lines

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

Quoted 3 lines

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

Quoted 11 lines

to count their interrupts, and use this as the #msis?

Quoted 9 lines

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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 3 lines

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...

[+Al,Darren to comment on _DSD review process]

Quoted 97 lines · Gabriele Paoloni

Hi Marc Many thanks for your comments

Quoted 72 lines

-----Original Message-----
From: linuxarm-bounces at huawei.com [mailto:linuxarm-bounces at huawei.com] 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- kernel at vger.kernel.org; Sinan Kaya; linux-acpi at vger.kernel.org; Hanjun Guo; Tomasz Nowicki; Thomas Gleixner; linux-arm-
kernel at lists.infradead.org
Subject: Re: [PATCH v9 15/15] irqchip: mbigen: Add ACPI support

Hanjun, John,

Quoted 8 lines · John Garry

Quoted 7 lines · Lorenzo Pieralisi

Quoted 6 lines · Hanjun Guo

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

of irq pins instead of num_pins in DT to avoid _DSD usage in this

case.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

For mbigen,

    Device(MBI0) {
          Name(_HID, "HISI0152")
          Name(_UID, Zero)
          Name(_CRS, ResourceTemplate() {
                  Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
		  Interrupt(ResourceProducer,...) {12,14,....}

Quoted 8 lines

Quoted 6 lines

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

Quoted 3 lines

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

Quoted 11 lines

to count their interrupts, and use this as the #msis?

Quoted 9 lines

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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 3 lines

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}
      }
    })
    }

Quoted 12 lines

For devices,

   Device(COM0) {
          Name(_HID, "ACPIIDxx")
          Name(_UID, Zero)
          Name(_CRS, ResourceTemplate() {
                 Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
		 Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
          })
    }

Quoted 1 line

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

Quoted 88 lines · Lorenzo Pieralisi

[+Al,Darren to comment on _DSD review process]

Quoted 85 lines · Gabriele Paoloni

Hi Marc Many thanks for your comments

Quoted 61 lines

Hanjun, John,

Quoted 8 lines · John Garry

Quoted 7 lines · Lorenzo Pieralisi

Quoted 6 lines · Hanjun Guo

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

of irq pins instead of num_pins in DT to avoid _DSD usage in this

case.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

For mbigen,

     Device(MBI0) {
           Name(_HID, "HISI0152")
           Name(_UID, Zero)
           Name(_CRS, ResourceTemplate() {
                   Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
		  Interrupt(ResourceProducer,...) {12,14,....}

Quoted 8 lines

Quoted 6 lines

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

Quoted 3 lines

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

Quoted 11 lines

to count their interrupts, and use this as the #msis?

Quoted 9 lines

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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 13 lines

Quoted 13 lines

For devices,

    Device(COM0) {
           Name(_HID, "ACPIIDxx")
           Name(_UID, Zero)
           Name(_CRS, ResourceTemplate() {
                  Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
		 Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
           })
     }

Quoted 8 lines

Quoted 1 line

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

Quoted 1 line

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.

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(-)

Signature · 1 line

1.7.12.4

Quoted 17 lines · Hanjun Guo

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!)

Quoted 1 line

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).