linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Guo <shawn.guo@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v2 1/3] ACPI/IORT: Consolidate use of SMMU device platdata
Date: Sun, 9 May 2021 10:14:44 +0800	[thread overview]
Message-ID: <20210509021443.GC8679@dragon> (raw)
In-Reply-To: <bf51c5b3-082c-98dd-ff8d-559ef5b56bad@arm.com>

On Tue, Apr 27, 2021 at 06:37:24PM +0100, Robin Murphy wrote:
> On 2021-04-02 04:56, Shawn Guo wrote:
> > Currently the platdata is being used in different way by SMMU and PMCG
> > device.  The former uses it for acpi_iort_node pointer passing, while
> > the later uses it for model identifier.  As it's been seen that the
> > model identifier is useful for SMMU devices as well, let's consolidate
> > the platdata use to get it accommodate both acpi_iort_node pointer and
> > model identifier, so that all IORT devices (SMMU, SMMUv3 and PMCG) pass
> > platdata in a consistent manner.
> > 
> > With this change, model identifier is not specific to PMCG, so
> > IORT_SMMU_V3_PMCG_GENERIC gets renamed to IORT_SMMU_GENERIC.  While at
> > it, the spaces used in model defines are converted to tabs.
> 
> SMMUs and PMCGs are deliberately kept distinct because they are not
> necessarily equivalent - a PMCG may belong to something other than an SMMU,
> (like a root complex or a device with its own TLB), and even a single SMMU
> may implement heterogeneous PMCGs (e.g. Arm's MMU-600 has PMCGs in its
> control unit and TLB units which count different sets of events). So NAK to
> that aspect, sorry.
> 
> FWIW this was originally here because we envisaged needing to identify
> individual PMCG implementations through a variety of poking at different
> fields and tables, so hiding that behind an abstraction in ACPI code seemed
> neatest. However, things haven't really panned out that way - now we seem to
> have moved more towards describing events in userspace in conjunction with
> other system-specific identifiers. If we've no need to identify PMCGs in the
> kernel for the sake of exporting imp-def events, then most of the argument
> for this PMCG identifier abstraction is gone, and it's looking increasingly
> like the HIP08 case deserves to be punted back to the PMCG driver itself as
> a one-off erratum workaround.
> 
> I think at this point we should accept that if a driver needs to match
> *some* platform-specific data for its own internal purposes, the fact that
> that data might be the IORT header still doesn't make it "IORT
> functionality", and referencing ACPI_SIG_IORT from drivers is a lesser evil
> than cluttering up the IORT code with increasing amounts of random stuff
> that's outside the scope of the IORT specification itself.

Thanks much for the comments, Robin!  Indeed, it makes more sense to
sort the issue out in qcom driver than IORT code.  v3 is on the way.

Shawn

  reply	other threads:[~2021-05-09  2:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-02  3:55 [PATCH v2 0/3] arm-smmu-qcom: Create qcom_smmu_impl for ACPI boot Shawn Guo
2021-04-02  3:56 ` [PATCH v2 1/3] ACPI/IORT: Consolidate use of SMMU device platdata Shawn Guo
2021-04-27 17:37   ` Robin Murphy
2021-05-09  2:14     ` Shawn Guo [this message]
2021-04-02  3:56 ` [PATCH v2 2/3] ACPI/IORT: Add Qualcomm Snapdragon platforms to iort_plat_info[] Shawn Guo
2021-04-27 17:41   ` Robin Murphy
2021-04-02  3:56 ` [PATCH v2 3/3] iommu/arm-smmu-qcom: hook up qcom_smmu_impl for ACPI boot Shawn Guo
2021-04-26  0:41 ` [PATCH v2 0/3] arm-smmu-qcom: Create " Shawn Guo

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=20210509021443.GC8679@dragon \
    --to=shawn.guo@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=guohanjun@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=will@kernel.org \
    --subject='Re: [PATCH v2 1/3] ACPI/IORT: Consolidate use of SMMU device platdata' \
    /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

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).