On Sun, Jun 6, 2010 at 8:16 PM, Robert Brown <robert.br...@gmail.com> wrote: > Sure, but I only see one place in ath5k_rxbuf_setup where it returns > an error value (-ENOMEM). I'm using a 5/18/2010 snapshot. Should I > grab a later version? > Are there any cache issues when dealing with hardware devices like > the Atheros chip? For instance, ath5k_rxbuf_setup sets up descriptors > and links. Is it certain the hardware has the same view of memory?
No, they typically don't have the same view, but it depends on how the memory is mapped. If the memory is from a coherent mapping, as our descriptors are, then the hardware and processor should have the same view. But there can still be races if proper barriers aren't used (e.g., out of order stores). We have this problem today around updates to ds_link, but adding the wmb() didn't fix the problem for another reporter. For streaming mappings (all of our SKBs) the data may be cached so you cannot expect to touch a buffer once it is mapped until it is unmapped again. In the worst case, bounce buffers are used, so the memory you mapped is actually copied to or from somewhere else entirely. Actually, you can read or write the mapped buffer if you use the dma_sync routines while the buffer is mapped (this implies a copy for bounce buffers). That covers DMA. For MMIO reads/writes, you can consider any writes to be posted to the hardware only after you do a subsequent PCI read. (This is my understanding but not gospel, read Documentation/DMA* to learn more.) -- Bob Copeland %% www.bobcopeland.com _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
