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