Re: [RFC] MMIO accessors & barriers documentation

Benjamin Herrenschmidt wrote:
Well, the argument currently is to make writel and readl imply the above
barriers by making them fully ordered (and slow on some platforms) and
so also provide more weakly ordered routines along with barriers for
people who know what they do. The above 2 barriers are what I've called
io_to_memory_rb() and memory_to_io_wb() (actually,
prepare_to_read_dma_memory() by itself doesn't really make much sense.
It does in conjunction with an MMIO read to flush DMA buffers, in which
case the barrier provides an ordering guarantee that the memory reads
will only be performed after the MMIO read has fully completed).

<jgarzik throws a monkey wrench into the works>

I think focusing on MMIO just confuses the issue.

wmb() is often used to make sure a memory store is visible to a busmastering PCI device... before the code proceeds with some more transactions in the memory space shared by the host and PCI device.

prepare_to_read_dma_memory() is the operation that an ethernet driver's RX code wants. And this is _completely_ unrelated to MMIO. It just wants to make sure that the device and host are looking at the same data. Often this involves polling a DMA descriptor (or index, stored inside DMA-able memory) looking for changes.

flush_my_writes_to_dma_memory() is the operation that an ethernet driver's TX code wants, to precede either an MMIO "poke" or any other non-MMIO operation where the driver needs to be certain that the write is visible to the PCI device, should the PCI device desire to read that area of memory.

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC] MMIO accessors & barriers documentation
    ... between descriptor updates in memory and the mmio to kick them? ... followed by MMIO store, that is does ia64 -current- accessors provide ... the barriers allowing to implement those ordering rules when the ...
    (Linux-Kernel)
  • Re: [RFC] MMIO accessors & barriers documentation
    ... transactions in the memory space shared by the host and PCI device. ... And this is _completely_ unrelated to MMIO. ... Why would you need a barrier other than a compiler barrierfor that? ...
    (Linux-Kernel)
  • [PATCH] Document Linuxs memory barriers [try #2]
    ... The attached patch documents the Linux kernel's memory barriers. ... I've tried to get rid of the concept of memory accesses appearing on the bus; ... barring implicit enforcement by the CPU. ...
    (Linux-Kernel)
  • Re: [RFC] MMIO accessors & barriers documentation
    ... previous memory stores are globally visible before the first MMIO store ... Barriers are required to ensure ordering vs. memory and vs. locks (see ... between a memory store and an MMIO store. ...
    (Linux-Kernel)
  • Re: I/O memory barriers vs SMP memory barriers
    ... There's actually three different cases of interest on ARM: ... direct-mapped and vmalloced kernel memory ... on SMP systems, and just a compiler barrier on UP systems. ... you _would_ need hardware barriers for. ...
    (Linux-Kernel)