> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:30 EST