All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: mark.rutland@arm.com,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	devicetree@vger.kernel.org, iommu@lists.linux-foundation.org,
	robh+dt@kernel.org, uchida.jun@socionext.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
Date: Tue, 7 Dec 2021 21:59:04 +0800	[thread overview]
Message-ID: <20211207135904.GH42658@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <675bfd78-69ac-608f-1303-e86b90a83f72@arm.com>

On Tue, Dec 07, 2021 at 01:46:49PM +0000, Robin Murphy wrote:

[...]

> >    [   28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
> > 
> > Please confirm if this is expected or not?  I think this might
> > introduce difficulty for John for the PMU event alias patches, which
> > is dependent on a non-zero IIDR.
> 
> Yes, from previous discussions I believe the HiSilicon implementations don't
> have much meaningful ID information at all (hence why we have to match ACPI
> table headers to identify the counter erratum). My trick only works for Arm
> Ltd. implementations since they happen to have the IMP-DEF CoreSight
> registers with the same information as would be in the future IIDR.
> 
> To clarify, the proposal at this point is to write up JSON files for
> MMU-600/MMU-700, based on this patch, in order to pipe-clean the process for
> future SMMUv3.3 PMCG implementations with real IIDRs.
> 
> Whether other implementers might retroactively define "equivalent" IIDR
> values for their existing implementations in a way we could potentially
> quirk in the driver is an orthogonal question.

Agreed, it makes sense that supports the standard IP modules in
the mainline kernel at this stage.

Thanks for explanation.

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

WARNING: multiple messages have this Message-ID (diff)
From: Leo Yan <leo.yan@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: John Garry <john.garry@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	mark.rutland@arm.com, devicetree@vger.kernel.org,
	iommu@lists.linux-foundation.org, uchida.jun@socionext.com,
	will@kernel.org, linux-arm-kernel@lists.infradead.org,
	robh+dt@kernel.org
Subject: Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
Date: Tue, 7 Dec 2021 21:59:04 +0800	[thread overview]
Message-ID: <20211207135904.GH42658@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <675bfd78-69ac-608f-1303-e86b90a83f72@arm.com>

On Tue, Dec 07, 2021 at 01:46:49PM +0000, Robin Murphy wrote:

[...]

> >    [   28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
> > 
> > Please confirm if this is expected or not?  I think this might
> > introduce difficulty for John for the PMU event alias patches, which
> > is dependent on a non-zero IIDR.
> 
> Yes, from previous discussions I believe the HiSilicon implementations don't
> have much meaningful ID information at all (hence why we have to match ACPI
> table headers to identify the counter erratum). My trick only works for Arm
> Ltd. implementations since they happen to have the IMP-DEF CoreSight
> registers with the same information as would be in the future IIDR.
> 
> To clarify, the proposal at this point is to write up JSON files for
> MMU-600/MMU-700, based on this patch, in order to pipe-clean the process for
> future SMMUv3.3 PMCG implementations with real IIDRs.
> 
> Whether other implementers might retroactively define "equivalent" IIDR
> values for their existing implementations in a way we could potentially
> quirk in the driver is an orthogonal question.

Agreed, it makes sense that supports the standard IP modules in
the mainline kernel at this stage.

Thanks for explanation.

Leo

WARNING: multiple messages have this Message-ID (diff)
From: Leo Yan <leo.yan@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: John Garry <john.garry@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	mark.rutland@arm.com, devicetree@vger.kernel.org,
	iommu@lists.linux-foundation.org, uchida.jun@socionext.com,
	will@kernel.org, linux-arm-kernel@lists.infradead.org,
	robh+dt@kernel.org
Subject: Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
Date: Tue, 7 Dec 2021 21:59:04 +0800	[thread overview]
Message-ID: <20211207135904.GH42658@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <675bfd78-69ac-608f-1303-e86b90a83f72@arm.com>

On Tue, Dec 07, 2021 at 01:46:49PM +0000, Robin Murphy wrote:

[...]

> >    [   28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
> > 
> > Please confirm if this is expected or not?  I think this might
> > introduce difficulty for John for the PMU event alias patches, which
> > is dependent on a non-zero IIDR.
> 
> Yes, from previous discussions I believe the HiSilicon implementations don't
> have much meaningful ID information at all (hence why we have to match ACPI
> table headers to identify the counter erratum). My trick only works for Arm
> Ltd. implementations since they happen to have the IMP-DEF CoreSight
> registers with the same information as would be in the future IIDR.
> 
> To clarify, the proposal at this point is to write up JSON files for
> MMU-600/MMU-700, based on this patch, in order to pipe-clean the process for
> future SMMUv3.3 PMCG implementations with real IIDRs.
> 
> Whether other implementers might retroactively define "equivalent" IIDR
> values for their existing implementations in a way we could potentially
> quirk in the driver is an orthogonal question.

Agreed, it makes sense that supports the standard IP modules in
the mainline kernel at this stage.

Thanks for explanation.

Leo

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

  reply	other threads:[~2021-12-07 13:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17 14:48 [PATCH v2 0/3] perf/smmuv3: Support devicetree Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` [PATCH v2 1/3] dt-bindings: Add Arm SMMUv3 PMCG binding Jean-Philippe Brucker
2021-11-17 14:48   ` Jean-Philippe Brucker
2021-11-17 14:48   ` Jean-Philippe Brucker
2021-11-17 14:48 ` [PATCH v2 2/3] perf/smmuv3: Add devicetree support Jean-Philippe Brucker
2021-11-17 14:48   ` Jean-Philippe Brucker
2021-11-17 14:48   ` Jean-Philippe Brucker
2021-11-17 14:48 ` [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers Jean-Philippe Brucker
2021-11-17 14:48   ` Jean-Philippe Brucker
2021-11-17 14:48   ` Jean-Philippe Brucker
2021-12-07  9:14   ` John Garry
2021-12-07  9:14     ` John Garry
2021-12-07  9:14     ` John Garry via iommu
2021-12-07 12:04     ` Robin Murphy
2021-12-07 12:04       ` Robin Murphy
2021-12-07 12:04       ` Robin Murphy
2021-12-07 12:28       ` John Garry
2021-12-07 12:28         ` John Garry
2021-12-07 12:28         ` John Garry via iommu
2021-12-07 12:48         ` Robin Murphy
2021-12-07 12:48           ` Robin Murphy
2021-12-07 12:48           ` Robin Murphy
2021-12-07 13:20           ` Leo Yan
2021-12-07 13:20             ` Leo Yan
2021-12-07 13:20             ` Leo Yan
2021-12-07 13:46             ` Robin Murphy
2021-12-07 13:46               ` Robin Murphy
2021-12-07 13:46               ` Robin Murphy
2021-12-07 13:59               ` Leo Yan [this message]
2021-12-07 13:59                 ` Leo Yan
2021-12-07 13:59                 ` Leo Yan
2021-12-07 14:00                 ` John Garry
2021-12-07 14:00                   ` John Garry
2021-12-07 14:00                   ` John Garry via iommu
2021-12-07 14:04                   ` Leo Yan
2021-12-07 14:04                     ` Leo Yan
2021-12-07 14:04                     ` Leo Yan
2021-12-14 14:04 ` [PATCH v2 0/3] perf/smmuv3: Support devicetree Will Deacon
2021-12-14 14:04   ` Will Deacon
2021-12-14 14:04   ` 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=20211207135904.GH42658@leoy-ThinkPad-X240s \
    --to=leo.yan@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --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.