Re: What's up with cpu_is_noncoherent_r10000() ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux