public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: paulus@samba.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: how to get virtual address from dma address
Date: Sat, 6 Oct 2001 14:04:19 -0400	[thread overview]
Message-ID: <200110061804.f96I4Jk03897@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1002355920.6872.linux-kernel2news@redhat.com>
In-Reply-To: <200110032244.f93MiI103485@localhost.localdomain> <d3n136tc48.fsf@lxplus014.cern.ch> <mailman.1002355920.6872.linux-kernel2news@redhat.com>

>[...]
> The argument for supplying this functionality in the PCI DMA code
> would be that if it was done there it could be done once, and in a
> sophisticated and efficient (and SMP-safe :) fashion, rather than
> ad-hoc in each driver.

This is exactly the kind of thinking that brought us pci_pool.
With all due respect to David-B, it was totally unnecessary,
in my view. However, attempts to make it "pretty" resulted in
something that cannot be implemented right. Just think if
pci_pool_free can be entered from an interrupt. If you allow
that, you cannot free full pages (because some broken architectures
implement pci_alloc_consistent with vmalloc, and vfree is not
interrupt safe). The root of the problem is an attempt to specify
variable sized pools.

I am afraid that if we start adding first class citizen APIs
in the area of pci_alloc_something, it's going to be more and
more interdependent and will place very strong constraints
on what architectures can and cannot do. For example, already
pci_alloc_consistent _cannot_ be implemented on some HP machines
(and, by extension, pci_pool).

> It may also be possible for the PCI DMA code to take advantage of its
> knowledge of a particular platform, for example if the platform only
> has a small range of possible DMA addresses then it could use a simple
> and fast lookup table.  Or it may be possible to read the IOMMU tables
> on some platforms and do the reverse mapping quickly that way - this
> would certainly be the case for the IBM RS/6000 machines since the
> IOMMU tables are in system RAM.

And it neither of these is possible, then what? Then you fall
back on the most generic code, which is the worst case of
all possible partial implementations in drivers.

-- Pete

  parent reply	other threads:[~2001-10-06 18:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-03 22:44 how to get virtual address from dma address James Bottomley
2001-10-04  0:24 ` David S. Miller
2001-10-04 10:11   ` BALBIR SINGH
2001-10-04 11:16     ` David S. Miller
2001-10-04 15:37   ` James Bottomley
2001-10-05 14:06 ` Jes Sorensen
2001-10-06  8:06   ` Paul Mackerras
2001-10-06  8:38     ` David S. Miller
2001-10-06 12:18       ` Paul Mackerras
2001-10-06 14:45         ` James Bottomley
2001-10-06 16:51           ` Gérard Roudier
2001-10-06 17:23         ` Jes Sorensen
2001-10-07  2:13           ` Paul Mackerras
2001-10-07 17:40             ` Jes Sorensen
2001-10-07  7:21           ` Gérard Roudier
2001-10-07 16:23             ` James Bottomley
2001-10-07 18:24               ` Gérard Roudier
2001-10-07 23:02                 ` James Bottomley
2001-10-08 21:06                   ` Gérard Roudier
     [not found]       ` <mailman.1002371041.9232.linux-kernel2news@redhat.com>
2001-10-06 18:19         ` Pete Zaitcev
     [not found]   ` <mailman.1002355920.6872.linux-kernel2news@redhat.com>
2001-10-06 18:04     ` Pete Zaitcev [this message]
     [not found] <Pine.LNX.4.21.0110031525370.14852-100000@pogo.esscom.com>
2001-10-03 21:48 ` Linux Bigot
2001-10-03 22:03   ` Ben Collins
2001-10-05 14:04   ` Jes Sorensen
  -- strict thread matches above, loose matches on Subject: below --
2001-10-03 21:30 Manfred Spraul
2001-10-03 16:37 Linux Bigot
2001-10-03 19:32 ` Ben Collins
2001-10-03 21:11   ` Linux Bigot
2001-10-03 21:23     ` Ben Collins
2001-10-03 14:11 Linux Bigot
2001-10-03 15:25 ` Jes Sorensen

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=200110061804.f96I4Jk03897@devserv.devel.redhat.com \
    --to=zaitcev@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.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