Re: What's up with cpu_is_noncoherent_r10000() ?

[David Daney <ddaney@avtrex.com>]

David Daney wrote:
> I am bringing up the git HEAD on an old ATI Xilleon X226.  This nice 
> system claims to be 4KEc, but for some reason doesn't support mips32r2, 
> but I digress.
> 
> Among its other problems this is a CONFIG_DMA_NONCOHERENT system, so 
> drivers like net/e100.c do not function properly if the cache is not 
> appropriately flushed/invalidated when they are doing DMA.  Fortunately 
> the authors of said driver have used 
> pci_dma_sync_single_for_{cpu,device} in what seems like the appropriate 
>  manner.
> 
> pci_dma_sync_single_for_device() ends up in dma_sync_single_for_device() 
> (in mm/dme-default.c) and is does the cache flush as expected.  The 
> problem is with dma_sync_single_for_cpu() which for some reason only 
> does the cache flush/invalidate  if cpu_is_noncoherent_r10000() returns 
> true (which it does only for R10K CPUs).  When I hack it up so that it 
> returns true unconditionally, e100 starts functioning normally for me. 
> This leads me to think that the cache operation should be done for all 
> CONFIG_DMA_NONCOHERENT systems not just R10K based systems.
> 
> What is the reasoning for only doing the cache operation on  R10K based 
> systems?
> 

OK, Ralf straightened me out on dma_sync_*.  It would appear that 
mm/dme-default.c is correct and drivers/net/e100.c is missing a 
pci_dma_sync_single_for_device().

I am preparing a patch for e100.c

David Daney