From: Robin Murphy <robin.murphy@arm.com>
To: Rob Herring <robh@kernel.org>
Cc: will@kernel.org, mark.rutland@arm.com, lorenzo.pieralisi@arm.com,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org,
jean-philippe@linaro.org, leo.yan@linaro.org,
noda.akio@socionext.com
Subject: Re: [PATCH 3/6] iommu/arm-smmu: Add DT PMU support
Date: Wed, 2 Mar 2022 17:03:24 +0000 [thread overview]
Message-ID: <b51de3ac-5dbe-a1f1-1897-febb52f3cb34@arm.com> (raw)
In-Reply-To: <Yh+OOs0BStF0y/VF@robh.at.kernel.org>
On 2022-03-02 15:33, Rob Herring wrote:
> Send DT patches to the DT list if you want them reviewed with some
> guarantee that I'll see them. (Except right now as PW stopped getting
> mail. :( )
Oops, sorry, I think I had some sort of mental block there - I should
equally have cc'd the IOMMU list too.
> On Thu, Feb 17, 2022 at 02:24:17PM +0000, Robin Murphy wrote:
>> Since IORT describes PMU interrupts rather inflexibly as an inherent
>
> What's IORT? ;)
See the preceding patch :P
But indeed this particular sentence is still its untouched 5-year-old
self... today I'd tend to write "ACPI IORT", is that better?
>> part of the SMMU, the best way to avoid excessive complexity is to make
>> the way we handle DT look as similar as possible. Fortunately the
>> de-facto standard for mentioning PMU interrupts at all under the current
>> binding has been to include them in the global interrupt count, listing
>> them after the actual fault interrupt(s), so we can capitalise on that.
>> It's about 9 years too late to redefine "#global-interrupts" to exclude
>> anything other than context interrupts without breaking compatibility,
>> so we're stuck with a slightly convoluted definition of PMU interrupts
>> as an optional subdivision of the "global" interrupts, but it works.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>
>> ---
>>
>> Not sure whether the count-backwards-from-the-middle nature of "number
>> of PMU interrupts" is too ugly and "index of first PMU interrupt" might
>> be any better.
>
> Can this be solved with 'interrupt-names' instead deprecating
> #global-interrupts along the way?
My gut feeling is that that's not realistically feasible - we don't have
a fixed set of IRQ lines with well-defined names, we have an imp-def set
of "things that might raise one or more of global fault conditions",
plus some number of context interrupts that work one of two ways, plus
possibly some number of PMU counter group interrupts, with the
additional fun that for some implementations those may all be the same
physical signal (and I've now seen at least one SoC inexplicably wire up
a combined interrupt *as well* as the individual outputs, and describe
them all!)
My main concern is not breaking backward-compatibility for a new DT with
an old OS. From past experience, I'm pretty sure Xen would be up in arms
about any breakage in that direction, so "#global-interrupts" is sadly
going nowhere for the foreseeable future. However even just thinking
about implementing such a thing in the Linux driver puts me off - we'd
have to take some horrible backwards approach where we look at all the
names first to figure out which IRQs to get, and such an abuse of
"interrupt-names" sounds worse than what it's trying to avoid.
The other approach I tried was to have a "pmu" sub-node with its own
"interrupts" property, but that turned out to cause problems if it was
behind an "interrupt-map", for reasons which didn't entirely make sense.
Plus the corresponding DT changes were uglier and more invasive - the
nice thing about the method here is that PMU support becomes a simple
one-line addition to many existing DTs.
>> ---
>> .../devicetree/bindings/iommu/arm,smmu.yaml | 19 ++++++++++++++++++-
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 4 ++++
>> 2 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index da5381c8ee11..9d39df42528a 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -87,10 +87,18 @@ properties:
>>
>> '#global-interrupts':
>> description: The number of global interrupts exposed by the device.
>> + Includes the count of PMU interrupts, if present.
>> $ref: /schemas/types.yaml#/definitions/uint32
>> minimum: 0
>> maximum: 260 # 2 secure, 2 non-secure, and up to 256 perf counters
>>
>> + '#pmu-interrupts':
>
> It would have been great if everything that's a count/size used '#', but
> that didn't happen. So I'm not that wild about using '#' randomly at
> all.
>
> This needs a vendor prefix (arm,).
Sure - I went for consistency with what's already established, but since
I'm similarly none too fond of it, swapping for something like
"arm,pmu-irq-start" is fine by me.
Thanks,
Robin.
>> + description: The number of PMU interrupts. Must be equal to the number of
>> + implemented counter groups.
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 1
>> + maximum: 256
>> +
>> '#iommu-cells':
>> enum: [ 1, 2 ]
>> description: |
>> @@ -115,6 +123,10 @@ properties:
>> context bank. In the case of a single, combined interrupt, it must be
>> listed multiple times.
>>
>> + If a PMU is present, the global interrupt entries consist of any fault
>> + interrupts first, followed by #pmu-interrupts entries, one per implemented
>> + counter group, specified in order of their indexing by the SMMU.
>> +
>> dma-coherent:
>> description: |
>> Present if page table walks made by the SMMU are cache coherent with the
>> @@ -190,9 +202,14 @@ examples:
>> smmu1: iommu@ba5e0000 {
>> compatible = "arm,smmu-v1";
>> reg = <0xba5e0000 0x10000>;
>> - #global-interrupts = <2>;
>> + #global-interrupts = <6>; /* 2 fault + 4 PMU */
>> + #pmu-interrupts = <4>;
>> interrupts = <0 32 4>,
>> <0 33 4>,
>> + <0 94 4>, /* This is the first PMU interrupt */
>> + <0 95 4>,
>> + <0 96 4>,
>> + <0 97 4>,
>> <0 34 4>, /* This is the first context interrupt */
>> <0 35 4>,
>> <0 36 4>,
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> index cbfe4cc914f0..8d6c8106fc1d 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> @@ -1995,6 +1995,10 @@ static int arm_smmu_device_dt_probe(struct arm_smmu_device *smmu,
>> return dev_err_probe(dev, -ENODEV,
>> "missing #global-interrupts property\n");
>> *pmu_irqs = 0;
>> + of_property_read_u32(dev->of_node, "#pmu-interrupts", pmu_irqs);
>> + if (*pmu_irqs > *global_irqs)
>> + return dev_err_probe(dev, -EINVAL, "invalid #pmu_interrupts property");
>> + *global_irqs -= *pmu_irqs;
>>
>> data = of_device_get_match_data(dev);
>> smmu->version = data->version;
>> --
>> 2.28.0.dirty
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-03-02 17:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 14:24 [PATCH 0/6] perf: Arm SMMU PMU driver Robin Murphy
2022-02-17 14:24 ` [PATCH 1/6] iommu/arm-smmu: Account for PMU interrupts Robin Murphy
2022-02-17 14:24 ` [PATCH 2/6] acpi/iort: Register SMMUv2 " Robin Murphy
2022-02-17 14:24 ` [PATCH 3/6] iommu/arm-smmu: Add DT PMU support Robin Murphy
2022-03-02 15:33 ` Rob Herring
2022-03-02 17:03 ` Robin Murphy [this message]
2022-02-17 14:24 ` [PATCH 4/6] iommu/smmu: Create child devices for PMUs Robin Murphy
2022-02-17 14:24 ` [PATCH 5/6] perf: Add ARM SMMU PMU driver Robin Murphy
2022-02-17 14:24 ` [PATCH 6/6] arm64: dts: Add SMMU PMUs to Juno Robin Murphy
2022-03-07 22:03 ` [PATCH 0/6] perf: Arm SMMU PMU driver Will Deacon
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=b51de3ac-5dbe-a1f1-1897-febb52f3cb34@arm.com \
--to=robin.murphy@arm.com \
--cc=jean-philippe@linaro.org \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=noda.akio@socionext.com \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=will@kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).