On Fri, 18 Jun 2010 00:30:51 +0900 Paul Mundt <lethal@xxxxxxxxxxxx> wrote: > On Thu, Jun 17, 2010 at 11:50:35PM +0900, FUJITA Tomonori wrote: > > On Thu, 17 Jun 2010 07:36:53 -0700 (PDT) > > David Miller <davem@xxxxxxxxxxxxx> wrote: > > > > > From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> > > > Date: Thu, 17 Jun 2010 21:21:13 +0900 > > > > > > > On Wed, 16 Jun 2010 23:24:44 -0700 > > > > "Michael Chan" <mchan@xxxxxxxxxxxx> wrote: > > > > > > > >> David, why is dma_is_consistent() always returning 1 on sparc? The > > > >> streaming DMA is not consistent. > > > > > > > > I think that there are some confusion about dma_is_consistent(). Some > > > > architectures think that dma_is_consistent() is supposed to return 1 > > > > if they can allocate coherent memory (note that some architectures > > > > can't allocate coherent memory). > > > > > > Right, and that's why it's defined this way. > > > > > > If the desired meaning is different, just me know and I'll fix the > > > sparc definition. > > > > I think that there are some other architectures do the same. We need > > to make sure that all the architectures define dma_is_consistent() in > > the same meaning if drivers need it. However, I'm not sure we really > > need dma_is_consistent(). There is only one user of it (and I think we > > could remove it). > > > > In the bnx2 case, we can simply prefetch on all the archs (or just > > remove the optimization). > > I think its worthwhile keeping, especially since the consistency can vary > on a per struct device level. If there's a benefit with these sorts of > prefetch micro-optimizations in drivers when it doesn't cost us that much > to provide the hint, I don't really see the harm. If dma_is_consistent() > is suddenly supposed to take on other meanings, or it's supposed to mean > something entirely different, then this is something we should deal with > separately. > > I don't see any harm in letting drivers know whether we can support > consistent DMA allocs for a given struct device or not though, even if > the micro-optimization is marginal at best. I'm happier with exporting less DMA APIs to drivers because looks like new original ways to use the APIs wrongly can be always invented. > At least I've conditionalized the definition on SH, and it seems other > archictures have done so too. It's not clear what we'd gain from throwing >From a quick look, except for SH and POWERPC (and always-coherent architectures), everyone does differently? There are architectures that need to turn off the CPU cache for coherent memory, I can't find none of them that see if an address is coherent or not in dma_is_consistent(). As I wrote, there is only one user of this API and we can remove it easily. Then I'm not sure it's worth fixing dma_is_consistent() in many architectures. I prefer to add this to feature-removal-schedule.txt to see if driver writers oppose. > that away as long as they're generally in agreement on what it means. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
