[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170927121540.GL8398@8bytes.org>
Date: Wed, 27 Sep 2017 14:15:40 +0200
From: Joerg Roedel <joro@...tes.org>
To: Rob Clark <robdclark@...il.com>
Cc: Jean-Philippe Brucker <jean-philippe.brucker@....com>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Will Deacon <Will.Deacon@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] iommu: arm-smmu: stall support
Hi Rob, Jean,
On Fri, Sep 22, 2017 at 02:42:44PM -0400, Rob Clark wrote:
> I'm in favour if splitting the reporting *somehow*.. the two
> approaches that seemed sane are:
>
> 1) call fault handler from irq and having separate domain->resume()
> called by the driver, potentially from a wq
> 2) or having two fault callbacks, first called before wq and then
> based on returned value, optionally 2nd callback called from wq
>
> The first seemed less intrusive to me, but I'm flexible.
How about adding a flag to the fault-handler call-back that tells us
whether it wants to sleep or not. If it wants, we call it from a wq, if
not we call call it directly like we do today in the
report_iommu_fault() function.
In any case we call iommu_ops->resume() when set on completion of the
fault-handler either from the workqueue or report_iommu_fault itself.
Regards,
Joerg
Powered by blists - more mailing lists