SMMU driver and stall vs terminate mode

[robin.murphy@arm.com (Robin Murphy)]

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
>