Prev: [PATCH 2/2] drivers:staging:ti-st: update ABI and TODO
Next: [PATCH 1/2] drivers:staging:ti-st: mv sysfs entries to debugfs
From: Clemens Ladisch on 28 Jul 2010 03:30
Stefan Richter wrote:
> We need:
> 2. a write memory barrier between branch_address update and wake-up of
> the DMA unit by MMIO register write.
>
> Barrier 2 is implicit in writel() on most machines --- or at least I
> think it is. See this from arch/x86/include/asm/io.h:
>
> #define build_mmio_write(name, size, type, reg, barrier) \
> static inline void name(type val, volatile void __iomem *addr) \
> { asm volatile("mov" size " %0,%1": :reg (val), \
> "m" (*(volatile type __force *)addr) barrier); }
>
> build_mmio_write(writel, "l", unsigned int, "r", :"memory")
>
> Does this order the mmio write relative to previous memory writes?

This asm barrier prevents the compiler from reordering.

The main purpose of writel() and friends is to access the address space
where memory-mapped I/O ranges reside; there are architectures where the
normal memory access commands cannot be used. This does not necessarily
imply anything about reordering semantics.

However, PCI address ranges are marked by the device's config registers
as either cacheable or not, and the kernel heeds this when mapping these
ranges. Registers are, of course, marked as uncacheable.


Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 28 Jul 2010 05:10
Clemens Ladisch wrote:
> Stefan Richter wrote:
>> We need:
>> 2. a write memory barrier between branch_address update and wake-up of
>> the DMA unit by MMIO register write.
>>
>> Barrier 2 is implicit in writel() on most machines --- or at least I
>> think it is. See this from arch/x86/include/asm/io.h:
>>
>> #define build_mmio_write(name, size, type, reg, barrier) \
>> static inline void name(type val, volatile void __iomem *addr) \
>> { asm volatile("mov" size " %0,%1": :reg (val), \
>> "m" (*(volatile type __force *)addr) barrier); }
>>
>> build_mmio_write(writel, "l", unsigned int, "r", :"memory")
>>
>> Does this order the mmio write relative to previous memory writes?
>
> This asm barrier prevents the compiler from reordering.
>
> The main purpose of writel() and friends is to access the address space
> where memory-mapped I/O ranges reside; there are architectures where the
> normal memory access commands cannot be used. This does not necessarily
> imply anything about reordering semantics.
>
> However, PCI address ranges are marked by the device's config registers
> as either cacheable or not, and the kernel heeds this when mapping these
> ranges. Registers are, of course, marked as uncacheable.

But the memory to which we wrote before that is cachable (though
cache-coherent, allocated by dma_alloc_coherent). This memory write
should not cross the mmio register write.

Documentation/DocBook/deviceiobook.tmpl mentions that mmio reads to a
device are ordered WRT to DMA transactions that the device issued before
that mmio read. But no mentions of mmio write to a device vs. preceding
memory accesses by the CPU.

Well, a quick look how some hopefully well-written drivers use and don't
use wmb() indicates that I don't need to worry. Perhaps it is time to
look for a PCI book.
--
Stefan Richter
-=====-==-=- -=== ===--
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH 2/2] drivers:staging:ti-st: update ABI and TODO
Next: [PATCH 1/2] drivers:staging:ti-st: mv sysfs entries to debugfs