Messages in this thread | | | Date | Wed, 18 Aug 1999 16:40:07 +0200 | From | Benjamin Herrenschmidt <> | Subject | PCI cache incoherency and DMA |
| |
Hi !
I'm working on fixing a couple of drivers for a PCI DMA non-cache coherent architecture (StrongARM/21285 based board), and in order to be completely safe, I need the ring descriptors to be in non-cachable space (since a cache line beeing larger that a single descriptor entry, writing to one may override datas written to another by the chip).
What is the "preferred" way of allocating a piece of RAM and making in non-cachable from within a driver ? I'm not very familiar with Linux memory allocation (yet), I can imagine a "brutal" way of doing a ioremap(virt_to_phys(my_kmalloced_memory)) with the appropriate flags in ioremap but I'm not 100% sure this is safe. Any advice ?
Also, in io.h, there are some macros defining (or not defining depending on the architecture) the flush and invalidate routines for DMA. That's great, but there are at least 2 important informations missing from this header file in order to write safe drivers:
- The cache line size (I beleive it may be defined elsewhere, is there a standard #define for it ?)
- and wether we are coherent or not. For the coherency, this is more complicated since it depends on the bus we are on. I beleive we could at least define a standard macro/function for PCI, taking a pcidev and returning if the path from this device to system memory is coherent or not, or if it requires GFP_DMA in kmalloc. Something like:
int pci_dma_is_cache_coherent(struct pcidev *device);
returning PCI_DEV_COHERENT, PCI_DEV_INCOHERENT, PCI_DEV_SPECIALALLOC
On most architecture, this function could be a simple macro or inline returning PCI_DEV_COHERENT. ARM would always return PCI_DEV_INCOHERENT, and would I leave the last one for possibke remaining special cases.
Any comments ?
-- Perso. e-mail: <mailto:bh40@calva.net> Work e-mail: <mailto:benh@mipsys.com> BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |