| Message ID | 1488890410-15503-11-git-send-email-guohanjun@huawei.com |
|---|---|
| State | New |
| Headers | show |
| Series | ACPI platform MSI support and its example mbigen | expand |
On 2017/3/7 22:35, Lorenzo Pieralisi wrote: > On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: >> From: Hanjun Guo <hanjun.guo@linaro.org> >> >> 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 <hanjun.guo@linaro.org> >> [lorenzo.pieralisi@arm.com: rewrote commit log] >> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> >> Tested-by: Ming Lei <ming.lei@canonical.com> >> Tested-by: Wei Xu <xuwei5@hisilicon.com> >> Tested-by: Sinan Kaya <okaya@codeaurora.org> >> Cc: Marc Zyngier <marc.zyngier@arm.com> >> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> >> Cc: Tomasz Nowicki <tn@semihalf.com> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> --- >> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++ >> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++- >> include/linux/acpi_iort.h | 5 +++++ >> 3 files changed, 31 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c >> index 83cd59d..fb95ceb 100644 >> --- a/drivers/acpi/arm64/iort.c >> +++ b/drivers/acpi/arm64/iort.c >> @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id) >> } >> >> /** >> + * iort_pmsi_get_dev_id() - Get the device id for a device >> + * @dev: The device for which the mapping is to be done. >> + * @dev_id: The device ID found. >> + * >> + * Returns: 0 for successful find a dev id, -ENODEV on error >> + */ >> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id) >> +{ >> + int i; >> + struct acpi_iort_node *node; >> + >> + node = iort_find_dev_node(dev); >> + if (!node) >> + return -ENODEV; > I think that when specs are updated so that we can enable SMMU MSIs we > shall have to find a way to get the acpi_iort_node for a device that is > not a named component here (ie SMMU), I reckon we can use the > fwnode_handle but I have to have a deeper look. Seems we can do this as follows: --- drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) > > This does not affect the patchset in its current form, just scanning > the code to make sure we will be able to support SMMU MSIs too when > time comes. Sure, thanks! Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmldiff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 22e08d2..c794219 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -121,6 +121,31 @@ static inline void iort_delete_fwnode(struct acpi_iort_node *node) spin_unlock(&iort_fwnode_lock); } +/** + * iort_get_iort_node() - Retrieve iort_node associated with an fwnode + * + * @fwnode: fwnode associated with device to be looked-up + * + * Returns: iort_node pointer on success, NULL on failure + */ +static inline +struct acpi_iort_node *iort_get_iort_node(struct fwnode_handle *fwnode) +{ + struct iort_fwnode *curr; + struct acpi_iort_node *iort_node = NULL; + + spin_lock(&iort_fwnode_lock); + list_for_each_entry(curr, &iort_fwnode_list, list) { + if (curr->fwnode == fwnode) { + iort_node = curr->iort_node; + break; + } + } + spin_unlock(&iort_fwnode_lock); + + return iort_node; +} + typedef acpi_status (*iort_find_node_callback) (struct acpi_iort_node *node, void *context); @@ -434,9 +459,25 @@ static struct acpi_iort_node *iort_find_dev_node(struct device *dev) { struct pci_bus *pbus; - if (!dev_is_pci(dev)) + if (!dev_is_pci(dev)) { + struct acpi_iort_node *node; + /* + * scan iort_fwnode_list to see if it's an iort platform + * device (such as SMMU, PMCG),its iort node already cached + * and associated with fwnode when iort platform devices + * were initialized. + */ + node = iort_get_iort_node(dev->fwnode); + if (node) + return node; + + /* + * if not, then it should be a platform device defined in + * DSDT (with Named Component node in IORT) + */ return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT, iort_match_node_callback, dev); + } /* Find a PCI root bus */ pbus = to_pci_dev(dev)->bus;
Hi Hanjun, Marc, On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: > From: Hanjun Guo <hanjun.guo@linaro.org> > > 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 <hanjun.guo@linaro.org> > [lorenzo.pieralisi@arm.com: rewrote commit log] > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > Tested-by: Ming Lei <ming.lei@canonical.com> > Tested-by: Wei Xu <xuwei5@hisilicon.com> > Tested-by: Sinan Kaya <okaya@codeaurora.org> > Cc: Marc Zyngier <marc.zyngier@arm.com> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > Cc: Tomasz Nowicki <tn@semihalf.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > --- > drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++ > drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++- > include/linux/acpi_iort.h | 5 +++++ > 3 files changed, 31 insertions(+), 1 deletion(-) To simplify merging ACPI/IRQCHIP changes via different trees it would be good to split this patch; I am not sure what's the best way of handling it though given that we would end up in a merge ordering dependency anyway (ie we can create an empty stub for iort_pmsi_get_dev_id() but that would create a dependency between ARM64 and irqchip trees anyway). Please let me know what's your preferred way of handling this. Thanks, Lorenzo > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index 83cd59d..fb95ceb 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id) > } > > /** > + * iort_pmsi_get_dev_id() - Get the device id for a device > + * @dev: The device for which the mapping is to be done. > + * @dev_id: The device ID found. > + * > + * Returns: 0 for successful find a dev id, -ENODEV on error > + */ > +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id) > +{ > + int i; > + struct acpi_iort_node *node; > + > + node = iort_find_dev_node(dev); > + if (!node) > + return -ENODEV; > + > + for (i = 0; i < node->mapping_count; i++) { > + if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i)) > + return 0; > + } > + > + return -ENODEV; > +} > + > +/** > * iort_dev_find_its_id() - Find the ITS identifier for a device > * @dev: The device. > * @req_id: Device's requester ID > diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c > index e4ba9f4..e801fc0 100644 > --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c > +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c > @@ -57,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, > > msi_info = msi_get_domain_info(domain->parent); > > - ret = of_pmsi_get_dev_id(domain, dev, &dev_id); > + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) : > + iort_pmsi_get_dev_id(dev, &dev_id); > if (ret) > return ret; > > diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h > index 77e0809..d074c77 100644 > --- a/include/linux/acpi_iort.h > +++ b/include/linux/acpi_iort.h > @@ -34,6 +34,7 @@ > bool iort_node_match(u8 type); > u32 iort_msi_map_rid(struct device *dev, u32 req_id); > struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id); > +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id); > /* IOMMU interface */ > void iort_set_dma_mask(struct device *dev); > const struct iommu_ops *iort_iommu_configure(struct device *dev); > @@ -45,6 +46,10 @@ static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id) > static inline struct irq_domain *iort_get_device_domain(struct device *dev, > u32 req_id) > { return NULL; } > + > +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id) > +{ return -ENODEV; } > + > /* IOMMU interface */ > static inline void iort_set_dma_mask(struct device *dev) { } > static inline > -- > 1.7.12.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote: > On 29/03/17 14:00, Hanjun Guo wrote: > > On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: > >> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote: > >>> Hi Lorenzo, > >>> > >>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote: > >>>> Hi Hanjun, Marc, > >>>> > >>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: > >>>>> From: Hanjun Guo <hanjun.guo@linaro.org> > >>>>> > >>>>> 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 <hanjun.guo@linaro.org> > >>>>> [lorenzo.pieralisi@arm.com: rewrote commit log] > >>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > >>>>> Tested-by: Ming Lei <ming.lei@canonical.com> > >>>>> Tested-by: Wei Xu <xuwei5@hisilicon.com> > >>>>> Tested-by: Sinan Kaya <okaya@codeaurora.org> > >>>>> Cc: Marc Zyngier <marc.zyngier@arm.com> > >>>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > >>>>> Cc: Tomasz Nowicki <tn@semihalf.com> > >>>>> Cc: Thomas Gleixner <tglx@linutronix.de> > >>>>> --- > >>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++ > >>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++- > >>>>> include/linux/acpi_iort.h | 5 +++++ > >>>>> 3 files changed, 31 insertions(+), 1 deletion(-) > >>>> > >>>> To simplify merging ACPI/IRQCHIP changes via different trees it > >>>> would be good to split this patch; I am not sure what's the best > >>>> way of handling it though given that we would end up in a merge > >>>> ordering dependency anyway (ie we can create an empty stub > >>>> for iort_pmsi_get_dev_id() but that would create a dependency > >>>> between ARM64 and irqchip trees anyway). > >>> > >>> The first 12 patches for ACPI platform MSI and later 3 patches > >>> for mbigen have no "physical" dependency, which means they can > >>> be merged and compiled independently, they only have functional > >>> dependency only. > >>> > >>> We already had SAS, XGE, USB and even UART drivers depend on > >>> the mbigen ACPI support, so I don't think the dependency of ACPI > >>> platform MSI and mbigen patches cares much if those two parts are > >>> merged in one merge window, even they are merged independently via > >>> different tree. > >>> > >>>> > >>>> Please let me know what's your preferred way of handling this. > >>> > >>> So in my opinion, they can be merged independently via ARM64 and > >>> irqchip tree with no ordering dependency, is it OK? > >> > >> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and > >> ACPI/IORT for ARM64, that's why I replied to this patch. I do not > >> think that's feasible to split patches in two separate branches > >> without having a dependency between them. > >> > >> Sure, the last three patches can go via IRQCHIP but that was not > >> my question :) > > > > Sorry, I misunderstood that :( > > > > Since it's not feasible to split patches, the best way I got is that > > we get Marc's ack then merge it. > > I believe there is a way to make this work without too much hassle. I > suggest we drop the ITS change from this patch entirely, and I instead > queue this patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45 > > That way, no dependency between the two trees. Lorenzo takes all the > patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and > everything should be perfectly standalone. > > Thoughts? Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework this patch and post the resulting branch for everyone to have a final test. Ok ? Thanks ! Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote: > On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote: > > On 29/03/17 14:00, Hanjun Guo wrote: > > > On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: > > >> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote: > > >>> Hi Lorenzo, > > >>> > > >>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote: > > >>>> Hi Hanjun, Marc, > > >>>> > > >>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: > > >>>>> From: Hanjun Guo <hanjun.guo@linaro.org> > > >>>>> > > >>>>> 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 <hanjun.guo@linaro.org> > > >>>>> [lorenzo.pieralisi@arm.com: rewrote commit log] > > >>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > > >>>>> Tested-by: Ming Lei <ming.lei@canonical.com> > > >>>>> Tested-by: Wei Xu <xuwei5@hisilicon.com> > > >>>>> Tested-by: Sinan Kaya <okaya@codeaurora.org> > > >>>>> Cc: Marc Zyngier <marc.zyngier@arm.com> > > >>>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> > > >>>>> Cc: Tomasz Nowicki <tn@semihalf.com> > > >>>>> Cc: Thomas Gleixner <tglx@linutronix.de> > > >>>>> --- > > >>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++ > > >>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++- > > >>>>> include/linux/acpi_iort.h | 5 +++++ > > >>>>> 3 files changed, 31 insertions(+), 1 deletion(-) > > >>>> > > >>>> To simplify merging ACPI/IRQCHIP changes via different trees it > > >>>> would be good to split this patch; I am not sure what's the best > > >>>> way of handling it though given that we would end up in a merge > > >>>> ordering dependency anyway (ie we can create an empty stub > > >>>> for iort_pmsi_get_dev_id() but that would create a dependency > > >>>> between ARM64 and irqchip trees anyway). > > >>> > > >>> The first 12 patches for ACPI platform MSI and later 3 patches > > >>> for mbigen have no "physical" dependency, which means they can > > >>> be merged and compiled independently, they only have functional > > >>> dependency only. > > >>> > > >>> We already had SAS, XGE, USB and even UART drivers depend on > > >>> the mbigen ACPI support, so I don't think the dependency of ACPI > > >>> platform MSI and mbigen patches cares much if those two parts are > > >>> merged in one merge window, even they are merged independently via > > >>> different tree. > > >>> > > >>>> > > >>>> Please let me know what's your preferred way of handling this. > > >>> > > >>> So in my opinion, they can be merged independently via ARM64 and > > >>> irqchip tree with no ordering dependency, is it OK? > > >> > > >> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and > > >> ACPI/IORT for ARM64, that's why I replied to this patch. I do not > > >> think that's feasible to split patches in two separate branches > > >> without having a dependency between them. > > >> > > >> Sure, the last three patches can go via IRQCHIP but that was not > > >> my question :) > > > > > > Sorry, I misunderstood that :( > > > > > > Since it's not feasible to split patches, the best way I got is that > > > we get Marc's ack then merge it. > > > > I believe there is a way to make this work without too much hassle. I > > suggest we drop the ITS change from this patch entirely, and I instead > > queue this patch: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45 > > > > That way, no dependency between the two trees. Lorenzo takes all the > > patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and > > everything should be perfectly standalone. > > > > Thoughts? > > Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework > this patch and post the resulting branch for everyone to have a final > test. git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12 Please have a look and let me know if that's ok, I planned to send a PR to Catalin by the end of the week (first 7 patches up to 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform device")). Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all: 在 2017/3/30 11:07, Hanjun Guo 写道: > On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote: >> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote: >>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote: >>>> On 29/03/17 14:00, Hanjun Guo wrote: >>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: >>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote: >>>>>>> Hi Lorenzo, >>>>>>> >>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote: >>>>>>>> Hi Hanjun, Marc, >>>>>>>> >>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: > [...] >>>>>>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++ >>>>>>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++- [...] >>>> >>>> Thoughts? >>> >>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework >>> this patch and post the resulting branch for everyone to have a final >>> test. >> >> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12 >> >> Please have a look and let me know if that's ok, I planned to send >> a PR to Catalin by the end of the week (first 7 patches up to >> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform >> device")). > > Perfect for me too, Lorenzo, Marc, Thank you very much. > > I'm currently in paternity leave and can't reach the machine, > I had a detail review with the patches, they looks good to me, > Ma Jun and Wei Xu will test on Hisilicon machines and give the > feedback. The sas/xge/uart are working fine on my hisilicon board with Lorenzo's branch (arm64-acpi-4.12) Thanks Majun > > Thanks > Hanjun > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 30, 2017 at 09:32:57AM +0100, Wei Xu wrote: > Hi All, > > On 2017/3/30 4:07, Hanjun Guo wrote: > > On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote: > >> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote: > >>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote: > >>>> On 29/03/17 14:00, Hanjun Guo wrote: > >>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: > >>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote: > >>>>>>> Hi Lorenzo, > >>>>>>> > >>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote: > >>>>>>>> Hi Hanjun, Marc, > >>>>>>>> > >>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: > > [...] > >>>>>>>>> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++ > >>>>>>>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++- > >>>>>>>>> include/linux/acpi_iort.h | 5 +++++ > >>>>>>>>> 3 files changed, 31 insertions(+), 1 deletion(-) > >>>>>>>> > >>>>>>>> To simplify merging ACPI/IRQCHIP changes via different trees it > >>>>>>>> would be good to split this patch; I am not sure what's the best > >>>>>>>> way of handling it though given that we would end up in a merge > >>>>>>>> ordering dependency anyway (ie we can create an empty stub > >>>>>>>> for iort_pmsi_get_dev_id() but that would create a dependency > >>>>>>>> between ARM64 and irqchip trees anyway). > >>>>>>> > >>>>>>> The first 12 patches for ACPI platform MSI and later 3 patches > >>>>>>> for mbigen have no "physical" dependency, which means they can > >>>>>>> be merged and compiled independently, they only have functional > >>>>>>> dependency only. > >>>>>>> > >>>>>>> We already had SAS, XGE, USB and even UART drivers depend on > >>>>>>> the mbigen ACPI support, so I don't think the dependency of ACPI > >>>>>>> platform MSI and mbigen patches cares much if those two parts are > >>>>>>> merged in one merge window, even they are merged independently via > >>>>>>> different tree. > >>>>>>> > >>>>>>>> > >>>>>>>> Please let me know what's your preferred way of handling this. > >>>>>>> > >>>>>>> So in my opinion, they can be merged independently via ARM64 and > >>>>>>> irqchip tree with no ordering dependency, is it OK? > >>>>>> > >>>>>> I am speaking about merging MBIgen AND ITS patches via IRQCHIP and > >>>>>> ACPI/IORT for ARM64, that's why I replied to this patch. I do not > >>>>>> think that's feasible to split patches in two separate branches > >>>>>> without having a dependency between them. > >>>>>> > >>>>>> Sure, the last three patches can go via IRQCHIP but that was not > >>>>>> my question :) > >>>>> > >>>>> Sorry, I misunderstood that :( > >>>>> > >>>>> Since it's not feasible to split patches, the best way I got is that > >>>>> we get Marc's ack then merge it. > >>>> > >>>> I believe there is a way to make this work without too much hassle. I > >>>> suggest we drop the ITS change from this patch entirely, and I instead > >>>> queue this patch: > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45 > >>>> > >>>> That way, no dependency between the two trees. Lorenzo takes all the > >>>> patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and > >>>> everything should be perfectly standalone. > >>>> > >>>> Thoughts? > >>> > >>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework > >>> this patch and post the resulting branch for everyone to have a final > >>> test. > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12 > >> > >> Please have a look and let me know if that's ok, I planned to send > >> a PR to Catalin by the end of the week (first 7 patches up to > >> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform > >> device")). > > > > Perfect for me too, Lorenzo, Marc, Thank you very much. > > > > I'm currently in paternity leave and can't reach the machine, > > I had a detail review with the patches, they looks good to me, > > Ma Jun and Wei Xu will test on Hisilicon machines and give the > > feedback. > > Thanks to all of you! > Tested on D05 board with this branch, the SAS disks and XGE port are working fine. Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull request to Catalin tomorrow, please carry out last few checks before I send it: git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12 You should try to merge it with Marc's branch: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12 and test the resulting branch, that's how they will go upstream. Please let me know, thank you for your help ! Lorenzo > The log is as below: > > estuary:/$ dmesg > [ 0.000000] Booting Linux on physical CPU 0x10000 > [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017 > [ 0.000000] Boot CPU: AArch64 Processor [410fd082] > [ 0.000000] efi: Getting EFI parameters from FDT: > [ 0.000000] efi: EFI v2.60 by EDK II > [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098 > [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000 > > > estuary:/$ ping 192.168.1.107 > PING 192.168.1.107 (192.168.1.107): 56 data bytes > 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms > 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms > 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms > 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms > ^C > --- 192.168.1.107 ping statistics --- > 4 packets transmitted, 4 packets received, 0% packet loss > round-trip min/avg/max = 0.098/0.144/0.273 ms > > estuary:/$ lspci -mk > 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000" > 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > > estuary:/$ cat /dev/sd > sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl > sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1 > > Best Regards, > Wei > > > > > Thanks > > Hanjun > > > > . > > > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> >>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework >>>>> this patch and post the resulting branch for everyone to have a final >>>>> test. >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12 >>>> >>>> Please have a look and let me know if that's ok, I planned to send >>>> a PR to Catalin by the end of the week (first 7 patches up to >>>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform >>>> device")). >>> >>> Perfect for me too, Lorenzo, Marc, Thank you very much. >>> >>> I'm currently in paternity leave and can't reach the machine, >>> I had a detail review with the patches, they looks good to me, >>> Ma Jun and Wei Xu will test on Hisilicon machines and give the >>> feedback. >> >> Thanks to all of you! >> Tested on D05 board with this branch, the SAS disks and XGE port are working fine. > > Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull > request to Catalin tomorrow, please carry out last few checks before > I send it: > > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12 > > You should try to merge it with Marc's branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12 > > and test the resulting branch, that's how they will go upstream. > > Please let me know, thank you for your help ! > Hi Lorenzo, xuwei is away now, and it is night time with majun, so I tested. majun can retest tomorrow again to triple-check. I did not touch the ITS patch Marc made which had the weak version of iort_pmis_get_dev_id(), but it should not affect anything in my test. After merging your tag to Marc's branch, here is the git log: git log --oneline 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12 d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device ae7c183 ACPI: platform-msi: retrieve devid from IORT e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic d11349c irqchip: mbigen: Add ACPI support aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain() 964bac1 irqchip: mbigen: drop module owner b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare() cc9eb0d irqchip: gic-v3-its: keep the include header files in alphabetic order ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number 3382357 dt-bindings: mediatek: multiple bases support for sysirq 4015616 irqchip: replace moxa with ftintc010 532278c irqchip: faraday: fix the trigger types 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin c02ed2e Linux 4.11-rc4 And some testing: dmesg snippet: [ 0.000000] Booting Linux on physical CPU 0x10000 [ 0.000000] Linux version 4.11.0-rc4-00420-g8b6f3f8 (johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 4.8.5 (Linaro GCC 4.8-2015.06) ) #4 SMP PREEMPT Thu Mar 30 16:40:36 BST 2017 [ 0.000000] Boot CPU: AArch64 Processor [410fd082] [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: EFI v2.60 by EDK II [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3cc86018 [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000 [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x0000000039BC0014 000024 (v02 HISI ) [ 0.000000] ACPI: XSDT 0x0000000039BB00E8 00006C (v01 HISI HIP07 00000000 01000013) [ 0.000000] ACPI: FACP 0x0000000039A80000 00010C (v05 HISI HIP07 00000000 INTL 20151124) [ 0.000000] ACPI: DSDT 0x0000000039A40000 0074E2 (v02 HISI HIP07 00000000 INTL 20151218) [ 0.000000] ACPI: MCFG 0x0000000039AD0000 0000AC (v01 HISI HIP07 00000000 INTL 20151124) [ 0.000000] ACPI: SLIT 0x0000000039AC0000 00003C (v01 HISI HIP07 00000000 INTL 20151124) [ 0.000000] ACPI: SPCR 0x0000000039AB0000 000050 (v02 HISI HIP07 00000000 INTL 20151124) [ 0.000000] ACPI: SRAT 0x0000000039AA0000 000500 (v03 HISI HIP07 00000000 INTL 20151124) [ 0.000000] ACPI: GTDT 0x0000000039A70000 000098 (v02 HISI HIP07 00000000 INTL 20151124) [ 0.000000] ACPI: APIC 0x0000000039A60000 0013E4 (v01 HISI HIP07 00000000 INTL 20151124) [ 0.000000] ACPI: IORT 0x0000000039A50000 000514 (v00 HISI HIP07 00000000 INTL 20151218) [ 0.000000] ACPI: iBFT 0x0000000031870000 000800 (v01 HISI HIP07 00000000 00000000) PCI: root@(none)$ lspci -mk 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000" 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" Integrated NIC: root@(none)$ ifconfig eth1 172.18.45.80 up root@(none)$ [ 345.449591] hns-nic HISI00C2:01 eth1: link up root@(none)$ ping 172.18.45.23 PING 172.18.45.23 (172.18.45.23): 56 data bytes 64 bytes from 172.18.45.23: seq=0 ttl=64 time=2026.837 ms 64 bytes from 172.18.45.23: seq=1 ttl=64 time=1026.843 ms 64 bytes from 172.18.45.23: seq=2 ttl=64 time=26.834 ms 64 bytes from 172.18.45.23: seq=3 ttl=64 time=0.075 ms 64 bytes from 172.18.45.23: seq=4 ttl=64 time=0.079 ms ^C --- 172.18.45.23 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.075/616.133/2026.837 ms Integrated Storage controller: root@(none)$ fdisk -l Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xdb9f5cd0 Device Boot Start End Blocks Id System /dev/sdb1 2048 209717247 104857600 83 Linux /dev/sdb2 209717248 419432447 104857600 83 Linux Disk /dev/sda: 186.3 GiB, 200049647616 bytes, 390721968 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 131072 bytes Disk /dev/sdc: 186.3 GiB, 200049647616 bytes, 390721968 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 131072 bytes Disk /dev/sdd: 186.3 GiB, 200049647616 bytes, 390721968 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 131072 bytes Disk /dev/sde: 186.3 GiB, 200049647616 bytes, 390721968 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 131072 bytes Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 131072 bytes root@(none)$ Looks ok @majun, please test as well. Thanks, John > Lorenzo > >> The log is as below: >> >> estuary:/$ dmesg >> [ 0.000000] Booting Linux on physical CPU 0x10000 >> [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017 >> [ 0.000000] Boot CPU: AArch64 Processor [410fd082] >> [ 0.000000] efi: Getting EFI parameters from FDT: >> [ 0.000000] efi: EFI v2.60 by EDK II >> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098 >> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000 >> >> >> estuary:/$ ping 192.168.1.107 >> PING 192.168.1.107 (192.168.1.107): 56 data bytes >> 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms >> 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms >> 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms >> 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms >> ^C >> --- 192.168.1.107 ping statistics --- >> 4 packets transmitted, 4 packets received, 0% packet loss >> round-trip min/avg/max = 0.098/0.144/0.273 ms >> >> estuary:/$ lspci -mk >> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000" >> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >> >> estuary:/$ cat /dev/sd >> sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl >> sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1 >> >> Best Regards, >> Wei >> >>> >>> Thanks >>> Hanjun >>> >>> . >>> >> > _______________________________________________ > linuxarm mailing list > linuxarm@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote: > > >>>>> > >>>>>Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework > >>>>>this patch and post the resulting branch for everyone to have a final > >>>>>test. > >>>> > >>>>git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12 > >>>> > >>>>Please have a look and let me know if that's ok, I planned to send > >>>>a PR to Catalin by the end of the week (first 7 patches up to > >>>>7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform > >>>>device")). > >>> > >>>Perfect for me too, Lorenzo, Marc, Thank you very much. > >>> > >>>I'm currently in paternity leave and can't reach the machine, > >>>I had a detail review with the patches, they looks good to me, > >>>Ma Jun and Wei Xu will test on Hisilicon machines and give the > >>>feedback. > >> > >>Thanks to all of you! > >>Tested on D05 board with this branch, the SAS disks and XGE port are working fine. > > > >Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull > >request to Catalin tomorrow, please carry out last few checks before > >I send it: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12 > > > >You should try to merge it with Marc's branch: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12 > > > >and test the resulting branch, that's how they will go upstream. > > > >Please let me know, thank you for your help ! > > > > Hi Lorenzo, > > xuwei is away now, and it is night time with majun, so I tested. > majun can retest tomorrow again to triple-check. I did not touch the > ITS patch Marc made which had the weak version of > iort_pmis_get_dev_id(), but it should not affect anything in my > test. > > After merging your tag to Marc's branch, here is the git log: > git log --oneline > 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12 > d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device > ae7c183 ACPI: platform-msi: retrieve devid from IORT > e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support > 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id > 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic > d11349c irqchip: mbigen: Add ACPI support > aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain() > 964bac1 irqchip: mbigen: drop module owner > b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware > d264edb irqchip: gicv3-its: platform-msi: scan MADT to create > platform msi domain > baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() > to prepare for ACPI > fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare() > cc9eb0d irqchip: gic-v3-its: keep the include header files in > alphabetic order > ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type > ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number > 3382357 dt-bindings: mediatek: multiple bases support for sysirq > 4015616 irqchip: replace moxa with ftintc010 > 532278c irqchip: faraday: fix the trigger types > 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin > 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin > c02ed2e Linux 4.11-rc4 > > And some testing: > > dmesg snippet: > [ 0.000000] Booting Linux on physical CPU 0x10000 > [ 0.000000] Linux version 4.11.0-rc4-00420-g8b6f3f8 > (johnpgarry@johnpgarry-ThinkCentre-M93p) (gcc version 4.8.5 (Linaro > GCC 4.8-2015.06) ) #4 SMP PREEMPT Thu Mar 30 16:40:36 BST 2017 > [ 0.000000] Boot CPU: AArch64 Processor [410fd082] > [ 0.000000] efi: Getting EFI parameters from FDT: > [ 0.000000] efi: EFI v2.60 by EDK II > [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 > ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3cc86018 > [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000 > [ 0.000000] ACPI: Early table checksum verification disabled > [ 0.000000] ACPI: RSDP 0x0000000039BC0014 000024 (v02 HISI ) > [ 0.000000] ACPI: XSDT 0x0000000039BB00E8 00006C (v01 HISI > HIP07 00000000 01000013) > [ 0.000000] ACPI: FACP 0x0000000039A80000 00010C (v05 HISI > HIP07 00000000 INTL 20151124) > [ 0.000000] ACPI: DSDT 0x0000000039A40000 0074E2 (v02 HISI > HIP07 00000000 INTL 20151218) > [ 0.000000] ACPI: MCFG 0x0000000039AD0000 0000AC (v01 HISI > HIP07 00000000 INTL 20151124) > [ 0.000000] ACPI: SLIT 0x0000000039AC0000 00003C (v01 HISI > HIP07 00000000 INTL 20151124) > [ 0.000000] ACPI: SPCR 0x0000000039AB0000 000050 (v02 HISI > HIP07 00000000 INTL 20151124) > [ 0.000000] ACPI: SRAT 0x0000000039AA0000 000500 (v03 HISI > HIP07 00000000 INTL 20151124) > [ 0.000000] ACPI: GTDT 0x0000000039A70000 000098 (v02 HISI > HIP07 00000000 INTL 20151124) > [ 0.000000] ACPI: APIC 0x0000000039A60000 0013E4 (v01 HISI > HIP07 00000000 INTL 20151124) > [ 0.000000] ACPI: IORT 0x0000000039A50000 000514 (v00 HISI > HIP07 00000000 INTL 20151218) > [ 0.000000] ACPI: iBFT 0x0000000031870000 000800 (v01 HISI > HIP07 00000000 00000000) > > PCI: > root@(none)$ lspci -mk > 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000" > 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > > Integrated NIC: > root@(none)$ ifconfig eth1 172.18.45.80 up > root@(none)$ [ 345.449591] hns-nic HISI00C2:01 eth1: link up > root@(none)$ ping 172.18.45.23 > PING 172.18.45.23 (172.18.45.23): 56 data bytes > 64 bytes from 172.18.45.23: seq=0 ttl=64 time=2026.837 ms > 64 bytes from 172.18.45.23: seq=1 ttl=64 time=1026.843 ms > 64 bytes from 172.18.45.23: seq=2 ttl=64 time=26.834 ms > 64 bytes from 172.18.45.23: seq=3 ttl=64 time=0.075 ms > 64 bytes from 172.18.45.23: seq=4 ttl=64 time=0.079 ms > ^C > --- 172.18.45.23 ping statistics --- > 5 packets transmitted, 5 packets received, 0% packet loss > round-trip min/avg/max = 0.075/616.133/2026.837 ms > > > > Integrated Storage controller: > root@(none)$ fdisk -l > Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0xdb9f5cd0 > > Device Boot Start End Blocks Id System > /dev/sdb1 2048 209717247 104857600 83 Linux > /dev/sdb2 209717248 419432447 104857600 83 Linux > > > Disk /dev/sda: 186.3 GiB, 200049647616 bytes, 390721968 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 131072 bytes > > Disk /dev/sdc: 186.3 GiB, 200049647616 bytes, 390721968 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 131072 bytes > > Disk /dev/sdd: 186.3 GiB, 200049647616 bytes, 390721968 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 131072 bytes > > Disk /dev/sde: 186.3 GiB, 200049647616 bytes, 390721968 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 131072 bytes > > Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 131072 bytes > > root@(none)$ > > Looks ok Great, thanks ! > @majun, please test as well. Yes, final test, PR is ready to be sent, I reviewed Hanjun patches but I just want to avoid breaking them given that we had to carry out changes for the split PR. Thanks, Lorenzo > > Thanks, > John > > >Lorenzo > > > >>The log is as below: > >> > >> estuary:/$ dmesg > >> [ 0.000000] Booting Linux on physical CPU 0x10000 > >> [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017 > >> [ 0.000000] Boot CPU: AArch64 Processor [410fd082] > >> [ 0.000000] efi: Getting EFI parameters from FDT: > >> [ 0.000000] efi: EFI v2.60 by EDK II > >> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098 > >> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000 > >> > >> > >> estuary:/$ ping 192.168.1.107 > >> PING 192.168.1.107 (192.168.1.107): 56 data bytes > >> 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms > >> 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms > >> 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms > >> 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms > >> ^C > >> --- 192.168.1.107 ping statistics --- > >> 4 packets transmitted, 4 packets received, 0% packet loss > >> round-trip min/avg/max = 0.098/0.144/0.273 ms > >> > >> estuary:/$ lspci -mk > >> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000" > >> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" > >> > >> estuary:/$ cat /dev/sd > >> sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl > >> sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1 > >> > >>Best Regards, > >>Wei > >> > >>> > >>>Thanks > >>>Hanjun > >>> > >>>. > >>> > >> > >_______________________________________________ > >linuxarm mailing list > >linuxarm@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lorenzo: 在 2017/3/31 0:54, Lorenzo Pieralisi 写道: > On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote: >> >>>>>>> >>>>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework >>>>>>> this patch and post the resulting branch for everyone to have a final >>>>>>> test. [...] >>>> >>>> Thanks to all of you! >>>> Tested on D05 board with this branch, the SAS disks and XGE port are working fine. >>> >>> Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull >>> request to Catalin tomorrow, please carry out last few checks before >>> I send it: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git tags/acpi-arm64-for-v4.12 >>> >>> You should try to merge it with Marc's branch: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-4.12 >>> >>> and test the resulting branch, that's how they will go upstream. >>> >>> Please let me know, thank you for your help ! >>> >> >> Hi Lorenzo, >> >> xuwei is away now, and it is night time with majun, so I tested. >> majun can retest tomorrow again to triple-check. I did not touch the >> ITS patch Marc made which had the weak version of >> iort_pmis_get_dev_id(), but it should not affect anything in my >> test. >> >> After merging your tag to Marc's branch, here is the git log: >> git log --oneline >> 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12 >> d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device >> ae7c183 ACPI: platform-msi: retrieve devid from IORT >> e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support >> 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id >> 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic >> d11349c irqchip: mbigen: Add ACPI support >> aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain() >> 964bac1 irqchip: mbigen: drop module owner >> b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware >> d264edb irqchip: gicv3-its: platform-msi: scan MADT to create >> platform msi domain >> baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() >> to prepare for ACPI >> fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare() >> cc9eb0d irqchip: gic-v3-its: keep the include header files in >> alphabetic order >> ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type >> ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number >> 3382357 dt-bindings: mediatek: multiple bases support for sysirq >> 4015616 irqchip: replace moxa with ftintc010 >> 532278c irqchip: faraday: fix the trigger types >> 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin >> 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin >> c02ed2e Linux 4.11-rc4 >> >> And some testing: >> [...] >> >> Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors >> Units: sectors of 1 * 512 = 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 131072 bytes >> >> root@(none)$ >> >> Looks ok > > Great, thanks ! > >> @majun, please test as well. > > Yes, final test, PR is ready to be sent, I reviewed Hanjun patches > but I just want to avoid breaking them given that we had to carry > out changes for the split PR. > I tested these patches again as you suggested, all of the related devices， xge/sas/usb/uart, are working fine on my hisilicon board just like before. The git log is: 565fdf3 Merge tag 'acpi-arm64-for-v4.12' into marc-irq-4.12 d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device ae7c183 ACPI: platform-msi: retrieve devid from IORT e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic d11349c irqchip: mbigen: Add ACPI support aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain() 964bac1 irqchip: mbigen: drop module owner b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare() cc9eb0d irqchip: gic-v3-its: keep the include header files in alphabetic order ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number 3382357 dt-bindings: mediatek: multiple bases support for sysirq 4015616 irqchip: replace moxa with ftintc010 532278c irqchip: faraday: fix the trigger types 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin c02ed2e Linux 4.11-rc4 Thanks Ma Jun > Thanks, > Lorenzo > >> >> Thanks, >> John >> >>> Lorenzo >>> >>>> The log is as below: >>>> >>>> estuary:/$ dmesg >>>> [ 0.000000] Booting Linux on physical CPU 0x10000 >>>> [ 0.000000] Linux version 4.11.0-rc3-14418-gea60d0a (xuwei@EstBuildSvr1) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #28 SMP PREEMPT Thu Mar 30 16:15:42 CST 2017 >>>> [ 0.000000] Boot CPU: AArch64 Processor [410fd082] >>>> [ 0.000000] efi: Getting EFI parameters from FDT: >>>> [ 0.000000] efi: EFI v2.60 by EDK II >>>> [ 0.000000] efi: SMBIOS=0x3f040000 SMBIOS 3.0=0x39af0000 ACPI=0x39bc0000 ACPI 2.0=0x39bc0014 MEMATTR=0x3ccb0098 >>>> [ 0.000000] cma: Reserved 16 MiB at 0x000000003e000000 >>>> >>>> >>>> estuary:/$ ping 192.168.1.107 >>>> PING 192.168.1.107 (192.168.1.107): 56 data bytes >>>> 64 bytes from 192.168.1.107: seq=0 ttl=64 time=0.273 ms >>>> 64 bytes from 192.168.1.107: seq=1 ttl=64 time=0.102 ms >>>> 64 bytes from 192.168.1.107: seq=2 ttl=64 time=0.103 ms >>>> 64 bytes from 192.168.1.107: seq=3 ttl=64 time=0.098 ms >>>> ^C >>>> --- 192.168.1.107 ping statistics --- >>>> 4 packets transmitted, 4 packets received, 0% packet loss >>>> round-trip min/avg/max = 0.098/0.144/0.273 ms >>>> >>>> estuary:/$ lspci -mk >>>> 30:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> 91:00.0 "Class 0300" "19e5" "1711" "0000" "0000" >>>> 90:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> 20:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> 10:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> 80:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> 00:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> c0:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> 88:00.0 "Class 0604" "19e5" "1610" "0000" "0000" "pcieport" >>>> >>>> estuary:/$ cat /dev/sd >>>> sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl >>>> sda1 sdb1 sdc1 sdd1 sde1 sdf1 sdg1 sdh1 sdi1 sdj1 sdk1 sdl1 >>>> >>>> Best Regards, >>>> Wei >>>> >>>>> >>>>> Thanks >>>>> Hanjun >>>>> >>>>> . >>>>> >>>> >>> _______________________________________________ >>> linuxarm mailing list >>> linuxarm@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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 83cd59d..fb95ceb 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -468,6 +468,30 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id) } /** + * iort_pmsi_get_dev_id() - Get the device id for a device + * @dev: The device for which the mapping is to be done. + * @dev_id: The device ID found. + * + * Returns: 0 for successful find a dev id, -ENODEV on error + */ +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id) +{ + int i; + struct acpi_iort_node *node; + + node = iort_find_dev_node(dev); + if (!node) + return -ENODEV; + + for (i = 0; i < node->mapping_count; i++) { + if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i)) + return 0; + } + + return -ENODEV; +} + +/** * iort_dev_find_its_id() - Find the ITS identifier for a device * @dev: The device. * @req_id: Device's requester ID diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c index e4ba9f4..e801fc0 100644 --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c @@ -57,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, msi_info = msi_get_domain_info(domain->parent); - ret = of_pmsi_get_dev_id(domain, dev, &dev_id); + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) : + iort_pmsi_get_dev_id(dev, &dev_id); if (ret) return ret; diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h index 77e0809..d074c77 100644 --- a/include/linux/acpi_iort.h +++ b/include/linux/acpi_iort.h @@ -34,6 +34,7 @@ bool iort_node_match(u8 type); u32 iort_msi_map_rid(struct device *dev, u32 req_id); struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id); +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id); /* IOMMU interface */ void iort_set_dma_mask(struct device *dev); const struct iommu_ops *iort_iommu_configure(struct device *dev); @@ -45,6 +46,10 @@ static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id) static inline struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id) { return NULL; } + +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id) +{ return -ENODEV; } + /* IOMMU interface */ static inline void iort_set_dma_mask(struct device *dev) { } static inline