Re: Question on Linux DMA routines

Re: Question on Linux DMA routines

[Grant Grundler]

"Gunneswara Marripudi" wrote:
> Hi Grant,
> 
> I have a quick question on Linux 2.3 DMA routines.

2.3 is dead. You mean 2.4.


> If I allocate and map memory using pci_alloc_consistent(),
> do I still need to call pci_dma_sync_single() if there is a 
> need to ensure the coherency? The documentation on it
> at DMA-mapping.txt is ambiguous (at least to me). 

No - it's not needed.

> - Consistent DMA mappings which are usually mapped at driver
> 113   initialization, unmapped at the end and for which the hardware should
> 114   guarantee that the device and the cpu can access the data
> 115   in parallel and will see updates made by each other without any
> 116   explicit software flushing.
> 117 
> 118   Think of "consistent" as "synchronous" or "coherent".
> 
> 
> It says that h/w should guarantee the consistency and I'm not sure 
> what if the underlying platform is not fully coherent.

The HW *is* fully coherent when the CPU doesn't cache the pages.
Only systems with PCX-L/L2 CPU (need to) operate this way.
All other platforms have an I/O MMU which manages the coherency.

You might be confused because HPUX doesn't ever use uncached memory
for I/O since it has dma_sync() macro instead. And device driver writers
are "trained" to use that.


grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: Question on Linux DMA routines

[Grant Grundler]

Grant Grundler wrote:
...
> The HW *is* fully coherent when the CPU doesn't cache the pages.
> Only systems with PCX-L/L2 CPU (need to) operate this way.
> All other platforms have an I/O MMU which manages the coherency.

Correction - PCX-T and older platforms are not coherent and U-bit
isn't available/useable on those machines. Drivers must do their own
cache flushing. sim700 (LASI SCSI) does this and I think Apricot
(LASI LAN) too. I'm suspecting this might be part of the 735 problems.

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: Question on Linux DMA routines

[Richard Hirst]

On Thu, Nov 30, 2000 at 10:01:13AM -0800, Grant Grundler wrote:
> Grant Grundler wrote:
> ...
> > The HW *is* fully coherent when the CPU doesn't cache the pages.
> > Only systems with PCX-L/L2 CPU (need to) operate this way.
> > All other platforms have an I/O MMU which manages the coherency.
> 
> Correction - PCX-T and older platforms are not coherent and U-bit
> isn't available/useable on those machines. Drivers must do their own
> cache flushing. sim700 (LASI SCSI) does this and I think Apricot
> (LASI LAN) too. I'm suspecting this might be part of the 735 problems.

That's right, sim700 and apricot call pci_alloc_consistent() and if
that fails they fall back to get_free_pages() and explicit cache
flushing and invalidating with dma_cache_wback/dma_cache_inv calls.
pci_alloc_consistent() should fail on pcx, pcxs and pcxt according
to setup.c.

When sim700 complains at startup that it "Couldn't get consistent
shared memory", it means pci_alloc_consistent() failed and therefore
you have one of these older CPUs, and it will drop back to doing its
own cache management.

At startup the driver does a test where it writes memory, flushes
it, writes something else to the same location, then gets the scsi chip
to read that location.  If the scsi chip gets the old data, the driver
says "WARNING: target data areas are not dma coherent".  This is
just for information, it has no effect on how the driver operates.

Richard