Messages in this thread | | | Date | Sun, 18 May 2003 03:05:22 -0400 | From | Pete Zaitcev <> | Subject | Re: [patch] support 64 bit pci_alloc_consistent |
| |
> 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/
| |