All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: robh+dt@kernel.org, iommu@lists.linux-foundation.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	will@kernel.org, joro@8bytes.org, mark.rutland@arm.com,
	jkchen@linux.alibaba.com, leo.yan@linaro.org,
	uchida.jun@socionext.com
Subject: Re: [PATCH 0/2] perf/smmuv3: Support devicetree
Date: Tue, 16 Nov 2021 17:00:14 +0000	[thread overview]
Message-ID: <54be6173-59d3-7ce8-e04b-b5197fdc0e10@arm.com> (raw)
In-Reply-To: <YZPRTUis+G279XIO@myrica>

On 2021-11-16 15:42, Jean-Philippe Brucker wrote:
> On Tue, Nov 16, 2021 at 12:02:47PM +0000, Robin Murphy wrote:
>> On 2021-11-16 11:35, Jean-Philippe Brucker wrote:
>>> Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
>>> Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
>>> multiple independent PMCGs, for example one for the Translation Control
>>> Unit (TCU) and one per Translation Buffer Unit (TBU).
>>>
>>> I previously sent the binding as reply to Jay Chen's thread implementing
>>> device tree support [1]. This posting addresses the comments from that
>>> thread.
>>
>> Ha, I'd also resurrected this and was planning to post it at some point this
>> week[0] - you should have said :)
> 
> Ah sorry about that, I just resent because there was some demand for it at
> Linaro

Heh, no worries - it's not like you were even CC'ed on the thread where 
I only mentioned I *might* do it.

Can I get away with being cheeky and just saying that my review comments 
are the diff between my branch and yours, I wonder...

>>> Patch 1 adds two compatible strings. "arm,smmu-v3-pmcg" is common to all
>>> PMCGs. "hisilicon,smmu-v3-pmcg-hip08" allows to support the same quirk
>>> as IORT for that implementation (see patch 2). We'll probably want to
>>> also introduce compatible strings for each implementation that has
>>> additional perf events. For example the MMU-600 implementation has
>>> different events for TCU and TBU PMCGs [2], but both components have the
>>> same device IDs. So the driver could differentiate them if they had two
>>> distinct compatible strings such as "arm,mmu-600-pmcg-tbu" and
>>> "arm,mmu-600-pmcg-tcu".
>>
>> Actually it only needs a general MMU-600 compatible, since once you know
>> it's an Arm Ltd. implementation, you can assume the pattern for the IMP_DEF
>> ID registers to figure out the rest.
> 
> It might be an error in the MMU-600 spec specifically, both TBU and TCU
> PMU registers have a 0x83 PIDR0, where I think the TBU should be 0x84 (the
> revC model uses that value). It's possible that the implementation
> actually has 0x84 instead.

Yup, it's a mistake in the TRM. I just checked a real MMU-600 and the 
PMU PIDRs match the main TCU/TBU PIDRs as expected. At least the MMU-700 
docs haven't repeated the same error.

Cheers,
Robin.

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	iommu@lists.linux-foundation.org, robh+dt@kernel.org,
	uchida.jun@socionext.com, leo.yan@linaro.org, will@kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/2] perf/smmuv3: Support devicetree
Date: Tue, 16 Nov 2021 17:00:14 +0000	[thread overview]
Message-ID: <54be6173-59d3-7ce8-e04b-b5197fdc0e10@arm.com> (raw)
In-Reply-To: <YZPRTUis+G279XIO@myrica>

On 2021-11-16 15:42, Jean-Philippe Brucker wrote:
> On Tue, Nov 16, 2021 at 12:02:47PM +0000, Robin Murphy wrote:
>> On 2021-11-16 11:35, Jean-Philippe Brucker wrote:
>>> Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
>>> Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
>>> multiple independent PMCGs, for example one for the Translation Control
>>> Unit (TCU) and one per Translation Buffer Unit (TBU).
>>>
>>> I previously sent the binding as reply to Jay Chen's thread implementing
>>> device tree support [1]. This posting addresses the comments from that
>>> thread.
>>
>> Ha, I'd also resurrected this and was planning to post it at some point this
>> week[0] - you should have said :)
> 
> Ah sorry about that, I just resent because there was some demand for it at
> Linaro

