linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: "David S. Miller" <davem@redhat.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	zaitcev@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RFC: kills consistent_dma_mask
Date: 24 Aug 2003 14:06:43 +0200	[thread overview]
Message-ID: <m3n0dz5kfg.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <m3isoo2taz.fsf@trained-monkey.org>

Jes Sorensen <jes@trained-monkey.org> writes:

> I don't like this approach as I mentioned before. IMHO it is adding
> unnecessary overhead to the runtime point. Why should one pass in the
> mask 5 times when it is enough to use pci_set_consistent_dma_mask
> etc.

I don't see this overhead. Most (all?) drivers use a fixed mask such
as 0x00ffffff or keep track of the mask in their internal structures
(using_dac etc). The code has to get the mask anyway, either from
pci_dev->(consistent_)dma_mask or from its arguments. Currently the
information is duplicated in both PCI and the driver. I think it may
be even faster to examine a function argument on the stack than to get
the mask from pci_dev (is it?)

If the mapping function is inlined (as with i386 case) the mask can be
optimized to NOP (however, i386 does not currently use dma_mask in
pci_map_*() at all, and it's unclear if it could do that inline).

> I still haven't seen a strong argument for the current API being
> insufficient. Alan mentioned one device causing the problem with
> multiple consistent masks, but are there many more device like that
> out there?

There might be in the future.

In general drivers may need many classes of DMA-able memory. We could,
of course, do that, but I think it's simpler to let the driver
specify mask in every call.


There is one big problem with current API: the DMA (struct driver) API
does not have consistent_dma_mask. If the PCI API is implemented on top
of DMA API, it can't be correct (and, obviously, DMA API on top of PCI
API can't be correct either). So, if we insist on keeping
consistent_dma_mask in pci_dev structure, we need to add it to DMA API
as well. There is no trivial change which can fix this problem.

DMA API is the basis for other things so adding consistent_dma_mask to
it brings other but similar problems here and there.


IMHO the actual implementation of DMA and PCI APIs is quite a mess.
I don't know if there is at least one platform which does it according
to the docs. This means many devices will not work on some platforms
without any good reason.
Moving the masks out of device + pci_dev etc. structs and thus
simplifying the API would help cleaning the code. While it's not
a trivial task, it seems to be easier to fix (and then maintain) than
adding consistent|coherent dma_mask to DMA API etc.

I'm not DMA/PCI API expert (though I know it currently much much better
than 2 weeks ago). I'd appreciate any corrections.
In fact in the beginning I thought it will be much easier.
-- 
Krzysztof Halasa
Network Administrator

  reply	other threads:[~2003-08-24 13:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-17 22:34 [PATCH] RFC: kills consistent_dma_mask Krzysztof Halasa
2003-08-18  6:37 ` David S. Miller
2003-08-18 12:44   ` Krzysztof Halasa
2003-08-18 12:43     ` David S. Miller
2003-08-18 15:54       ` Krzysztof Halasa
2003-08-18 16:49         ` David S. Miller
2003-08-18 18:21           ` Krzysztof Halasa
2003-08-18 18:50             ` David S. Miller
2003-08-18 21:58               ` Krzysztof Halasa
2003-08-19  9:24                 ` Jes Sorensen
2003-08-19  9:21         ` Jes Sorensen
2003-08-18 13:00     ` Jes Sorensen
2003-08-18  8:07 ` Christoph Hellwig
2003-08-18 15:15 ` Pete Zaitcev
2003-08-18 16:14   ` Krzysztof Halasa
2003-08-19  9:16     ` Jes Sorensen
2003-08-19  9:49       ` Krzysztof Halasa
2003-08-19 10:15         ` Jes Sorensen
2003-08-19  9:03   ` Jes Sorensen
2003-08-19 13:07     ` Alan Cox
2003-08-19 13:20       ` Jes Sorensen
2003-08-19 16:55       ` David S. Miller
2003-08-19 18:33         ` Alan Cox
2003-08-19 18:31           ` David S. Miller
2003-08-19 20:31         ` Krzysztof Halasa
2003-08-22 11:54           ` Krzysztof Halasa
2003-08-23 17:11             ` Jes Sorensen
2003-08-24 12:06               ` Krzysztof Halasa [this message]
2003-08-24 13:00                 ` David S. Miller
2003-08-24 19:58                   ` Krzysztof Halasa
2003-08-25  8:50                     ` Jes Sorensen
2003-08-30 21:18                     ` Krzysztof Halasa
2003-08-31  1:50                       ` David S. Miller
2003-08-31 12:52                         ` Alan Cox
2003-08-31 15:24                           ` Krzysztof Halasa
2003-09-01  5:22                           ` David S. Miller
2003-09-01  7:34                             ` Krzysztof Halasa
2003-09-01  7:43                               ` David S. Miller
2003-09-01 17:14                                 ` Krzysztof Halasa
2003-09-01 17:28                                   ` David S. Miller
2003-09-01 18:24                                     ` Krzysztof Halasa
2003-09-01  7:54                             ` Alan Cox
2003-09-01  7:52                               ` David S. Miller
2003-09-01 16:27                                 ` Krzysztof Halasa
2003-09-01 17:33                                   ` David S. Miller
2003-08-25  8:47                 ` 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=m3n0dz5kfg.fsf@defiant.pm.waw.pl \
    --to=khc@pm.waw.pl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=jes@trained-monkey.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zaitcev@redhat.com \
    /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).