| Message ID | 20210127113258.1421-1-thunder.leizhen@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | perf/smmuv3: Don't reserve the PMCG register spaces | expand |
On Wed, Jan 27, 2021 at 07:32:55PM +0800, Zhen Lei wrote: > v2 --> v3: > Patch 3 is updated because https://lkml.org/lkml/2021/1/22/532 has been queued in advance. > > v1 --> v2: > According to Robin Murphy's suggestion: https://lkml.org/lkml/2021/1/20/470 > Don't reserve the PMCG register spaces, and reserve the entire SMMU register space. > > v1: > Since the PMCG may implement its resigters space(4KB Page0 and 4KB Page1) > within the SMMUv3 64KB Page0. In this case, when the SMMUv3 driver reserves the > 64KB Page0 resource in advance, the PMCG driver try to reserve its Page0 and > Page1 resources, a resource conflict occurs. > > commit 52f3fab0067d6fa ("iommu/arm-smmu-v3: Don't reserve implementation > defined register space") reduce the resource reservation range of the SMMUv3 > driver, it only reserves the first 0xe00 bytes in the 64KB Page0, to avoid > the above-mentioned resource conflicts. > > But the SMMUv3.3 add support for ECMDQ, its registers space is also implemented > in the SMMUv3 64KB Page0. This means we need to build two separate mappings. > New features may be added in the future, and more independent mappings may be > required. The simple problem is complicated because the user expects to map the > entire SMMUv3 64KB Page0. > > Therefore, the proper solution is: If the PMCG register resources are located in > the 64KB Page0 of the SMMU, the PMCG driver does not reserve the conflict resources > when the SMMUv3 driver has reserved the conflict resources before. Instead, the PMCG > driver only performs devm_ioremap() to ensure that it can work properly. > > Zhen Lei (3): > perf/smmuv3: Don't reserve the PMCG register spaces > perf/smmuv3: Add a MODULE_SOFTDEP() to indicate dependency on SMMU > iommu/arm-smmu-v3: Reserving the entire SMMU register space I'll need Robin's ack on these. Will
On 2021/1/29 4:31, Will Deacon wrote: > On Wed, Jan 27, 2021 at 07:32:55PM +0800, Zhen Lei wrote: >> v2 --> v3: >> Patch 3 is updated because https://lkml.org/lkml/2021/1/22/532 has been queued in advance. >> >> v1 --> v2: >> According to Robin Murphy's suggestion: https://lkml.org/lkml/2021/1/20/470 >> Don't reserve the PMCG register spaces, and reserve the entire SMMU register space. >> >> v1: >> Since the PMCG may implement its resigters space(4KB Page0 and 4KB Page1) >> within the SMMUv3 64KB Page0. In this case, when the SMMUv3 driver reserves the >> 64KB Page0 resource in advance, the PMCG driver try to reserve its Page0 and >> Page1 resources, a resource conflict occurs. >> >> commit 52f3fab0067d6fa ("iommu/arm-smmu-v3: Don't reserve implementation >> defined register space") reduce the resource reservation range of the SMMUv3 >> driver, it only reserves the first 0xe00 bytes in the 64KB Page0, to avoid >> the above-mentioned resource conflicts. >> >> But the SMMUv3.3 add support for ECMDQ, its registers space is also implemented >> in the SMMUv3 64KB Page0. This means we need to build two separate mappings. >> New features may be added in the future, and more independent mappings may be >> required. The simple problem is complicated because the user expects to map the >> entire SMMUv3 64KB Page0. >> >> Therefore, the proper solution is: If the PMCG register resources are located in >> the 64KB Page0 of the SMMU, the PMCG driver does not reserve the conflict resources >> when the SMMUv3 driver has reserved the conflict resources before. Instead, the PMCG >> driver only performs devm_ioremap() to ensure that it can work properly. >> >> Zhen Lei (3): >> perf/smmuv3: Don't reserve the PMCG register spaces >> perf/smmuv3: Add a MODULE_SOFTDEP() to indicate dependency on SMMU >> iommu/arm-smmu-v3: Reserving the entire SMMU register space > > I'll need Robin's ack on these. Hi, Robin: What's your opinion? In fact, I have written the patches that SMMU and PMCG whoever come first will reserve the resources, and whoever comes next does not reserve. However, the processing logic is relatively complex. > > Will > > . >
v2 --> v3: Patch 3 is updated because https://lkml.org/lkml/2021/1/22/532 has been queued in advance. v1 --> v2: According to Robin Murphy's suggestion: https://lkml.org/lkml/2021/1/20/470 Don't reserve the PMCG register spaces, and reserve the entire SMMU register space. v1: Since the PMCG may implement its resigters space(4KB Page0 and 4KB Page1) within the SMMUv3 64KB Page0. In this case, when the SMMUv3 driver reserves the 64KB Page0 resource in advance, the PMCG driver try to reserve its Page0 and Page1 resources, a resource conflict occurs. commit 52f3fab0067d6fa ("iommu/arm-smmu-v3: Don't reserve implementation defined register space") reduce the resource reservation range of the SMMUv3 driver, it only reserves the first 0xe00 bytes in the 64KB Page0, to avoid the above-mentioned resource conflicts. But the SMMUv3.3 add support for ECMDQ, its registers space is also implemented in the SMMUv3 64KB Page0. This means we need to build two separate mappings. New features may be added in the future, and more independent mappings may be required. The simple problem is complicated because the user expects to map the entire SMMUv3 64KB Page0. Therefore, the proper solution is: If the PMCG register resources are located in the 64KB Page0 of the SMMU, the PMCG driver does not reserve the conflict resources when the SMMUv3 driver has reserved the conflict resources before. Instead, the PMCG driver only performs devm_ioremap() to ensure that it can work properly. Zhen Lei (3): perf/smmuv3: Don't reserve the PMCG register spaces perf/smmuv3: Add a MODULE_SOFTDEP() to indicate dependency on SMMU iommu/arm-smmu-v3: Reserving the entire SMMU register space drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 24 ++++-------------------- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 -- drivers/perf/arm_smmuv3_pmu.c | 28 ++++++++++++++++++++++++++-- 3 files changed, 30 insertions(+), 24 deletions(-)