What's up with cpu_is_noncoherent_r10000() ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: MIPS Linux List <linux-mips@xxxxxxxxxxxxxx>
- Subject: What's up with cpu_is_noncoherent_r10000() ?
- From: David Daney <ddaney@xxxxxxxxxx>
- Date: Mon, 25 Aug 2008 09:34:29 -0700
- User-agent: Thunderbird 2.0.0.16 (X11/20080723)
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?
David Daney
[Index of Archives]
[Linux MIPS Home]
[LKML Archive]
[Linux ARM Kernel]
[Linux ARM]
[Linux]
[Git]
[Yosemite News]
[Linux SCSI]
[Linux Hams]