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 linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
