On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote: > On 02/02/2015 11:22 AM, Johannes Berg wrote: > >>> You basically have the following sequence: > >>> > >>> iowrite() > >>> ioread() > >>> > >>> If you look, you'll see that iowrite() is actually done (or should be, > >>> or perhaps with appropriate syncs) on an uncached mapping. > >> since it's mmio, iowrite will be map to write, not out which is cached > >> mapping. > >> That's why we address "posted write" here. > >> If it's un-cached mapping which is volatile, we don't even need ioread. > > No, this isn't true - "posted write" in the context of this discussion > > is about the PCIe bus. Memory writes that go through cache aren't > > referred to as "posted writes", those are just (cached) memory writes. > > > >>> As a result, > >>> the only thing you care about here is the PCIe bus, not the CPU cache > >>> flush. And from there on that's just a question of PCIe bus semantics. > >> So how does ioread guarantee PCIe bus transaction done? > > That's how PCIe works, operations are serialized, and read() has to wait > > for a response from the device > do you know which mechanism or which instruction set makes read() wait > for a response from the device? I have no idea. I assume it's just like a DRAM read, the CPU stalls while there's no response. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
