From: Will Deacon <will@kernel.org>
To: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>, "list@263.net:IOMMU DRIVERS ,
Joerg Roedel <joro@8bytes.org>,"
<iommu@lists.linux-foundation.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH] iomm/arm-smmu: Add stall implementation hook
Date: Wed, 20 May 2020 13:59:17 +0100 [thread overview]
Message-ID: <20200520125916.GE25815@willie-the-truck> (raw)
In-Reply-To: <a801e79a0a75092c28a6646ae7fa5e36@codeaurora.org>
On Wed, May 20, 2020 at 03:02:45PM +0530, Sai Prakash Ranjan wrote:
> On 2020-05-19 20:41, Rob Clark wrote:
> > On Tue, May 19, 2020 at 2:26 AM Sai Prakash Ranjan
> > <saiprakash.ranjan@codeaurora.org> wrote:
> > > On 2020-05-18 21:15, Will Deacon wrote:
> > > > So this sounds like an erratum to me, and I'm happy to set HUPCF if we
> > > > detect the broken implementation. However, it will need an entry in
> > > > Documentation/arm64/silicon-errata.rst and a decent comment in the
> > > > driver
> > > > to explain what we're doing and why.
> > > >
> > >
> > > AFAIK there is no erratum documented internally for this behaviour and
> > > this
> > > exists from MSM8996 SoC time and errata usually don't survive this
> > > long
> > > across generation of SoCs and there is no point for us in disguising
> > > it.
> >
> > possibly longer, qcom_iommu sets CFCFG..
> >
>
> Oh right, I was still in college when those SoCs were released ;)
>
> > > Is it OK if we clearly mention it as the "design limitation" or some
> > > other
> > > term which we can agree upon along with the description which Rob and
> > > Jordan
> > > provided for setting HUPCF in the driver when we add the set_hupcf
> > > callback?
> >
> > I'm not too picky on what we call it, but afaict it has been this way
> > since the beginning of time, rather than specific to a certain SoC or
> > generation of SoCs. So it doesn't seem like the hw designers consider
> > it a bug.
> >
> > (I'm not sure what the expected behavior is.. nor if any other SMMU
> > implementation encounters this sort of situation..)
>
> Yes, that was my point as well that its probably not counted as a bug
> by the hw designers. So I'm going to post setting HUPCF on QCOM
> implementation with clear comments based on yours and Jordan's description
> of this problem, but I wanted to have a way to set this only for GPU context
> bank and not GMU as Jordan mentioned earlier that GMU doesnt need HUPCF set.
> I was checking as to how do we map cb to device, if it was possible then we
> can have
> a compatibility thing like we did for identity mapping. Any ideas Robin?
Right, see my reply over at:
https://lore.kernel.org/r/20200520125700.GD25815@willie-the-truck
Hopefully something like that can be made to work.
Will
prev parent reply other threads:[~2020-05-20 12:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 20:20 [PATCH] iomm/arm-smmu: Add stall implementation hook Sai Prakash Ranjan
2020-05-07 10:14 ` Sai Prakash Ranjan
2020-05-07 10:55 ` Robin Murphy
2020-05-07 12:06 ` Sai Prakash Ranjan
2020-05-07 14:56 ` Robin Murphy
2020-05-07 12:53 ` Will Deacon
2020-05-08 15:32 ` Rob Clark
2020-05-08 15:40 ` Rob Clark
2020-05-11 17:30 ` Jordan Crouse
2020-05-18 15:45 ` Will Deacon
2020-05-19 9:26 ` Sai Prakash Ranjan
2020-05-19 15:11 ` Rob Clark
2020-05-20 9:32 ` Sai Prakash Ranjan
2020-05-20 12:59 ` Will Deacon [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=20200520125916.GE25815@willie-the-truck \
--to=will@kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=saiprakash.ranjan@codeaurora.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).