Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 19/12/17 06:55, Linu Cherian wrote: > Hi Marc, > > On Mon Dec 18, 2017 at 03:39:22PM +, Marc Zyngier wrote: >> Thanks for putting me in the loop Robin. >> >> On 18/12/17 14:48, Robin Murphy wrote: >>> On 10/12/17 02:35, Linu Cherian wrote: Hi, On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. This would be a matter of concern for software if the SMMU and SMMU PMCG blocks are managed by two independent drivers. The problem arises when we want to alloc/free MSIs for these devices using the APIs, platform_msi_domain_alloc/free_irqs. Platform bus id being same for these two hardware blocks, they end up sharing the same ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management of this shared ITT becomes a problem when they are managed by two independent drivers. >>> >>> What is the problem exactly? IIRC resizing a possibly-live ITT is a >>> right pain in the bum to do - is it just that? >> >> Understatement of the day! ;-) Yes, it is a massive headache, and will >> either result in a temporary loss of interrupts (at some point you have >> to unmap the ITT), or with spurious interrupts (you generate interrupts >> for all the MSIs you've blackholed when unmapping the ITT). > > Just sharing a thought. > > If the firmware, through device tree/ACPI > can provide the following input to the ITS driver, > (For example, as part of msi-parent property in device tree) > > 1. flag indicating the ITT (Device ID) is being shared > 2. the maximum number of vectors that are required to be allocated for this > ITT > > resizing of ITT and the associated complexities could be avoided. I'm not sure it is that simple. First, this is a change of the spec, and we need to support the current states of ACPI and DT. In any case, this would need to affect all nodes. Then, MSIs are very dynamic, and there may be decision that SW makes at runtime that would change the parameters of the ITT allocation (platform_msi_domain_alloc_irqs does take an nvec parameter that could override firmware data -- what if all the drivers do that?). Finally, and assuming we still want to go in that direction, I'd rather have each node describing its maximum MSI allocation and let the ITS driver sum it up, much like we do it on PCI. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 19/12/17 06:55, Linu Cherian wrote: > Hi Marc, > > On Mon Dec 18, 2017 at 03:39:22PM +, Marc Zyngier wrote: >> Thanks for putting me in the loop Robin. >> >> On 18/12/17 14:48, Robin Murphy wrote: >>> On 10/12/17 02:35, Linu Cherian wrote: Hi, On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. This would be a matter of concern for software if the SMMU and SMMU PMCG blocks are managed by two independent drivers. The problem arises when we want to alloc/free MSIs for these devices using the APIs, platform_msi_domain_alloc/free_irqs. Platform bus id being same for these two hardware blocks, they end up sharing the same ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management of this shared ITT becomes a problem when they are managed by two independent drivers. >>> >>> What is the problem exactly? IIRC resizing a possibly-live ITT is a >>> right pain in the bum to do - is it just that? >> >> Understatement of the day! ;-) Yes, it is a massive headache, and will >> either result in a temporary loss of interrupts (at some point you have >> to unmap the ITT), or with spurious interrupts (you generate interrupts >> for all the MSIs you've blackholed when unmapping the ITT). > > Just sharing a thought. > > If the firmware, through device tree/ACPI > can provide the following input to the ITS driver, > (For example, as part of msi-parent property in device tree) > > 1. flag indicating the ITT (Device ID) is being shared > 2. the maximum number of vectors that are required to be allocated for this > ITT > > resizing of ITT and the associated complexities could be avoided. I'm not sure it is that simple. First, this is a change of the spec, and we need to support the current states of ACPI and DT. In any case, this would need to affect all nodes. Then, MSIs are very dynamic, and there may be decision that SW makes at runtime that would change the parameters of the ITT allocation (platform_msi_domain_alloc_irqs does take an nvec parameter that could override firmware data -- what if all the drivers do that?). Finally, and assuming we still want to go in that direction, I'd rather have each node describing its maximum MSI allocation and let the ITS driver sum it up, much like we do it on PCI. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Marc, On Mon Dec 18, 2017 at 03:39:22PM +, Marc Zyngier wrote: > Thanks for putting me in the loop Robin. > > On 18/12/17 14:48, Robin Murphy wrote: > > On 10/12/17 02:35, Linu Cherian wrote: > >> Hi, > >> > >> > >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>> This adds a driver for the SMMUv3 PMU into the perf framework. > >>> It includes an IORT update to support PM Counter Groups. > >>> > >> > >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way > >> that platform bus id (Device ID in ITS terminmology)is shared with that of > >> SMMU. > >> This would be a matter of concern for software if the SMMU and SMMU PMCG > >> blocks > >> are managed by two independent drivers. > >> > >> The problem arises when we want to alloc/free MSIs for these devices > >> using the APIs, platform_msi_domain_alloc/free_irqs. > >> Platform bus id being same for these two hardware blocks, they end up > >> sharing the same > >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and > >> management > >> of this shared ITT becomes a problem when they are managed by two > >> independent > >> drivers. > > > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > > right pain in the bum to do - is it just that? > > Understatement of the day! ;-) Yes, it is a massive headache, and will > either result in a temporary loss of interrupts (at some point you have > to unmap the ITT), or with spurious interrupts (you generate interrupts > for all the MSIs you've blackholed when unmapping the ITT). Just sharing a thought. If the firmware, through device tree/ACPI can provide the following input to the ITS driver, (For example, as part of msi-parent property in device tree) 1. flag indicating the ITT (Device ID) is being shared 2. the maximum number of vectors that are required to be allocated for this ITT resizing of ITT and the associated complexities could be avoided. > > > > >> We were looking into the option of keeping the SMMU PMCG nodes as sub > >> nodes under > >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total > >> vectors > >> required for SMMU PMCG devices and make a common > >> platform_msi_domain_alloc/free_irqs > >> function call for all devices that share the platform bus id. > > > > I'm not sure how scalable that approach would be, since it's not > > entirely obvious how to handle PMCGs associated with named components or > > root complexes (rather than directly with SMMU instances). We certainly > > don't want to end up spraying similar PMCG DevID logic around all manner > > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs > > will be expected to have distinct IDs from their host devices, they > > could reasonably still overlap with other PMCGs/SMMUs). > > > >> Would like to know your expert opinion on what would be the right approach > >> to handle this case ? > > > > My gut feeling says the way to deal with this properly is in the ITS > > code, but I appreciate that that's a lot easier said than done :/ > > I can revive the hack I once wrote for that (and that was hoping to > forever forget), but that's pretty disgusting, and subject to the above > caveat. > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... -- Linu cherian
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Marc, On Mon Dec 18, 2017 at 03:39:22PM +, Marc Zyngier wrote: > Thanks for putting me in the loop Robin. > > On 18/12/17 14:48, Robin Murphy wrote: > > On 10/12/17 02:35, Linu Cherian wrote: > >> Hi, > >> > >> > >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>> This adds a driver for the SMMUv3 PMU into the perf framework. > >>> It includes an IORT update to support PM Counter Groups. > >>> > >> > >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way > >> that platform bus id (Device ID in ITS terminmology)is shared with that of > >> SMMU. > >> This would be a matter of concern for software if the SMMU and SMMU PMCG > >> blocks > >> are managed by two independent drivers. > >> > >> The problem arises when we want to alloc/free MSIs for these devices > >> using the APIs, platform_msi_domain_alloc/free_irqs. > >> Platform bus id being same for these two hardware blocks, they end up > >> sharing the same > >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and > >> management > >> of this shared ITT becomes a problem when they are managed by two > >> independent > >> drivers. > > > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > > right pain in the bum to do - is it just that? > > Understatement of the day! ;-) Yes, it is a massive headache, and will > either result in a temporary loss of interrupts (at some point you have > to unmap the ITT), or with spurious interrupts (you generate interrupts > for all the MSIs you've blackholed when unmapping the ITT). Just sharing a thought. If the firmware, through device tree/ACPI can provide the following input to the ITS driver, (For example, as part of msi-parent property in device tree) 1. flag indicating the ITT (Device ID) is being shared 2. the maximum number of vectors that are required to be allocated for this ITT resizing of ITT and the associated complexities could be avoided. > > > > >> We were looking into the option of keeping the SMMU PMCG nodes as sub > >> nodes under > >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total > >> vectors > >> required for SMMU PMCG devices and make a common > >> platform_msi_domain_alloc/free_irqs > >> function call for all devices that share the platform bus id. > > > > I'm not sure how scalable that approach would be, since it's not > > entirely obvious how to handle PMCGs associated with named components or > > root complexes (rather than directly with SMMU instances). We certainly > > don't want to end up spraying similar PMCG DevID logic around all manner > > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs > > will be expected to have distinct IDs from their host devices, they > > could reasonably still overlap with other PMCGs/SMMUs). > > > >> Would like to know your expert opinion on what would be the right approach > >> to handle this case ? > > > > My gut feeling says the way to deal with this properly is in the ITS > > code, but I appreciate that that's a lot easier said than done :/ > > I can revive the hack I once wrote for that (and that was hoping to > forever forget), but that's pretty disgusting, and subject to the above > caveat. > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... -- Linu cherian
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Robin, On Mon Dec 18, 2017 at 02:48:14PM +, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: > >Hi, > > > > > >On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>This adds a driver for the SMMUv3 PMU into the perf framework. > >>It includes an IORT update to support PM Counter Groups. > >> > > > >In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way > >that platform bus id (Device ID in ITS terminmology)is shared with that of > >SMMU. > >This would be a matter of concern for software if the SMMU and SMMU PMCG > >blocks > >are managed by two independent drivers. > > > >The problem arises when we want to alloc/free MSIs for these devices > >using the APIs, platform_msi_domain_alloc/free_irqs. > >Platform bus id being same for these two hardware blocks, they end up > >sharing the same > >ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and > >management > >of this shared ITT becomes a problem when they are managed by two independent > >drivers. > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > right pain in the bum to do - is it just that? Yes exactly. Resizing ITT was the problem in sharing. > >We were looking into the option of keeping the SMMU PMCG nodes as sub nodes > >under > >SMMUv3 node, so that SMMUv3 driver could probe and figure out the total > >vectors > >required for SMMU PMCG devices and make a common > >platform_msi_domain_alloc/free_irqs > >function call for all devices that share the platform bus id. > > I'm not sure how scalable that approach would be, since it's not > entirely obvious how to handle PMCGs associated with named > components or root complexes (rather than directly with SMMU > instances). We certainly don't want to end up spraying similar PMCG > DevID logic around all manner of GPU/accelerator/etc. drivers in > future (whilst PMCGs for device TLBs will be expected to have > distinct IDs from their host devices, they could reasonably still > overlap with other PMCGs/SMMUs). > OK. While trying the above approach, we also felt that the code will become lot messier than actually thought. > >Would like to know your expert opinion on what would be the right approach > >to handle this case ? > > My gut feeling says the way to deal with this properly is in the ITS > code, but I appreciate that that's a lot easier said than done :/ > Yes Correct. > Robin. -- Linu cherian
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Robin, On Mon Dec 18, 2017 at 02:48:14PM +, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: > >Hi, > > > > > >On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>This adds a driver for the SMMUv3 PMU into the perf framework. > >>It includes an IORT update to support PM Counter Groups. > >> > > > >In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way > >that platform bus id (Device ID in ITS terminmology)is shared with that of > >SMMU. > >This would be a matter of concern for software if the SMMU and SMMU PMCG > >blocks > >are managed by two independent drivers. > > > >The problem arises when we want to alloc/free MSIs for these devices > >using the APIs, platform_msi_domain_alloc/free_irqs. > >Platform bus id being same for these two hardware blocks, they end up > >sharing the same > >ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and > >management > >of this shared ITT becomes a problem when they are managed by two independent > >drivers. > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > right pain in the bum to do - is it just that? Yes exactly. Resizing ITT was the problem in sharing. > >We were looking into the option of keeping the SMMU PMCG nodes as sub nodes > >under > >SMMUv3 node, so that SMMUv3 driver could probe and figure out the total > >vectors > >required for SMMU PMCG devices and make a common > >platform_msi_domain_alloc/free_irqs > >function call for all devices that share the platform bus id. > > I'm not sure how scalable that approach would be, since it's not > entirely obvious how to handle PMCGs associated with named > components or root complexes (rather than directly with SMMU > instances). We certainly don't want to end up spraying similar PMCG > DevID logic around all manner of GPU/accelerator/etc. drivers in > future (whilst PMCGs for device TLBs will be expected to have > distinct IDs from their host devices, they could reasonably still > overlap with other PMCGs/SMMUs). > OK. While trying the above approach, we also felt that the code will become lot messier than actually thought. > >Would like to know your expert opinion on what would be the right approach > >to handle this case ? > > My gut feeling says the way to deal with this properly is in the ITS > code, but I appreciate that that's a lot easier said than done :/ > Yes Correct. > Robin. -- Linu cherian
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Thanks for putting me in the loop Robin. On 18/12/17 14:48, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: >> Hi, >> >> >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: >>> This adds a driver for the SMMUv3 PMU into the perf framework. >>> It includes an IORT update to support PM Counter Groups. >>> >> >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way >> that platform bus id (Device ID in ITS terminmology)is shared with that of >> SMMU. >> This would be a matter of concern for software if the SMMU and SMMU PMCG >> blocks >> are managed by two independent drivers. >> >> The problem arises when we want to alloc/free MSIs for these devices >> using the APIs, platform_msi_domain_alloc/free_irqs. >> Platform bus id being same for these two hardware blocks, they end up >> sharing the same >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and >> management >> of this shared ITT becomes a problem when they are managed by two independent >> drivers. > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > right pain in the bum to do - is it just that? Understatement of the day! ;-) Yes, it is a massive headache, and will either result in a temporary loss of interrupts (at some point you have to unmap the ITT), or with spurious interrupts (you generate interrupts for all the MSIs you've blackholed when unmapping the ITT). > >> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes >> under >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total >> vectors >> required for SMMU PMCG devices and make a common >> platform_msi_domain_alloc/free_irqs >> function call for all devices that share the platform bus id. > > I'm not sure how scalable that approach would be, since it's not > entirely obvious how to handle PMCGs associated with named components or > root complexes (rather than directly with SMMU instances). We certainly > don't want to end up spraying similar PMCG DevID logic around all manner > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs > will be expected to have distinct IDs from their host devices, they > could reasonably still overlap with other PMCGs/SMMUs). > >> Would like to know your expert opinion on what would be the right approach >> to handle this case ? > > My gut feeling says the way to deal with this properly is in the ITS > code, but I appreciate that that's a lot easier said than done :/ I can revive the hack I once wrote for that (and that was hoping to forever forget), but that's pretty disgusting, and subject to the above caveat. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Thanks for putting me in the loop Robin. On 18/12/17 14:48, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: >> Hi, >> >> >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: >>> This adds a driver for the SMMUv3 PMU into the perf framework. >>> It includes an IORT update to support PM Counter Groups. >>> >> >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way >> that platform bus id (Device ID in ITS terminmology)is shared with that of >> SMMU. >> This would be a matter of concern for software if the SMMU and SMMU PMCG >> blocks >> are managed by two independent drivers. >> >> The problem arises when we want to alloc/free MSIs for these devices >> using the APIs, platform_msi_domain_alloc/free_irqs. >> Platform bus id being same for these two hardware blocks, they end up >> sharing the same >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and >> management >> of this shared ITT becomes a problem when they are managed by two independent >> drivers. > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > right pain in the bum to do - is it just that? Understatement of the day! ;-) Yes, it is a massive headache, and will either result in a temporary loss of interrupts (at some point you have to unmap the ITT), or with spurious interrupts (you generate interrupts for all the MSIs you've blackholed when unmapping the ITT). > >> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes >> under >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total >> vectors >> required for SMMU PMCG devices and make a common >> platform_msi_domain_alloc/free_irqs >> function call for all devices that share the platform bus id. > > I'm not sure how scalable that approach would be, since it's not > entirely obvious how to handle PMCGs associated with named components or > root complexes (rather than directly with SMMU instances). We certainly > don't want to end up spraying similar PMCG DevID logic around all manner > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs > will be expected to have distinct IDs from their host devices, they > could reasonably still overlap with other PMCGs/SMMUs). > >> Would like to know your expert opinion on what would be the right approach >> to handle this case ? > > My gut feeling says the way to deal with this properly is in the ITS > code, but I appreciate that that's a lot easier said than done :/ I can revive the hack I once wrote for that (and that was hoping to forever forget), but that's pretty disgusting, and subject to the above caveat. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 10/12/17 02:35, Linu Cherian wrote: Hi, On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. This would be a matter of concern for software if the SMMU and SMMU PMCG blocks are managed by two independent drivers. The problem arises when we want to alloc/free MSIs for these devices using the APIs, platform_msi_domain_alloc/free_irqs. Platform bus id being same for these two hardware blocks, they end up sharing the same ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management of this shared ITT becomes a problem when they are managed by two independent drivers. What is the problem exactly? IIRC resizing a possibly-live ITT is a right pain in the bum to do - is it just that? We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs function call for all devices that share the platform bus id. I'm not sure how scalable that approach would be, since it's not entirely obvious how to handle PMCGs associated with named components or root complexes (rather than directly with SMMU instances). We certainly don't want to end up spraying similar PMCG DevID logic around all manner of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs will be expected to have distinct IDs from their host devices, they could reasonably still overlap with other PMCGs/SMMUs). Would like to know your expert opinion on what would be the right approach to handle this case ? My gut feeling says the way to deal with this properly is in the ITS code, but I appreciate that that's a lot easier said than done :/ Robin.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 10/12/17 02:35, Linu Cherian wrote: Hi, On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. This would be a matter of concern for software if the SMMU and SMMU PMCG blocks are managed by two independent drivers. The problem arises when we want to alloc/free MSIs for these devices using the APIs, platform_msi_domain_alloc/free_irqs. Platform bus id being same for these two hardware blocks, they end up sharing the same ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management of this shared ITT becomes a problem when they are managed by two independent drivers. What is the problem exactly? IIRC resizing a possibly-live ITT is a right pain in the bum to do - is it just that? We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs function call for all devices that share the platform bus id. I'm not sure how scalable that approach would be, since it's not entirely obvious how to handle PMCGs associated with named components or root complexes (rather than directly with SMMU instances). We certainly don't want to end up spraying similar PMCG DevID logic around all manner of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs will be expected to have distinct IDs from their host devices, they could reasonably still overlap with other PMCGs/SMMUs). Would like to know your expert opinion on what would be the right approach to handle this case ? My gut feeling says the way to deal with this properly is in the ITS code, but I appreciate that that's a lot easier said than done :/ Robin.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi, On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. This would be a matter of concern for software if the SMMU and SMMU PMCG blocks are managed by two independent drivers. The problem arises when we want to alloc/free MSIs for these devices using the APIs, platform_msi_domain_alloc/free_irqs. Platform bus id being same for these two hardware blocks, they end up sharing the same ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management of this shared ITT becomes a problem when they are managed by two independent drivers. We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs function call for all devices that share the platform bus id. Would like to know your expert opinion on what would be the right approach to handle this case ? Thanks. > IORT has no mechanism for determining device names so PMUs > are named based on their physical address. > > Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours > with no failures. > > Neil Leeder (2): > acpi: arm64: add iort support for PMCG > perf: add arm64 smmuv3 pmu driver > > drivers/acpi/arm64/iort.c | 54 +++ > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 823 > ++ > include/acpi/actbl2.h | 9 +- > 5 files changed, 895 insertions(+), 1 deletion(-) > create mode 100644 drivers/perf/arm_smmuv3_pmu.c > > -- > 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-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Linu cherian
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi, On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. This would be a matter of concern for software if the SMMU and SMMU PMCG blocks are managed by two independent drivers. The problem arises when we want to alloc/free MSIs for these devices using the APIs, platform_msi_domain_alloc/free_irqs. Platform bus id being same for these two hardware blocks, they end up sharing the same ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management of this shared ITT becomes a problem when they are managed by two independent drivers. We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs function call for all devices that share the platform bus id. Would like to know your expert opinion on what would be the right approach to handle this case ? Thanks. > IORT has no mechanism for determining device names so PMUs > are named based on their physical address. > > Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours > with no failures. > > Neil Leeder (2): > acpi: arm64: add iort support for PMCG > perf: add arm64 smmuv3 pmu driver > > drivers/acpi/arm64/iort.c | 54 +++ > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 823 > ++ > include/acpi/actbl2.h | 9 +- > 5 files changed, 895 insertions(+), 1 deletion(-) > create mode 100644 drivers/perf/arm_smmuv3_pmu.c > > -- > 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-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Linu cherian
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Yury, On 10/31/2017 7:33 PM, Yury Norov wrote: > Hi Neil, > > On Fri, Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: >> This adds a driver for the SMMUv3 PMU into the perf framework. >> It includes an IORT update to support PM Counter Groups. >> >> IORT has no mechanism for determining device names so PMUs >> are named based on their physical address. >> >> Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours >> with no failures. >> >> Neil Leeder (2): >> acpi: arm64: add iort support for PMCG >> perf: add arm64 smmuv3 pmu driver >> >> drivers/acpi/arm64/iort.c | 54 +++ >> drivers/perf/Kconfig | 9 + >> drivers/perf/Makefile | 1 + >> drivers/perf/arm_smmuv3_pmu.c | 823 >> ++ >> include/acpi/actbl2.h | 9 +- >> 5 files changed, 895 insertions(+), 1 deletion(-) >> create mode 100644 drivers/perf/arm_smmuv3_pmu.c > > I try to run your driver on ThunderX2, but perf list doesn't show new > events, and example in description in patch 2 also doesn't work: > yury@VAL1-25:~/linux$ tools/perf/perf stat -e > smmu_0_ff88840/transaction,filter_enable=1, > filter_span=1,filter_stream_id=0x42/ -a pwd > event syntax error: '..ter_enable=1,' > \___ parser error > Run 'perf list' for a list of valid events > > Usage: perf stat [] [] > > -e, --eventevent selector. use 'perf list' to list available > events > > I run v4.14-rc7 kernel plus this series. The config is attached. I > found that platform_match() never return 1 for arm-smmu-pmu and so > the driver never probed. > > Maybe it's my local configuration issue? Thanks for testing this driver. As some of the review comments pointed out, there are some changes needed which will be addressed in a future patchset. Notably the IORT needs updating to handle the two base addresses. The current driver assumes the second memory area is adjacent to the first, which may not be the case in all implementations. In order to make the driver probe correctly, you'll need to update your ACPI tables with entries for PMCG, node type 0x5. This ACPI information will include the two base addresses. I've heard that the updated spec which will include the second memory area will be available soon. At that point I will release another patchset for review. Neil -- 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.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Yury, On 10/31/2017 7:33 PM, Yury Norov wrote: > Hi Neil, > > On Fri, Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: >> This adds a driver for the SMMUv3 PMU into the perf framework. >> It includes an IORT update to support PM Counter Groups. >> >> IORT has no mechanism for determining device names so PMUs >> are named based on their physical address. >> >> Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours >> with no failures. >> >> Neil Leeder (2): >> acpi: arm64: add iort support for PMCG >> perf: add arm64 smmuv3 pmu driver >> >> drivers/acpi/arm64/iort.c | 54 +++ >> drivers/perf/Kconfig | 9 + >> drivers/perf/Makefile | 1 + >> drivers/perf/arm_smmuv3_pmu.c | 823 >> ++ >> include/acpi/actbl2.h | 9 +- >> 5 files changed, 895 insertions(+), 1 deletion(-) >> create mode 100644 drivers/perf/arm_smmuv3_pmu.c > > I try to run your driver on ThunderX2, but perf list doesn't show new > events, and example in description in patch 2 also doesn't work: > yury@VAL1-25:~/linux$ tools/perf/perf stat -e > smmu_0_ff88840/transaction,filter_enable=1, > filter_span=1,filter_stream_id=0x42/ -a pwd > event syntax error: '..ter_enable=1,' > \___ parser error > Run 'perf list' for a list of valid events > > Usage: perf stat [] [] > > -e, --eventevent selector. use 'perf list' to list available > events > > I run v4.14-rc7 kernel plus this series. The config is attached. I > found that platform_match() never return 1 for arm-smmu-pmu and so > the driver never probed. > > Maybe it's my local configuration issue? Thanks for testing this driver. As some of the review comments pointed out, there are some changes needed which will be addressed in a future patchset. Notably the IORT needs updating to handle the two base addresses. The current driver assumes the second memory area is adjacent to the first, which may not be the case in all implementations. In order to make the driver probe correctly, you'll need to update your ACPI tables with entries for PMCG, node type 0x5. This ACPI information will include the two base addresses. I've heard that the updated spec which will include the second memory area will be available soon. At that point I will release another patchset for review. Neil -- 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.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Neil, On Fri, Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > > IORT has no mechanism for determining device names so PMUs > are named based on their physical address. > > Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours > with no failures. > > Neil Leeder (2): > acpi: arm64: add iort support for PMCG > perf: add arm64 smmuv3 pmu driver > > drivers/acpi/arm64/iort.c | 54 +++ > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 823 > ++ > include/acpi/actbl2.h | 9 +- > 5 files changed, 895 insertions(+), 1 deletion(-) > create mode 100644 drivers/perf/arm_smmuv3_pmu.c I try to run your driver on ThunderX2, but perf list doesn't show new events, and example in description in patch 2 also doesn't work: yury@VAL1-25:~/linux$ tools/perf/perf stat -e smmu_0_ff88840/transaction,filter_enable=1, filter_span=1,filter_stream_id=0x42/ -a pwd event syntax error: '..ter_enable=1,' \___ parser error Run 'perf list' for a list of valid events Usage: perf stat [] [] -e, --eventevent selector. use 'perf list' to list available events I run v4.14-rc7 kernel plus this series. The config is attached. I found that platform_match() never return 1 for arm-smmu-pmu and so the driver never probed. Maybe it's my local configuration issue? Thanks for any help, Yury t99.config.gz Description: application/gzip
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Neil, On Fri, Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > This adds a driver for the SMMUv3 PMU into the perf framework. > It includes an IORT update to support PM Counter Groups. > > IORT has no mechanism for determining device names so PMUs > are named based on their physical address. > > Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours > with no failures. > > Neil Leeder (2): > acpi: arm64: add iort support for PMCG > perf: add arm64 smmuv3 pmu driver > > drivers/acpi/arm64/iort.c | 54 +++ > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 823 > ++ > include/acpi/actbl2.h | 9 +- > 5 files changed, 895 insertions(+), 1 deletion(-) > create mode 100644 drivers/perf/arm_smmuv3_pmu.c I try to run your driver on ThunderX2, but perf list doesn't show new events, and example in description in patch 2 also doesn't work: yury@VAL1-25:~/linux$ tools/perf/perf stat -e smmu_0_ff88840/transaction,filter_enable=1, filter_span=1,filter_stream_id=0x42/ -a pwd event syntax error: '..ter_enable=1,' \___ parser error Run 'perf list' for a list of valid events Usage: perf stat [] [] -e, --eventevent selector. use 'perf list' to list available events I run v4.14-rc7 kernel plus this series. The config is attached. I found that platform_match() never return 1 for arm-smmu-pmu and so the driver never probed. Maybe it's my local configuration issue? Thanks for any help, Yury t99.config.gz Description: application/gzip
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 2017/10/12 19:05, Lorenzo Pieralisi wrote: > On Thu, Oct 12, 2017 at 06:58:33PM +0800, Hanjun Guo wrote: >> On 2017/8/11 11:28, Leeder, Neil wrote: >>> On 8/9/2017 9:26 PM, Hanjun Guo wrote: > On 2017/8/9 23:48, Leeder, Neil wrote: >>>drivers/perf/Kconfig | 9 + >>>drivers/perf/Makefile | 1 + >>>drivers/perf/arm_smmuv3_pmu.c | 823 >>> ++ >>>include/acpi/actbl2.h | 9 +- > Do you have the acpica support code? I'm currently > working on SMMUv3 MSI support and I would like to test > it with MSI support for PMCG as well. >>> I don't have any code other than what was posted here. >>> What additional ACPICA support code is needed? > Sorry for not clear, I mean the acpica code for iASL and > other tool: github.com/acpica/acpica.git > > With that code, I can compile my IORT table with PMCG node. >>> Unfortunately it looks like I'm the first person from Qualcomm Datacenter >>> Technologies to try to add something to ACPICA, which means I'll have to >>> kick off an internal legal process which may take some time. Unless someone >>> else wants to take a crack at it - and really, there's nothing more than is >>> in the ARM IORT spec - it could be a while before I can do that. >> Just a update, I sent a pull request to Bob for ACPICA changes, >> please take a look: >> >> https://github.com/acpica/acpica/pull/327 > You should not have done that. We need to update IORT specifications > for IORT PMCG before merging ACPICA PMCG support. > > Ask Robert to drop it straight away or I will. Sorry, I will do that, thanks for the reminder. Thanks Hanjun
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 2017/10/12 19:05, Lorenzo Pieralisi wrote: > On Thu, Oct 12, 2017 at 06:58:33PM +0800, Hanjun Guo wrote: >> On 2017/8/11 11:28, Leeder, Neil wrote: >>> On 8/9/2017 9:26 PM, Hanjun Guo wrote: > On 2017/8/9 23:48, Leeder, Neil wrote: >>>drivers/perf/Kconfig | 9 + >>>drivers/perf/Makefile | 1 + >>>drivers/perf/arm_smmuv3_pmu.c | 823 >>> ++ >>>include/acpi/actbl2.h | 9 +- > Do you have the acpica support code? I'm currently > working on SMMUv3 MSI support and I would like to test > it with MSI support for PMCG as well. >>> I don't have any code other than what was posted here. >>> What additional ACPICA support code is needed? > Sorry for not clear, I mean the acpica code for iASL and > other tool: github.com/acpica/acpica.git > > With that code, I can compile my IORT table with PMCG node. >>> Unfortunately it looks like I'm the first person from Qualcomm Datacenter >>> Technologies to try to add something to ACPICA, which means I'll have to >>> kick off an internal legal process which may take some time. Unless someone >>> else wants to take a crack at it - and really, there's nothing more than is >>> in the ARM IORT spec - it could be a while before I can do that. >> Just a update, I sent a pull request to Bob for ACPICA changes, >> please take a look: >> >> https://github.com/acpica/acpica/pull/327 > You should not have done that. We need to update IORT specifications > for IORT PMCG before merging ACPICA PMCG support. > > Ask Robert to drop it straight away or I will. Sorry, I will do that, thanks for the reminder. Thanks Hanjun
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On Thu, Oct 12, 2017 at 06:58:33PM +0800, Hanjun Guo wrote: > On 2017/8/11 11:28, Leeder, Neil wrote: > > On 8/9/2017 9:26 PM, Hanjun Guo wrote: > >> > On 2017/8/9 23:48, Leeder, Neil wrote: > > drivers/perf/Kconfig | 9 + > > drivers/perf/Makefile | 1 + > > drivers/perf/arm_smmuv3_pmu.c | 823 > > ++ > > include/acpi/actbl2.h | 9 +- > >>> Do you have the acpica support code? I'm currently > >>> working on SMMUv3 MSI support and I would like to test > >>> it with MSI support for PMCG as well. > >>> >> I don't have any code other than what was posted here. > >>> >> What additional ACPICA support code is needed? > >> > > >> > Sorry for not clear, I mean the acpica code for iASL and > >> > other tool: github.com/acpica/acpica.git > >> > > >> > With that code, I can compile my IORT table with PMCG node. > > Unfortunately it looks like I'm the first person from Qualcomm Datacenter > > Technologies to try to add something to ACPICA, which means I'll have to > > kick off an internal legal process which may take some time. Unless someone > > else wants to take a crack at it - and really, there's nothing more than is > > in the ARM IORT spec - it could be a while before I can do that. > > Just a update, I sent a pull request to Bob for ACPICA changes, > please take a look: > > https://github.com/acpica/acpica/pull/327 You should not have done that. We need to update IORT specifications for IORT PMCG before merging ACPICA PMCG support. Ask Robert to drop it straight away or I will. Lorenzo
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On Thu, Oct 12, 2017 at 06:58:33PM +0800, Hanjun Guo wrote: > On 2017/8/11 11:28, Leeder, Neil wrote: > > On 8/9/2017 9:26 PM, Hanjun Guo wrote: > >> > On 2017/8/9 23:48, Leeder, Neil wrote: > > drivers/perf/Kconfig | 9 + > > drivers/perf/Makefile | 1 + > > drivers/perf/arm_smmuv3_pmu.c | 823 > > ++ > > include/acpi/actbl2.h | 9 +- > >>> Do you have the acpica support code? I'm currently > >>> working on SMMUv3 MSI support and I would like to test > >>> it with MSI support for PMCG as well. > >>> >> I don't have any code other than what was posted here. > >>> >> What additional ACPICA support code is needed? > >> > > >> > Sorry for not clear, I mean the acpica code for iASL and > >> > other tool: github.com/acpica/acpica.git > >> > > >> > With that code, I can compile my IORT table with PMCG node. > > Unfortunately it looks like I'm the first person from Qualcomm Datacenter > > Technologies to try to add something to ACPICA, which means I'll have to > > kick off an internal legal process which may take some time. Unless someone > > else wants to take a crack at it - and really, there's nothing more than is > > in the ARM IORT spec - it could be a while before I can do that. > > Just a update, I sent a pull request to Bob for ACPICA changes, > please take a look: > > https://github.com/acpica/acpica/pull/327 You should not have done that. We need to update IORT specifications for IORT PMCG before merging ACPICA PMCG support. Ask Robert to drop it straight away or I will. Lorenzo
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 2017/8/11 11:28, Leeder, Neil wrote: > On 8/9/2017 9:26 PM, Hanjun Guo wrote: >> > On 2017/8/9 23:48, Leeder, Neil wrote: > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 823 > ++ > include/acpi/actbl2.h | 9 +- >>> Do you have the acpica support code? I'm currently >>> working on SMMUv3 MSI support and I would like to test >>> it with MSI support for PMCG as well. >>> >> I don't have any code other than what was posted here. >>> >> What additional ACPICA support code is needed? >> > >> > Sorry for not clear, I mean the acpica code for iASL and >> > other tool: github.com/acpica/acpica.git >> > >> > With that code, I can compile my IORT table with PMCG node. > Unfortunately it looks like I'm the first person from Qualcomm Datacenter > Technologies to try to add something to ACPICA, which means I'll have to > kick off an internal legal process which may take some time. Unless someone > else wants to take a crack at it - and really, there's nothing more than is > in the ARM IORT spec - it could be a while before I can do that. Just a update, I sent a pull request to Bob for ACPICA changes, please take a look: https://github.com/acpica/acpica/pull/327 Thanks Hanjun
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 2017/8/11 11:28, Leeder, Neil wrote: > On 8/9/2017 9:26 PM, Hanjun Guo wrote: >> > On 2017/8/9 23:48, Leeder, Neil wrote: > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_smmuv3_pmu.c | 823 > ++ > include/acpi/actbl2.h | 9 +- >>> Do you have the acpica support code? I'm currently >>> working on SMMUv3 MSI support and I would like to test >>> it with MSI support for PMCG as well. >>> >> I don't have any code other than what was posted here. >>> >> What additional ACPICA support code is needed? >> > >> > Sorry for not clear, I mean the acpica code for iASL and >> > other tool: github.com/acpica/acpica.git >> > >> > With that code, I can compile my IORT table with PMCG node. > Unfortunately it looks like I'm the first person from Qualcomm Datacenter > Technologies to try to add something to ACPICA, which means I'll have to > kick off an internal legal process which may take some time. Unless someone > else wants to take a crack at it - and really, there's nothing more than is > in the ARM IORT spec - it could be a while before I can do that. Just a update, I sent a pull request to Bob for ACPICA changes, please take a look: https://github.com/acpica/acpica/pull/327 Thanks Hanjun
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 8/9/2017 9:26 PM, Hanjun Guo wrote: > On 2017/8/9 23:48, Leeder, Neil wrote: drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- >>> Do you have the acpica support code? I'm currently >>> working on SMMUv3 MSI support and I would like to test >>> it with MSI support for PMCG as well. >> I don't have any code other than what was posted here. >> What additional ACPICA support code is needed? > > Sorry for not clear, I mean the acpica code for iASL and > other tool: github.com/acpica/acpica.git > > With that code, I can compile my IORT table with PMCG node. Unfortunately it looks like I'm the first person from Qualcomm Datacenter Technologies to try to add something to ACPICA, which means I'll have to kick off an internal legal process which may take some time. Unless someone else wants to take a crack at it - and really, there's nothing more than is in the ARM IORT spec - it could be a while before I can do that. Neil -- 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.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 8/9/2017 9:26 PM, Hanjun Guo wrote: > On 2017/8/9 23:48, Leeder, Neil wrote: drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- >>> Do you have the acpica support code? I'm currently >>> working on SMMUv3 MSI support and I would like to test >>> it with MSI support for PMCG as well. >> I don't have any code other than what was posted here. >> What additional ACPICA support code is needed? > > Sorry for not clear, I mean the acpica code for iASL and > other tool: github.com/acpica/acpica.git > > With that code, I can compile my IORT table with PMCG node. Unfortunately it looks like I'm the first person from Qualcomm Datacenter Technologies to try to add something to ACPICA, which means I'll have to kick off an internal legal process which may take some time. Unless someone else wants to take a crack at it - and really, there's nothing more than is in the ARM IORT spec - it could be a while before I can do that. Neil -- 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.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 2017/8/9 23:48, Leeder, Neil wrote: drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- Do you have the acpica support code? I'm currently working on SMMUv3 MSI support and I would like to test it with MSI support for PMCG as well. I don't have any code other than what was posted here. What additional ACPICA support code is needed? Sorry for not clear, I mean the acpica code for iASL and other tool: github.com/acpica/acpica.git With that code, I can compile my IORT table with PMCG node. Thanks Hanjun
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
On 2017/8/9 23:48, Leeder, Neil wrote: drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- Do you have the acpica support code? I'm currently working on SMMUv3 MSI support and I would like to test it with MSI support for PMCG as well. I don't have any code other than what was posted here. What additional ACPICA support code is needed? Sorry for not clear, I mean the acpica code for iASL and other tool: github.com/acpica/acpica.git With that code, I can compile my IORT table with PMCG node. Thanks Hanjun
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Hanjun, On 8/9/2017 3:56 AM, Hanjun Guo wrote: > Hi Neil, > > On 2017/8/5 3:59, Neil Leeder wrote: >> This adds a driver for the SMMUv3 PMU into the perf framework. >> It includes an IORT update to support PM Counter Groups. >> >> IORT has no mechanism for determining device names so PMUs >> are named based on their physical address. >> >> Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours >> with no failures. >> >> Neil Leeder (2): >>acpi: arm64: add iort support for PMCG >>perf: add arm64 smmuv3 pmu driver >> >> drivers/acpi/arm64/iort.c | 54 +++ > > I would like to be Cced for next version. I will. I apologise for not including all the interested parties on this patchset. > >> drivers/perf/Kconfig | 9 + >> drivers/perf/Makefile | 1 + >> drivers/perf/arm_smmuv3_pmu.c | 823 >> ++ >> include/acpi/actbl2.h | 9 +- > > Do you have the acpica support code? I'm currently > working on SMMUv3 MSI support and I would like to test > it with MSI support for PMCG as well. I don't have any code other than what was posted here. What additional ACPICA support code is needed? Neil -- 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.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Hanjun, On 8/9/2017 3:56 AM, Hanjun Guo wrote: > Hi Neil, > > On 2017/8/5 3:59, Neil Leeder wrote: >> This adds a driver for the SMMUv3 PMU into the perf framework. >> It includes an IORT update to support PM Counter Groups. >> >> IORT has no mechanism for determining device names so PMUs >> are named based on their physical address. >> >> Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours >> with no failures. >> >> Neil Leeder (2): >>acpi: arm64: add iort support for PMCG >>perf: add arm64 smmuv3 pmu driver >> >> drivers/acpi/arm64/iort.c | 54 +++ > > I would like to be Cced for next version. I will. I apologise for not including all the interested parties on this patchset. > >> drivers/perf/Kconfig | 9 + >> drivers/perf/Makefile | 1 + >> drivers/perf/arm_smmuv3_pmu.c | 823 >> ++ >> include/acpi/actbl2.h | 9 +- > > Do you have the acpica support code? I'm currently > working on SMMUv3 MSI support and I would like to test > it with MSI support for PMCG as well. I don't have any code other than what was posted here. What additional ACPICA support code is needed? Neil -- 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.
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Neil, On 2017/8/5 3:59, Neil Leeder wrote: This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. IORT has no mechanism for determining device names so PMUs are named based on their physical address. Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours with no failures. Neil Leeder (2): acpi: arm64: add iort support for PMCG perf: add arm64 smmuv3 pmu driver drivers/acpi/arm64/iort.c | 54 +++ I would like to be Cced for next version. drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- Do you have the acpica support code? I'm currently working on SMMUv3 MSI support and I would like to test it with MSI support for PMCG as well. Thanks Hanjun 5 files changed, 895 insertions(+), 1 deletion(-) create mode 100644 drivers/perf/arm_smmuv3_pmu.c
Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
Hi Neil, On 2017/8/5 3:59, Neil Leeder wrote: This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. IORT has no mechanism for determining device names so PMUs are named based on their physical address. Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours with no failures. Neil Leeder (2): acpi: arm64: add iort support for PMCG perf: add arm64 smmuv3 pmu driver drivers/acpi/arm64/iort.c | 54 +++ I would like to be Cced for next version. drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- Do you have the acpica support code? I'm currently working on SMMUv3 MSI support and I would like to test it with MSI support for PMCG as well. Thanks Hanjun 5 files changed, 895 insertions(+), 1 deletion(-) create mode 100644 drivers/perf/arm_smmuv3_pmu.c
[PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. IORT has no mechanism for determining device names so PMUs are named based on their physical address. Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours with no failures. Neil Leeder (2): acpi: arm64: add iort support for PMCG perf: add arm64 smmuv3 pmu driver drivers/acpi/arm64/iort.c | 54 +++ drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- 5 files changed, 895 insertions(+), 1 deletion(-) create mode 100644 drivers/perf/arm_smmuv3_pmu.c -- 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.
[PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. IORT has no mechanism for determining device names so PMUs are named based on their physical address. Tested on Qualcomm QDF2400. perf_fuzzer ran for 4+ hours with no failures. Neil Leeder (2): acpi: arm64: add iort support for PMCG perf: add arm64 smmuv3 pmu driver drivers/acpi/arm64/iort.c | 54 +++ drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- 5 files changed, 895 insertions(+), 1 deletion(-) create mode 100644 drivers/perf/arm_smmuv3_pmu.c -- 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.
