linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Gérard Roudier" <groudier@free.fr>
Cc: Jes Sorensen <jes@sunsite.dk>,
	paulus@samba.org, "David S. Miller" <davem@redhat.com>,
	James.Bottomley@HansenPartnership.com, linuxopinion@yahoo.com,
	linux-kernel@vger.kernel.org
Subject: Re: how to get virtual address from dma address
Date: Sun, 07 Oct 2001 11:23:47 -0500	[thread overview]
Message-ID: <200110071623.f97GNmD01704@localhost.localdomain> (raw)
In-Reply-To: Message from =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr>  of "Sun, 07 Oct 2001 09:21:05 +0200." <20011007091404.X953-100000@gerard>

> I would apply the bat to people that wants such a dma to virtual
> general translation. This thing is obviously gross shit.

If you read back in the thread, you'll find the proposed API was per 
pci_device and only when the device driver writer actually asked for it.  This 
makes it potentially as efficient as the code in sym53c8xx in the worst case 
and much more efficient in the best.

We have all agreed that just doing the mapping generally will be inefficient 
for a particular class of hardware with no readable access to its page tables.

> I would also apply the bat to people that look into stuff of other
> people and, instead of trying to actually understand the code, just
> give a look and send inappropriate statements to the list. 

The statement currently made to the list:

> Worse still, every driver that needs this feature is doing it on its own, so
> the code for doing this in usb-ohci is different from the code in the
> sym53c8xx driver etc. 

Is true: both drivers use hashes to do dma to virtual mapping.  They both have 
their own code for doing it (I have looked).  We can disagree about whether 
the code is subtle or complex, but you can't deny that these two drivers have 
separate implementations of the same function.

> In my opinion, any bus_to_virt() thing hurts a lot. It only makes
> sense if it refers to the virt_to_bus() mapping that was used to
> generate the bus address and assumes the reverse function to be a
> mapping. A general bus_to_virt() thing looks so ugly thing to me that
> I donnot want to ever use such.

Right, but we're not arguing over whether to do it generally.  The argument is 
whether an API looking like this:

pci_register_mapping(struct pci_dev *dev, void *virtualAddress, dma_addr_t 
dmaAddress, size_t size);
void *pci_dma_to_virtual(struct pci_dev *dev, dma_addr_t dmaAddress);
dma_addr_t pci_virtual_to_dma(struct pci_dev *dev, void *virtualAddress);
pci_unregister_mapping(struct pci_dev *dev, void *virtualAddress, dma_addr_t 
dmaAddress, size_t size);

should or should not be provided.

For this API I claim that:

1. I can do the worst case MMU hardware as efficiently as your driver (because 
it would essentially be a hashed look up of registered mappings for your 
single pci device instance alone, functionally identical to the code you use 
today).

2. on optimal hardware (like x86 where this can be done by bit flipping of the 
address) I can do a whole lot better.

I also claim the same is true for every driver which still needs to do this 
type of mapping (which is a significant fraction of drivers for devices which 
have an intelligent processor core and multiple outstanding jobs with a 
non-predictable order of completion).

Therefore, every driver that needs to do this today is using the least 
efficient method.  Further, they're all coding their own least efficient 
methods.

If you can provide a reasoned counter argument to the above (preferably 
stripped of the invective periphrasis) I'm listening.

James Bottomley


  reply	other threads:[~2001-10-07 16:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1002355920.6872.linux-kernel2news@redhat.com>
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:38     ` David S. Miller
2001-10-06 18:19       ` Pete Zaitcev
2001-10-06 18:04     ` Pete Zaitcev
2001-10-06  8:06   ` Paul Mackerras
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  7:21         ` Gérard Roudier
2001-10-07 16:23           ` James Bottomley [this message]
2001-10-07 18:24             ` Gérard Roudier
2001-10-07 23:02               ` James Bottomley
2001-10-08 21:06                 ` Gérard Roudier
2001-10-07  2:13       ` Paul Mackerras
2001-10-07 17:40         ` Jes Sorensen
     [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
2001-10-03 21:30 Manfred Spraul
  -- strict thread matches above, loose matches on Subject: below --
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=200110071623.f97GNmD01704@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=davem@redhat.com \
    --cc=groudier@free.fr \
    --cc=jes@sunsite.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxopinion@yahoo.com \
    --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;
as well as URLs for NNTP newsgroup(s).