public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: 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()
Date: Fri, 18 Jun 2010 00:30:51 +0900	[thread overview]
Message-ID: <20100617153051.GB8964@linux-sh.org> (raw)
In-Reply-To: <20100617234520S.fujita.tomonori@lab.ntt.co.jp>

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@davemloft.net> wrote:
> 
> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > Date: Thu, 17 Jun 2010 21:21:13 +0900
> > 
> > > On Wed, 16 Jun 2010 23:24:44 -0700
> > > "Michael Chan" <mchan@broadcom.com> 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.

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
that away as long as they're generally in agreement on what it means.

  reply	other threads:[~2010-06-17 15:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17  1:13 bnx2 fails to compile on parisc because of missing get_dma_ops() James Bottomley
2010-06-17  1:16 ` David Miller
2010-06-17 12:13   ` FUJITA Tomonori
2010-06-17  1:17 ` Mike Frysinger
2010-06-17  3:53   ` Michael Chan
2010-06-17  4:00     ` Mike Frysinger
2010-06-17  4:03     ` Paul Mundt
2010-06-17  4:10       ` Michael Chan
2010-06-17  6:24         ` Michael Chan
2010-06-17 12:21           ` FUJITA Tomonori
2010-06-17 14:36             ` David Miller
2010-06-17 14:50               ` FUJITA Tomonori
2010-06-17 15:30                 ` Paul Mundt [this message]
2010-06-22  6:30                   ` FUJITA Tomonori
2010-06-22 17:14                     ` Grant Grundler
2010-06-22 17:26                     ` James Bottomley
2010-06-23  0:38                       ` FUJITA Tomonori
2010-06-17  4:20     ` James Bottomley
2010-06-17 12:13     ` FUJITA Tomonori
2010-06-17 12:54       ` Michael Chan
2010-06-17 13:12         ` James Bottomley
2010-06-17 13:30           ` Michael Chan
2010-06-17 13:36             ` James Bottomley
2010-06-17 14:05             ` FUJITA Tomonori
2010-06-17 14:42               ` Michael Chan
2010-06-17 14:50               ` FUJITA Tomonori
2010-06-17 15:52                 ` David Miller
2010-06-17 12:13 ` FUJITA Tomonori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100617153051.GB8964@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=JBottomley@novell.com \
    --cc=davem@davemloft.net \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox