lkml.org 
[lkml]   [1999]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPCI 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.073 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site