From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Mon, 20 Jun 2016 17:08:45 +0100 Subject: SMMU driver and stall vs terminate mode In-Reply-To: References: Message-ID: <5768150D.2070705@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Stuart, On 20/06/16 16:28, Stuart Yoder wrote: > Robin/Will, > > Right now the SMMU driver is hardcoded to configure 'stall' mode for > context faults: > > /* SCTLR */ > reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP; > > We are running into an issue with a device where it seems behave sanely > when SCTLR_CFCFG=0 ...i.e. 'terminate' mode, but in stall mode seems to be > unaware that an access violation occurred. Does the device keep issuing transactions after the initial faulting one, by any chance? Brian (+cc) has seen similar-sounding issues in the past (albeit with backports to some horrible Android kernel), and I think we concluded that there's an inherent race window between writing RESUME and acking the interrupt in which MMU-500 can process another faulting transaction and reassert the IRQ without Linux realising, which then gets lost and things go out of whack. > Is there really some assumption that all devices that send transcactions > through the SMMU _must_ be able to handle stall mode? I am trying to > find out from our hw designers what is going on at the signal level for > the device in question, but it seems to me that 'terminate' mode exists > for a reason and I wonder what your thoughts are about providing a > configuration option to allow configuration of terminate mode if a particular > SoC requires it. Personally, I'd quite happily leave it turned off (MMU-400/401 don't support stalling anyway), but I recall Will having a fairly reasonable-sounding argument in favour, which I now can't remember the details of. Hopefully he might remind us, unless his conference is too enthralling. Robin. > > Thanks, > Stuart >