From: Pete Zaitcev <zaitcev@redhat.com>
To: Jes Sorensen <jes@wildopensource.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] support 64 bit pci_alloc_consistent
Date: Sun, 18 May 2003 03:05:22 -0400 [thread overview]
Message-ID: <200305180705.h4I75MT13787@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1053231184.22467.linux-kernel2news@redhat.com>
> The default mask for pci_alloc_consistent() is still 32 bit as there are
> 64 bit capable hardware out there that doesn't support 64 bit addresses
> for descripters etc.
I think this is a mix-up of concepts. You mean aic7xxx, right?
IMHO, it's an example of a device which needs various masks
for different allocations. As it happens, the driver uses
consistent allocations with one mask, streaming allocations
with other mask. This is a pure coincidence, however. Being
consistent or streaming is one thing, and asking for various
masks is another thing.
But I see that there may be practical differences if we suddenly
make pci_set_dma_mask act upon consistent allocations. So,
perhaps you're right... Let's add a call...
> @@ -94,6 +103,11 @@
>
> int pci_set_dma_mask(struct pci_dev *pdev, u64 device_mask);
>
> +The query for consistent allocations is performed via a a call to
> +pci_set_consistent_dma_mask():
> +
> + int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_mask);
I think it's not a query, but a request, but I'm not a native
speaker.
> +pci_set_consistent_dma_mask() will always be able to set the same or a
> +smaller mask as pci_set_dma_mask(). However for the rare case that a
> +device driver only uses consistent allocations, one would have to
> +check the return value from pci_set_consistent().
pci_set_consistent_dma_mask, surely.
> + dev->consistent_dma_mask = mask;
> + u64 consistent_dma_mask;/* Like dma_mask, but for
> + pci_alloc_consistent mappings as
> + not all hardware supports
> + 64 bit addresses for consistent
> + allocations such descriptors. */
> +int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask);
This is cool, but where is the implementation?
I do not see anyone honouring the ->consistent_dma_mask
in the patch. I'm stupid, right?
-- Pete
next parent reply other threads:[~2003-05-18 6:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1053231184.22467.linux-kernel2news@redhat.com>
2003-05-18 7:05 ` Pete Zaitcev [this message]
2003-05-18 4:09 [patch] support 64 bit pci_alloc_consistent Jes Sorensen
2003-05-18 5:46 ` David S. Miller
2003-05-18 6:00 ` Andre Hedrick
2003-05-18 9:29 ` Arjan van de Ven
2003-05-18 9:35 ` David S. Miller
2003-05-18 9:43 ` Arjan van de Ven
2003-05-18 14:17 ` James Bottomley
2003-05-18 14:21 ` Arjan van de Ven
2003-05-18 14:28 ` James Bottomley
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=200305180705.h4I75MT13787@devserv.devel.redhat.com \
--to=zaitcev@redhat.com \
--cc=jes@wildopensource.com \
--cc=linux-kernel@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