Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754299Ab0FVGa1 (ORCPT ); Tue, 22 Jun 2010 02:30:27 -0400 Received: from sh.osrg.net ([192.16.179.4]:56981 "EHLO sh.osrg.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752628Ab0FVGaZ (ORCPT ); Tue, 22 Jun 2010 02:30:25 -0400 Date: Tue, 22 Jun 2010 15:30:08 +0900 To: lethal@linux-sh.org Cc: fujita.tomonori@lab.ntt.co.jp, davem@davemloft.net, mchan@broadcom.com, vapier@gentoo.org, JBottomley@novell.com, netdev@vger.kernel.org, linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: bnx2 fails to compile on parisc because of missing get_dma_ops() From: FUJITA Tomonori In-Reply-To: <20100617153051.GB8964@linux-sh.org> References: <20100617.073653.193708702.davem@davemloft.net> <20100617234520S.fujita.tomonori@lab.ntt.co.jp> <20100617153051.GB8964@linux-sh.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20100622152823R.fujita.tomonori@lab.ntt.co.jp> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sh.osrg.net [192.16.179.4]); Tue, 22 Jun 2010 15:30:10 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3236 Lines: 68 On Fri, 18 Jun 2010 00:30:51 +0900 Paul Mundt 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 wrote: > > > > > From: FUJITA Tomonori > > > Date: Thu, 17 Jun 2010 21:21:13 +0900 > > > > > > > On Wed, 16 Jun 2010 23:24:44 -0700 > > > > "Michael Chan" 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/