dma_is_consistent() is nonsensical...

dma_is_consistent() is nonsensical...

[Deepak Saxena]

Working on adding support for cache-coherent operation to ARM and 
wondering exactly what this API is supposed to do. From the name it
is obviously supposed to tell the caller (only one in the kernel...
drivers/scsi/53c700.c) whether the provided dma_handle is cache-coherent
or not.  In the case of multiple DMA domains where certain devices
are on snooping interfaces and others are not we really want to know what
device the DMA address is on so can we add a struct device* ptr to this 
function? Or can we just kill it since nobody is actually using it? 
Calling dma_alloc_coherent should always return coherent/consistent 
(why the different naming conventions too?) so I don't really see a real 
use case. 

~Deepak

-- 
Deepak Saxena - dsaxena@plexity.net - http://www.plexity.net

"To question your government is not unpatriotic - to not question your
 government is unpatriotic." -  Senator Chuck Hagel (R-NE) - Nov 15, 2005

Re: dma_is_consistent() is nonsensical...

[Krzysztof Halasa]

Deepak Saxena <dsaxena@plexity.net> writes:

> Working on adding support for cache-coherent operation to ARM and 
> wondering exactly what this API is supposed to do. From the name it
> is obviously supposed to tell the caller (only one in the kernel...
> drivers/scsi/53c700.c) whether the provided dma_handle is cache-coherent
> or not.  In the case of multiple DMA domains where certain devices
> are on snooping interfaces and others are not we really want to know what
> device the DMA address is on so can we add a struct device* ptr to this 
> function? Or can we just kill it since nobody is actually using it? 
> Calling dma_alloc_coherent should always return coherent/consistent 
> (why the different naming conventions too?) so I don't really see a real 
> use case. 

I would have to look at the current code but yes, there were issues
like that in the past. Coherent vs consistent - there are two APIs
(DMA and PCI) each with a different name for this.
-- 
Krzysztof Halasa