From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Robin Murphy <robin.murphy@arm.com>,
Jordan Crouse <jcrouse@codeaurora.org>,
Will Deacon <will@kernel.org>
Cc: Sean Paul <sean@poorly.run>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
David Airlie <airlied@linux.ie>,
linux-arm-msm@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
Rob Herring <robh+dt@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
iommu@lists.linux-foundation.org, Andy Gross <agross@kernel.org>,
dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
linux-arm-msm-owner@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Brian Masney <masneyb@onstation.org>
Subject: Re: [PATCH v9 0/7] iommu/arm-smmu: Enable split pagetable support
Date: Wed, 01 Jul 2020 15:41:03 +0530 [thread overview]
Message-ID: <bdc2a4348230f430138d320e49e188c0@codeaurora.org> (raw)
In-Reply-To: <20200626200042.13713-1-jcrouse@codeaurora.org>
Hi Will, Robin,
On 2020-06-27 01:30, Jordan Crouse wrote:
> Another iteration of the split-pagetable support for arm-smmu and the
> Adreno GPU
> SMMU. After email discussions [1] we opted to make a arm-smmu
> implementation for
> specifically for the Adreno GPU and use that to enable split pagetable
> support
> and later other implementation specific bits that we need.
>
> On the hardware side this is very close to the same code from before
> [2] only
> the TTBR1 quirk is turned on by the implementation and not a domain
> attribute.
> In drm/msm we use the returned size of the aperture as a clue to let us
> know
> which virtual address space we should use for global memory objects.
>
> There are two open items that you should be aware of. First, in the
> implementation specific code we have to check the compatible string of
> the
> device so that we only enable TTBR1 for the GPU (SID 0) and not the GMU
> (SID 4).
> I went back and forth trying to decide if I wanted to use the
> compatible string
> or the SID as the filter and settled on the compatible string but I
> could be
> talked out of it.
>
> The other open item is that in drm/msm the hardware only uses 49 bits
> of the
> address space but arm-smmu expects the address to be sign extended all
> the way
> to 64 bits. This isn't a problem normally unless you look at the
> hardware
> registers that contain a IOVA and then the upper bits will be zero. I
> opted to
> restrict the internal drm/msm IOVA range to only 49 bits and then sign
> extend
> right before calling iommu_map / iommu_unmap. This is a bit wonky but I
> thought
> that matching the hardware would be less confusing when debugging a
> hang.
>
> v9: Fix bot-detected merge conflict
> v7: Add attached device to smmu_domain to pass to implementation
> specific
> functions
>
> [1]
> https://lists.linuxfoundation.org/pipermail/iommu/2020-May/044537.html
> [2] https://patchwork.kernel.org/patch/11482591/
>
>
> Jordan Crouse (7):
> iommu/arm-smmu: Pass io-pgtable config to implementation specific
> function
> iommu/arm-smmu: Add support for split pagetables
> dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU
> iommu/arm-smmu: Add a pointer to the attached device to smmu_domain
> iommu/arm-smmu: Add implementation for the adreno GPU SMMU
> drm/msm: Set the global virtual address range from the IOMMU domain
> arm: dts: qcom: sm845: Set the compatible string for the GPU SMMU
>
> .../devicetree/bindings/iommu/arm,smmu.yaml | 4 ++
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++++-
> drivers/gpu/drm/msm/msm_iommu.c | 7 +++
> drivers/iommu/arm-smmu-impl.c | 6 ++-
> drivers/iommu/arm-smmu-qcom.c | 45 ++++++++++++++++++-
> drivers/iommu/arm-smmu.c | 38 +++++++++++-----
> drivers/iommu/arm-smmu.h | 30 ++++++++++---
> 8 files changed, 120 insertions(+), 25 deletions(-)
Any chance reviewing this?
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2020-07-02 7:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 20:00 [PATCH v9 0/7] iommu/arm-smmu: Enable split pagetable support Jordan Crouse
2020-06-26 20:00 ` [PATCH v9 6/7] drm/msm: Set the global virtual address range from the IOMMU domain Jordan Crouse
2020-06-27 17:10 ` [Freedreno] " Rob Clark
2020-06-29 14:52 ` Jordan Crouse
2020-07-01 10:11 ` Sai Prakash Ranjan [this message]
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=bdc2a4348230f430138d320e49e188c0@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=agross@kernel.org \
--cc=airlied@linux.ie \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jcrouse@codeaurora.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masneyb@onstation.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sean@poorly.run \
--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).