From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> Cc: Neil Leeder <nleeder@codeaurora.org>, Mark Langsdorf <mlangsdo@redhat.com>, Jon Masters <jcm@redhat.com>, Timur Tabi <timur@codeaurora.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Mark Brown <broonie@kernel.org>, Mark Salter <msalter@redhat.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Will Deacon <will.deacon@arm.com>, Mark Rutland <mark.rutland@arm.com>, Linuxarm <linuxarm@huawei.com> Subject: Re: [PATCH 1/2] acpi: arm64: add iort support for PMCG Date: Tue, 30 Jan 2018 18:00:13 +0000 [thread overview] Message-ID: <20180130180013.GA16154@e107981-ln.cambridge.arm.com> (raw) In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8386400F7@FRAEML521-MBX.china.huawei.com> On Tue, Jan 30, 2018 at 10:39:20AM +0000, Shameerali Kolothum Thodi wrote: > Hi Neil/Lorenzo, > > > -----Original Message----- > > From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@lists.infradead.org] > > On Behalf Of Neil Leeder > > Sent: Friday, August 04, 2017 8:59 PM > > To: Will Deacon <will.deacon@arm.com>; Mark Rutland > > <mark.rutland@arm.com> > > Cc: Mark Langsdorf <mlangsdo@redhat.com>; Jon Masters > > <jcm@redhat.com>; Timur Tabi <timur@codeaurora.org>; linux- > > kernel@vger.kernel.org; Mark Brown <broonie@kernel.org>; Mark Salter > > <msalter@redhat.com>; nleeder@codeaurora.org; linux-arm- > > kernel@lists.infradead.org > > Subject: [PATCH 1/2] acpi: arm64: add iort support for PMCG > > > > Add support for the SMMU Performance Monitor Counter Group > > information from ACPI. This is in preparation for its use > > in the SMMU v3 PMU driver. > > [...] > > > static __init > > const struct iort_iommu_config *iort_get_iommu_cfg(struct acpi_iort_node > > *node) > > { > > @@ -1001,6 +1041,8 @@ const struct iort_iommu_config > > *iort_get_iommu_cfg(struct acpi_iort_node *node) > > return &iort_arm_smmu_v3_cfg; > > case ACPI_IORT_NODE_SMMU: > > return &iort_arm_smmu_cfg; > > + case ACPI_IORT_NODE_PMCG: > > + return &iort_arm_smmu_pmcg_cfg; > > I understand this series will be revised based on the iort spec update. > > This Is to clarify few queries we have with respect to one of our hisilicon > platform which has support for SMMU v3 PMCG. In our implementation > the base address for the PMCG is defined at a IMP DEF address offset > within the SMMUv3 page 0 address space. And as per SMMU spec, > > " The Performance Monitor Counter Groups are standalone monitoring > facilities and, as such, can be implemented in separate components that > are all associated with (but not necessarily part of) an SMMU" > > It looks like PMCG can be part of SMMU, it is not clear whether this kind > of address mapping is forbidden or not. If this is an accepted scenario, then > the devm_ioremap_resource() call in SMMv3 probe will fail as it reports conflict. > > As far as I can see, the above code just checks the iort node type is PMCG > and assumes that its SMMU PMCG. As per IORT spec, it make sense to check > the node reference filed and make that call. > > And to fix the resource conflict issue we have, is it possible to treat the PMCG > node as the child of the SMMU and call the platform_device_add() appropriately > to avoid the conflict? I am not sure this will fix the issue and also about the order > in which SMMU and PMCG devices will be populated will have an impact on this. > > Please let me know your thoughts on this. I went back and re-read the patches, I think the point here is that the perf driver (ie PATCH 2 that, by the way, is not maiinline) uses devm_ioremap_resource() to map the counters and that's what is causing failures when PMCG is part of SMMUv3 registers. It is the resources hierarchy that is wrong and in turn, I do not think devm_request_mem_region() is the right way of requesting it for the PMCG driver. I need to look into this but I suspect that's something that should be handled in the PMCG driver, that has to request the memory region _differently_ (ie ioremap copes with this overlap - it is the devm_request_mem_region() in devm_ioremap_resource() that fails, correct ?). Certainly we need to create in IORT the resources with the correct hierarchy (I reckon DT does it already if the right device hierarchy is specified). Lorenzo > > Thanks, > Shameer > > > default: > > return NULL; > > } > > @@ -1056,6 +1098,15 @@ static int __init > > iort_add_smmu_platform_device(struct acpi_iort_node *node) > > if (ret) > > goto dev_put; > > > > + /* End of init for PMCG */ > > + if (node->type == ACPI_IORT_NODE_PMCG) { > > + ret = platform_device_add(pdev); > > + if (ret) > > + goto dev_put; > > + > > + return 0; > > + } > > + > > /* > > * We expect the dma masks to be equivalent for > > * all SMMUs set-ups > > @@ -1131,6 +1182,9 @@ static void __init iort_init_platform_devices(void) > > acpi_free_fwnode_static(fwnode); > > return; > > } > > + } else if (iort_node->type == ACPI_IORT_NODE_PMCG) { > > + if (iort_add_smmu_platform_device(iort_node)) > > + return; > > } > > > > iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node, > > diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h > > index 707dda74..2169b6f 100644 > > --- a/include/acpi/actbl2.h > > +++ b/include/acpi/actbl2.h > > @@ -695,7 +695,8 @@ enum acpi_iort_node_type { > > ACPI_IORT_NODE_NAMED_COMPONENT = 0x01, > > ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02, > > ACPI_IORT_NODE_SMMU = 0x03, > > - ACPI_IORT_NODE_SMMU_V3 = 0x04 > > + ACPI_IORT_NODE_SMMU_V3 = 0x04, > > + ACPI_IORT_NODE_PMCG = 0x05 > > }; > > > > struct acpi_iort_id_mapping { > > @@ -811,6 +812,12 @@ struct acpi_iort_smmu_v3 { > > #define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE (1) > > #define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1) > > > > +struct acpi_iort_pmcg { > > + u64 base_address; /* PMCG base address */ > > + u32 overflow_gsiv; > > + u32 node_reference; > > +}; > > + > > > > /**************************************************************** > > *************** > > * > > * IVRS - I/O Virtualization Reporting Structure > > -- > > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > > Technologies Inc. > > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, > > a Linux Foundation Collaborative Project. > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/2] acpi: arm64: add iort support for PMCG Date: Tue, 30 Jan 2018 18:00:13 +0000 [thread overview] Message-ID: <20180130180013.GA16154@e107981-ln.cambridge.arm.com> (raw) In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8386400F7@FRAEML521-MBX.china.huawei.com> On Tue, Jan 30, 2018 at 10:39:20AM +0000, Shameerali Kolothum Thodi wrote: > Hi Neil/Lorenzo, > > > -----Original Message----- > > From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] > > On Behalf Of Neil Leeder > > Sent: Friday, August 04, 2017 8:59 PM > > To: Will Deacon <will.deacon@arm.com>; Mark Rutland > > <mark.rutland@arm.com> > > Cc: Mark Langsdorf <mlangsdo@redhat.com>; Jon Masters > > <jcm@redhat.com>; Timur Tabi <timur@codeaurora.org>; linux- > > kernel at vger.kernel.org; Mark Brown <broonie@kernel.org>; Mark Salter > > <msalter@redhat.com>; nleeder at codeaurora.org; linux-arm- > > kernel at lists.infradead.org > > Subject: [PATCH 1/2] acpi: arm64: add iort support for PMCG > > > > Add support for the SMMU Performance Monitor Counter Group > > information from ACPI. This is in preparation for its use > > in the SMMU v3 PMU driver. > > [...] > > > static __init > > const struct iort_iommu_config *iort_get_iommu_cfg(struct acpi_iort_node > > *node) > > { > > @@ -1001,6 +1041,8 @@ const struct iort_iommu_config > > *iort_get_iommu_cfg(struct acpi_iort_node *node) > > return &iort_arm_smmu_v3_cfg; > > case ACPI_IORT_NODE_SMMU: > > return &iort_arm_smmu_cfg; > > + case ACPI_IORT_NODE_PMCG: > > + return &iort_arm_smmu_pmcg_cfg; > > I understand this series will be revised based on the iort spec update. > > This Is to clarify few queries we have with respect to one of our hisilicon > platform which has support for SMMU v3 PMCG. In our implementation > the base address for the PMCG is defined at a IMP DEF address offset > within the SMMUv3 page 0 address space. And as per SMMU spec, > > " The Performance Monitor Counter Groups are standalone monitoring > facilities and, as such, can be implemented in separate components that > are all associated with (but not necessarily part of) an SMMU" > > It looks like PMCG can be part of SMMU, it is not clear whether this kind > of address mapping is forbidden or not. If this is an accepted scenario, then > the devm_ioremap_resource() call in SMMv3 probe will fail as it reports conflict. > > As far as I can see, the above code just checks the iort node type is PMCG > and assumes that its SMMU PMCG. As per IORT spec, it make sense to check > the node reference filed and make that call. > > And to fix the resource conflict issue we have, is it possible to treat the PMCG > node as the child of the SMMU and call the platform_device_add() appropriately > to avoid the conflict? I am not sure this will fix the issue and also about the order > in which SMMU and PMCG devices will be populated will have an impact on this. > > Please let me know your thoughts on this. I went back and re-read the patches, I think the point here is that the perf driver (ie PATCH 2 that, by the way, is not maiinline) uses devm_ioremap_resource() to map the counters and that's what is causing failures when PMCG is part of SMMUv3 registers. It is the resources hierarchy that is wrong and in turn, I do not think devm_request_mem_region() is the right way of requesting it for the PMCG driver. I need to look into this but I suspect that's something that should be handled in the PMCG driver, that has to request the memory region _differently_ (ie ioremap copes with this overlap - it is the devm_request_mem_region() in devm_ioremap_resource() that fails, correct ?). Certainly we need to create in IORT the resources with the correct hierarchy (I reckon DT does it already if the right device hierarchy is specified). Lorenzo > > Thanks, > Shameer > > > default: > > return NULL; > > } > > @@ -1056,6 +1098,15 @@ static int __init > > iort_add_smmu_platform_device(struct acpi_iort_node *node) > > if (ret) > > goto dev_put; > > > > + /* End of init for PMCG */ > > + if (node->type == ACPI_IORT_NODE_PMCG) { > > + ret = platform_device_add(pdev); > > + if (ret) > > + goto dev_put; > > + > > + return 0; > > + } > > + > > /* > > * We expect the dma masks to be equivalent for > > * all SMMUs set-ups > > @@ -1131,6 +1182,9 @@ static void __init iort_init_platform_devices(void) > > acpi_free_fwnode_static(fwnode); > > return; > > } > > + } else if (iort_node->type == ACPI_IORT_NODE_PMCG) { > > + if (iort_add_smmu_platform_device(iort_node)) > > + return; > > } > > > > iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node, > > diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h > > index 707dda74..2169b6f 100644 > > --- a/include/acpi/actbl2.h > > +++ b/include/acpi/actbl2.h > > @@ -695,7 +695,8 @@ enum acpi_iort_node_type { > > ACPI_IORT_NODE_NAMED_COMPONENT = 0x01, > > ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02, > > ACPI_IORT_NODE_SMMU = 0x03, > > - ACPI_IORT_NODE_SMMU_V3 = 0x04 > > + ACPI_IORT_NODE_SMMU_V3 = 0x04, > > + ACPI_IORT_NODE_PMCG = 0x05 > > }; > > > > struct acpi_iort_id_mapping { > > @@ -811,6 +812,12 @@ struct acpi_iort_smmu_v3 { > > #define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE (1) > > #define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1) > > > > +struct acpi_iort_pmcg { > > + u64 base_address; /* PMCG base address */ > > + u32 overflow_gsiv; > > + u32 node_reference; > > +}; > > + > > > > /**************************************************************** > > *************** > > * > > * IVRS - I/O Virtualization Reporting Structure > > -- > > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > > Technologies Inc. > > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, > > a Linux Foundation Collaborative Project. > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel at lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2018-01-30 18:00 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-04 19:59 [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support Neil Leeder 2017-08-04 19:59 ` Neil Leeder 2017-08-04 19:59 ` [PATCH 1/2] acpi: arm64: add iort support for PMCG Neil Leeder 2017-08-04 19:59 ` Neil Leeder 2017-08-07 11:17 ` Robin Murphy 2017-08-07 11:17 ` Robin Murphy 2017-08-07 20:52 ` Leeder, Neil 2017-08-07 20:52 ` Leeder, Neil 2017-08-07 16:44 ` Lorenzo Pieralisi 2017-08-07 16:44 ` Lorenzo Pieralisi 2017-08-07 21:00 ` Leeder, Neil 2017-08-07 21:00 ` Leeder, Neil 2018-01-30 10:39 ` Shameerali Kolothum Thodi 2018-01-30 10:39 ` Shameerali Kolothum Thodi 2018-01-30 18:00 ` Lorenzo Pieralisi [this message] 2018-01-30 18:00 ` Lorenzo Pieralisi 2018-01-31 12:10 ` Shameerali Kolothum Thodi 2018-01-31 12:10 ` Shameerali Kolothum Thodi 2018-01-31 12:34 ` Lorenzo Pieralisi 2018-01-31 12:34 ` Lorenzo Pieralisi 2017-08-04 19:59 ` [PATCH 2/2] perf: add arm64 smmuv3 pmu driver Neil Leeder 2017-08-04 19:59 ` Neil Leeder 2017-08-07 14:31 ` Robin Murphy 2017-08-07 14:31 ` Robin Murphy 2017-08-07 21:18 ` Leeder, Neil 2017-08-07 21:18 ` Leeder, Neil 2017-12-05 5:01 ` Linu Cherian 2017-12-05 5:01 ` Linu Cherian 2018-03-29 7:03 ` Yisheng Xie 2018-03-29 7:03 ` Yisheng Xie [not found] ` <e55ab4404143ea0b3cc4795a93e37480@codeaurora.org> 2018-04-01 5:44 ` Neil Leeder 2018-04-01 5:44 ` Neil Leeder 2018-04-02 6:37 ` Yisheng Xie 2018-04-02 6:37 ` Yisheng Xie 2018-04-02 14:24 ` Hanjun Guo 2018-04-02 14:24 ` Hanjun Guo 2018-04-02 17:59 ` Neil Leeder 2018-04-02 17:59 ` Neil Leeder 2018-04-03 1:15 ` Hanjun Guo 2018-04-03 1:15 ` Hanjun Guo 2018-04-04 11:35 ` Lorenzo Pieralisi 2018-04-04 11:35 ` Lorenzo Pieralisi 2018-05-02 14:20 ` Agustin Vega-Frias 2018-05-02 14:20 ` Agustin Vega-Frias 2018-05-03 9:22 ` Shameerali Kolothum Thodi 2018-05-03 9:22 ` Shameerali Kolothum Thodi 2018-04-18 11:05 ` Shameerali Kolothum Thodi 2018-04-18 11:05 ` Shameerali Kolothum Thodi 2018-04-19 1:17 ` Yisheng Xie 2018-04-19 1:17 ` Yisheng Xie 2017-08-09 7:56 ` [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support Hanjun Guo 2017-08-09 7:56 ` Hanjun Guo 2017-08-09 15:48 ` Leeder, Neil 2017-08-09 15:48 ` Leeder, Neil 2017-08-10 1:26 ` Hanjun Guo 2017-08-10 1:26 ` Hanjun Guo 2017-08-11 3:28 ` Leeder, Neil 2017-08-11 3:28 ` Leeder, Neil 2017-10-12 10:58 ` Hanjun Guo 2017-10-12 10:58 ` Hanjun Guo 2017-10-12 11:05 ` Lorenzo Pieralisi 2017-10-12 11:05 ` Lorenzo Pieralisi 2017-10-12 11:11 ` Hanjun Guo 2017-10-12 11:11 ` Hanjun Guo 2017-10-31 23:33 ` Yury Norov 2017-10-31 23:33 ` Yury Norov 2017-11-02 20:38 ` Leeder, Neil 2017-11-02 20:38 ` Leeder, Neil 2017-12-10 2:35 ` Linu Cherian 2017-12-10 2:35 ` Linu Cherian 2017-12-18 14:48 ` Robin Murphy 2017-12-18 14:48 ` Robin Murphy 2017-12-18 15:39 ` Marc Zyngier 2017-12-18 15:39 ` Marc Zyngier 2017-12-19 6:55 ` Linu Cherian 2017-12-19 6:55 ` Linu Cherian 2017-12-19 12:11 ` Marc Zyngier 2017-12-19 12:11 ` Marc Zyngier 2017-12-19 6:36 ` Linu Cherian 2017-12-19 6:36 ` Linu Cherian
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180130180013.GA16154@e107981-ln.cambridge.arm.com \ --to=lorenzo.pieralisi@arm.com \ --cc=broonie@kernel.org \ --cc=jcm@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxarm@huawei.com \ --cc=mark.rutland@arm.com \ --cc=mlangsdo@redhat.com \ --cc=msalter@redhat.com \ --cc=nleeder@codeaurora.org \ --cc=shameerali.kolothum.thodi@huawei.com \ --cc=timur@codeaurora.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.