Heh, no worries - it's not like you were even CC'ed on the thread where 
I only mentioned I *might* do it.

Can I get away with being cheeky and just saying that my review comments 
are the diff between my branch and yours, I wonder...

>>> Patch 1 adds two compatible strings. "arm,smmu-v3-pmcg" is common to all
>>> PMCGs. "hisilicon,smmu-v3-pmcg-hip08" allows to support the same quirk
>>> as IORT for that implementation (see patch 2). We'll probably want to
>>> also introduce compatible strings for each implementation that has
>>> additional perf events. For example the MMU-600 implementation has
>>> different events for TCU and TBU PMCGs [2], but both components have the
>>> same device IDs. So the driver could differentiate them if they had two
>>> distinct compatible strings such as "arm,mmu-600-pmcg-tbu" and
>>> "arm,mmu-600-pmcg-tcu".
>>
>> Actually it only needs a general MMU-600 compatible, since once you know
>> it's an Arm Ltd. implementation, you can assume the pattern for the IMP_DEF
>> ID registers to figure out the rest.
> 
> It might be an error in the MMU-600 spec specifically, both TBU and TCU
> PMU registers have a 0x83 PIDR0, where I think the TBU should be 0x84 (the
> revC model uses that value). It's possible that the implementation
> actually has 0x84 instead.

Yup, it's a mistake in the TRM. I just checked a real MMU-600 and the 
PMU PIDRs match the main TCU/TBU PIDRs as expected. At least the MMU-700 
docs haven't repeated the same error.

Cheers,
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: robh+dt@kernel.org, iommu@lists.linux-foundation.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	will@kernel.org, joro@8bytes.org, mark.rutland@arm.com,
	jkchen@linux.alibaba.com, leo.yan@linaro.org,
	uchida.jun@socionext.com
Subject: Re: [PATCH 0/2] perf/smmuv3: Support devicetree
Date: Tue, 16 Nov 2021 17:00:14 +0000	[thread overview]
Message-ID: <54be6173-59d3-7ce8-e04b-b5197fdc0e10@arm.com> (raw)
In-Reply-To: <YZPRTUis+G279XIO@myrica>

On 2021-11-16 15:42, Jean-Philippe Brucker wrote:
> On Tue, Nov 16, 2021 at 12:02:47PM +0000, Robin Murphy wrote:
>> On 2021-11-16 11:35, Jean-Philippe Brucker wrote:
>>> Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
>>> Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
>>> multiple independent PMCGs, for example one for the Translation Control
>>> Unit (TCU) and one per Translation Buffer Unit (TBU).
>>>
>>> I previously sent the binding as reply to Jay Chen's thread implementing
>>> device tree support [1]. This posting addresses the comments from that
>>> thread.
>>
>> Ha, I'd also resurrected this and was planning to post it at some point this
>> week[0] - you should have said :)
> 
> Ah sorry about that, I just resent because there was some demand for it at
> Linaro

Heh, no worries - it's not like you were even CC'ed on the thread where 
I only mentioned I *might* do it.

Can I get away with being cheeky and just saying that my review comments 
are the diff between my branch and yours, I wonder...

