public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: PCI DAC routines for SN
Date: Thu, 25 Apr 2002 01:22:14 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905526@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905493@msgid-missing>

On Wed, Apr 24, 2002 at 06:00:23PM -0700, David S. Miller wrote:
> The DMA api is confusing enough, and you want to add yet another
> interface for device driver author Joe Blow to have to learn?

What if it's just a simple flag (or mask like dma_mask) that the
driver optionally sets to true (or 64 bits)?  That way, the drivers
wouldn't have to change at all and the default behaviour would be
identical to the current API?

Of course, this only make sense if you acknowledge that (2) is at
least of some small concern (small, simple fix for a small, simple
problem).

> This basically boils down to the fact that it must do one of two
> things:
> 
> 1) It must make performance phenominally better.
> 
>    In the DAC consistent case, it actaully will decrease bus
>    utilization slightly, we agree on this.
> 
> 2) It must make some DMA performance optimization possible which
>    currently is not possible at all.
> 
>    I do not believe this is the case.  You've tried to argue that
>    SAC consistent memory is precious for mappings, and I've tried
>    to show you that the consistent part of the mappings used by
>    devices won't even show up on the radar.
> 
> We are at an impasse' and I really doubt this is going to change.
> All you can do by arguing further is just make me type the same
> things a few more times, and I'd like to avoid that, I type enough
> already. :-)

I know the feeling.  At any rate, thanks for the lively discussion.
It's been educational.

Jesse


      parent reply	other threads:[~2002-04-25  1:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-22 22:34 [Linux-ia64] Re: PCI DAC routines for SN David Mosberger
2002-04-22 22:39 ` Jesse Barnes
2002-04-22 23:07 ` David Mosberger
2002-04-22 23:40 ` Jesse Barnes
2002-04-23  1:34 ` Grant Grundler
2002-04-23 21:11 ` Grant Grundler
2002-04-24  4:04 ` David S. Miller
2002-04-24  5:49 ` Jesse Barnes
2002-04-24  5:50 ` David S. Miller
2002-04-24 16:13 ` Grant Grundler
2002-04-24 17:39 ` David S. Miller
2002-04-24 17:40 ` David S. Miller
2002-04-24 19:45 ` Jesse Barnes
2002-04-24 23:13 ` Jesse Barnes
2002-04-24 23:53 ` David S. Miller
2002-04-25  0:08 ` David S. Miller
2002-04-25  0:11 ` Jesse Barnes
2002-04-25  0:17 ` David S. Miller
2002-04-25  0:21 ` Jesse Barnes
2002-04-25  0:36 ` Jesse Barnes
2002-04-25  0:43 ` David S. Miller
2002-04-25  1:00 ` David S. Miller
2002-04-25  1:01 ` Jesse Barnes
2002-04-25  1:22 ` Jesse Barnes [this message]

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=marc-linux-ia64-105590701905526@msgid-missing \
    --to=jbarnes@sgi.com \
    --cc=linux-ia64@vger.kernel.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