Re: (reposting) how to get DMA'able memory within 4GB on 64-bit m achi ne

[David S. Miller]

Jes Sorensen writes:
 > >>>>> "David" == David S Miller <[e-mail]> 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
[e-mail]