[lkml]   [2001]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

Jes Sorensen writes:
> >>>>> "David" == David S Miller <> 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.

David S. Miller

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.070 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site