Hi Arnd,

quoted

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