Jes Sorensen writes:
> >>>>> "David" == David S Miller <davem@redhat.com> writes:
>
> David> Jes Sorensen writes:
> >> Because on ia64 you will get back a 64 bit pointer if you use
> >> pci_set_dma_mask() to set a 64 bit mask before calling the pci
> >> functions in question.
>
> David> Please note that this is nonstandard and undocumented behavior.
>
> David> This is not a supported API at all, and the way 64-bit DMA will
> David> eventually be done across all platforms is likely to be
> David> different.
>
> Well please also note there has been requests for proper 64 bit DMA
> support for over 3 years or so by now.
Hey Jes, figure this out, I did all the work to get proper 32 bit DMA
to work. I was waiting 3 years for that and I did all the work
myself. I was patient, people needing 64-bit DMA can be patient as
well and wait 1 or 2 weeks for 2.5.x to start up so we can make these
kinds of changes.
> The interface we use works well, so why should it be changed for other
> architecures? Instead it would make a lot more sense to support it on
> other architectures that can do 64 bit DMA.
Because it makes not one iota of sense to have a 64-bit dma_addr_t on
a 32-bit system where none of this DAC crap is relevant.
That is why.
Send Linus a patch which makes dma_addr_t 64-bit on ix86, see how far
you get. And I would totally agree with him, the overhead of the
larger type is totally stupid for %99 of cases on x86.
Sure, if HIGHMEM or whatever is set, it may make sense. But I think
eating the 64-bit type in all drivers using dma_addr_t, even one's
only capable of 32-bit PCI addressing, is bogus as well.
This is why I wanted a seperate dma64_addr_t and pci64_*() routines to
match. So the overhead only existed where it was absolutely needed.
People already bark at me about the overhead of adding dma_addr_t when
"virt_to_bus and bus_to_virt worked perfectly fine without having to
keep track of these DMA cookies everywhere" and to a certain extent
they are right. So we should avoid making this worse when possible.
Later,
David S. Miller
davem@redhat.com
-
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 : Sat Jun 30 2001 - 21:00:20 EST