Hi Arnd, >> >* 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 ? > >It's more likely that you have to do a readl() after the writel() to >any address inside of the device in order to ensure the writel() >has completed, but that is something that the hardware manual for >the iommu should describe. > ok, get it. So will do it as required for here. >> >* 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 ? > >It doesn't have to be a speculative fetch, it could also be a normal >fetch triggered by a DMA. The point is that the CPU is free to reorder >the store to (io page table) memory relative to the store to the >IOMMU flush register, and when you directly follow up with a store to >the DMA master that triggers a transfer, this transfer can hit the >IOMMU and cause the stale page table entry to be read. > >I guess in practice the barrier that comes before the MMIO write to the >DMA master would ensure ordering of the DMA after both the IOPTE >update and the MMIO flush (unless there was the speculative fetch you >mentioned), but this is where I'm no longer confident enough in my >pwn understanding of th ordering rules to rely on that. Having the >barrier between the IOPTE update and the flush certainly leaves >no room for ambiguity. Ok understand. Also i think speculative access if any, should go away if unmap is done first and then remap by clients. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html