>>> Patch 1 adds two compatible strings. "arm,smmu-v3-pmcg" is common to all
>>> PMCGs. "hisilicon,smmu-v3-pmcg-hip08" allows to support the same quirk
>>> as IORT for that implementation (see patch 2). We'll probably want to
>>> also introduce compatible strings for each implementation that has
>>> additional perf events. For example the MMU-600 implementation has
>>> different events for TCU and TBU PMCGs [2], but both components have the
>>> same device IDs. So the driver could differentiate them if they had two
>>> distinct compatible strings such as "arm,mmu-600-pmcg-tbu" and
>>> "arm,mmu-600-pmcg-tcu".
>>
>> Actually it only needs a general MMU-600 compatible, since once you know
>> it's an Arm Ltd. implementation, you can assume the pattern for the IMP_DEF
>> ID registers to figure out the rest.
> 
> It might be an error in the MMU-600 spec specifically, both TBU and TCU
> PMU registers have a 0x83 PIDR0, where I think the TBU should be 0x84 (the
> revC model uses that value). It's possible that the implementation
> actually has 0x84 instead.

Yup, it's a mistake in the TRM. I just checked a real MMU-600 and the 
PMU PIDRs match the main TCU/TBU PIDRs as expected. At least the MMU-700 
docs haven't repeated the same error.

Cheers,
Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-11-16 17:00 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 11:35 [PATCH 0/2] perf/smmuv3: Support devicetree Jean-Philippe Brucker
2021-11-16 11:35 ` Jean-Philippe Brucker
2021-11-16 11:35 ` Jean-Philippe Brucker
2021-11-16 11:35 ` [PATCH 1/2] dt-bindings: Add Arm SMMUv3 PMCG binding Jean-Philippe Brucker
2021-11-16 11:35   ` Jean-Philippe Brucker
2021-11-16 11:35   ` Jean-Philippe Brucker
2021-11-16 14:02   ` Rob Herring
2021-11-16 14:02     ` Rob Herring
2021-11-16 14:02     ` Rob Herring
2021-11-16 15:43     ` Jean-Philippe Brucker
2021-11-16 15:43       ` Jean-Philippe Brucker
2021-11-16 15:43       ` Jean-Philippe Brucker
2021-11-17 23:19   ` Rob Herring
2021-11-17 23:19     ` Rob Herring
2021-11-17 23:19     ` Rob Herring
2021-11-18 15:50     ` Robin Murphy
2021-11-18 15:50       ` Robin Murphy
2021-11-18 15:50       ` Robin Murphy
2021-12-10 11:34       ` Jean-Philippe Brucker
2021-12-10 11:34         ` Jean-Philippe Brucker
2021-12-10 11:34         ` Jean-Philippe Brucker
2021-11-16 11:35 ` [PATCH 2/2] perf/smmuv3: Add devicetree support Jean-Philippe Brucker
2021-11-16 11:35   ` Jean-Philippe Brucker
2021-11-16 11:35   ` Jean-Philippe Brucker
2021-11-16 12:06   ` John Garry
2021-11-16 12:06     ` John Garry
2021-11-16 12:06     ` John Garry
2021-11-16 15:42     ` Jean-Philippe Brucker
2021-11-16 15:42       ` Jean-Philippe Brucker
2021-11-16 15:42       ` Jean-Philippe Brucker
2021-11-16 12:02 ` [PATCH 0/2] perf/smmuv3: Support devicetree Robin Murphy
2021-11-16 12:02   ` Robin Murphy
2021-11-16 12:02   ` Robin Murphy
2021-11-16 15:42   ` Jean-Philippe Brucker
2021-11-16 15:42     ` Jean-Philippe Brucker
2021-11-16 15:42     ` Jean-Philippe Brucker
2021-11-16 17:00     ` Robin Murphy [this message]
2021-11-16 17:00       ` Robin Murphy
2021-11-16 17:00       ` Robin Murphy
2021-11-16 17:20       ` Jean-Philippe Brucker
2021-11-16 17:20         ` Jean-Philippe Brucker
2021-11-16 17:20         ` Jean-Philippe Brucker

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=54be6173-59d3-7ce8-e04b-b5197fdc0e10@arm.com \
    --to=robin.murphy@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=jkchen@linux.alibaba.com \
    --cc=joro@8bytes.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=uchida.jun@socionext.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 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.