[PATCH V5 6/7] iommu/msm: Use writel_relaxed and add a barrier
Sricharan
sricharan at codeaurora.org
Wed May 25 06:19:18 PDT 2016
Hi Arnd,
>> Ok, so i was doing this from the idea that, other iommu drivers
>> where polling on a status bit in their sync call to ensure completion
>> of pending TLB invalidations. But in this case, there is no status bit.
>> So added a barrier to have no ordering issues before the client
>> triggers the dma operation. But as you say above that it is implicit that
>> the device would have a barrier before starting the trigger, then the
>> barrier here becomes redundant.
>
>Ok. There are two more things to note here:
>
>* On other platforms, polling the register is likely required because
> an MMIO write is "posted", meaning that a sync after writel() will
> only ensure that it has left the CPU write queue, but it may still be
> on the bus fabric and whatever side-effects are triggered by the
> write are normally not guaranteed to be completed even after the
> 'sync'. You need to check the datasheet for your IOMMU to find out
> whether the 'dsb' instruction actually has any effect on the IOMMU.
> If not, then neither the barrier that you add here nor the barrier
> in the following writel() is sufficient.
>
Thanks for the detailed explanation.
i will check this. So with this, i think that if the iommu does not
support polling for its status, then it should listen to 'dsb' otherwise
there will no be no way of make it coherent ?
>* The one barrier that is normally required in an IOMMU is between
> updating the in-memory page tables and the following MMIO store
> that triggers the TLB flush for that entry. This barrier is
> implied by writel() but not writel_relaxed(). If you don't have
> a hardware page table walker in your IOMMU, you don't need to worry
> about this.
>
To get my understanding correct here, is the barrier required here because
of speculative fetch ?
Regards,
Sricharan
More information about the linux-arm-kernel
mailing list