From: Grant Grundler <grundler@parisc-linux.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: lethal@linux-sh.org, 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: Tue, 22 Jun 2010 11:14:45 -0600 [thread overview]
Message-ID: <20100622171445.GB8644@lackof.org> (raw)
In-Reply-To: <20100622152823R.fujita.tomonori@lab.ntt.co.jp>
On Tue, Jun 22, 2010 at 03:30:08PM +0900, FUJITA Tomonori wrote:
...
> > 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.
Agree.
...
> 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().
parisc "knows" primarily based on chipset and then checks CPU model.
We hook in the correct dma_ops early in boot before any device drivers
are probed.
hth,
grant
next prev parent reply other threads:[~2010-06-22 17:14 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
2010-06-22 6:30 ` FUJITA Tomonori
2010-06-22 17:14 ` Grant Grundler [this message]
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=20100622171445.GB8644@lackof.org \
--to=grundler@parisc-linux.org \
--cc=JBottomley@novell.com \
--cc=davem@davemloft.net \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=lethal@linux-sh.org \
--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