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
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
