devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Rob Clark <robdclark@gmail.com>
Cc: "iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Sricharan R <sricharan@codeaurora.org>,
	Jordan Crouse <jcrouse@codeaurora.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
Date: Thu, 12 Jan 2017 15:17:18 +0000	[thread overview]
Message-ID: <20170112151717.GB13843@arm.com> (raw)
In-Reply-To: <CAF6AEGvGWu+OMED52_Mphpd1K=2QAeeuPV8RaRzL9S+N4YOh2Q@mail.gmail.com>

On Wed, Jan 11, 2017 at 03:59:30PM -0500, Rob Clark wrote:
> On Wed, Jan 11, 2017 at 4:36 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Jan 10, 2017 at 02:20:13PM -0500, Rob Clark wrote:
> >> On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
> >> >> Hmm, well we install the fault handler on the iommu_domain..  perhaps
> >> >> maybe a combo of dts property (or deciding based on more specific
> >> >> compat string), plus extra param passed in to
> >> >> iommu_set_fault_hander().  The dts property or compat string to
> >> >> indicate whether the iommu (and how it is wired up) can handle stalls,
> >> >> and enable_stall param when fault handler is registered to indicate
> >> >> whether the device itself can cope.. if either can't do stalling, then
> >> >> don't set CFCFG.
> >> >
> >> > I thought about this some more, and I think you're right. Having
> >> > iommu_set_fault_handler take a flags parameter indicating that, for example,
> >> > the fault handler can deal with paging, is all we need to implement the
> >> > per-master opt-in functionality for stalling faults. There's no real
> >> > requirement to standardise a generic firmware property for that (but
> >> > we still need *something* that says stalling is usable on the SMMU --
> >> > perhaps just the compatible string is ok).
> >>
> >> btw, it occurred to me that maybe it should be flags param to
> >> iommu_attach_device() (just in case fault handler not installed?)
> >> otoh stalling without a fault handler is silly, but I guess we need it
> >> to infer whether stalling can be supported by other devices on same
> >> iommu.. tbh I'm on a bit shaky ground when it comes to multiple
> >> devices per iommu since the SoC's I'm familiar with do it the other
> >> way around.  But I guess you have thought more about the multi-device
> >> case, so figured I should suggest it..
> >
> > I don't think it works at attach time, because the stalling property belongs
> > to the domain, rather than the individual devices within it. Similarly, I
> > don't think we should allow this property to be toggled once devices have
> > been attached.
> >
> 
> hmm, I was more thinking of cases where drivers for particular devices
> need some work (ie. like potentially disabling hw hang detect during
> faults).. I guess we could have three levels, that all have to be true
> in order to enable stall: smmu, domain (pass flags in to
> iommu_domain_alloc()??), and device (iommu_attach_device())?

Hooking iommu_set_fault_handler, as you originally suggested, is the best
way to set the flag on the domain. I think we just need to enforce that
iommu_set_fault_handler is called prior to attaching devices to a domain,
so that the IOMMU driver can configure the domain appropriately on the
first attach.

Will

  reply	other threads:[~2017-01-12 15:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1483479056-15202-1-git-send-email-robdclark@gmail.com>
     [not found] ` <1483479056-15202-2-git-send-email-robdclark@gmail.com>
     [not found]   ` <1483479056-15202-2-git-send-email-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-05 11:55     ` [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling Will Deacon
2017-01-05 12:08       ` Mark Rutland
2017-01-05 14:00         ` Will Deacon
     [not found]           ` <20170105140005.GJ679-5wv7dgnIgG8@public.gmane.org>
2017-01-05 14:07             ` Mark Rutland
2017-01-05 14:47               ` Will Deacon
     [not found]                 ` <20170105144742.GK679-5wv7dgnIgG8@public.gmane.org>
2017-01-05 15:32                   ` Robin Murphy
2017-01-05 16:07                     ` Will Deacon
     [not found]                       ` <20170105160755.GN679-5wv7dgnIgG8@public.gmane.org>
2017-01-05 17:03                         ` Robin Murphy
     [not found]                           ` <611575f4-3e37-1f4d-ef29-94e6f65baf66-5wv7dgnIgG8@public.gmane.org>
2017-01-05 17:25                             ` Will Deacon
2017-01-06 16:36                               ` Rob Clark
     [not found]       ` <20170105115528.GG679-5wv7dgnIgG8@public.gmane.org>
2017-01-05 15:27         ` Rob Clark
     [not found]           ` <CAF6AEGsUdZALAQTozmxPV8Os=3pG7ay=1Oqtctx99FV9_4SX7Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-05 15:49             ` Will Deacon
     [not found]               ` <20170105154950.GM679-5wv7dgnIgG8@public.gmane.org>
2017-01-06 16:26                 ` Rob Clark
2017-01-10 17:52                   ` Will Deacon
     [not found]                     ` <20170110175219.GK527-5wv7dgnIgG8@public.gmane.org>
2017-01-10 19:20                       ` Rob Clark
     [not found]                         ` <CAF6AEGsCJ6L-wmBHFYy2jfQ1bfq_d2wmiWVUXno344US9ikLVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-11  9:36                           ` Will Deacon
     [not found]                             ` <20170111093606.GA12388-5wv7dgnIgG8@public.gmane.org>
2017-01-11 20:59                               ` Rob Clark
2017-01-12 15:17                                 ` Will Deacon [this message]
     [not found]                                   ` <20170112151717.GB13843-5wv7dgnIgG8@public.gmane.org>
2017-01-30 20:51                                     ` Rob Clark

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=20170112151717.GB13843@arm.com \
    --to=will.deacon@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jcrouse@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robdclark@gmail.com \
    --cc=robh@kernel.org \
    --cc=sricharan@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).