DMA changes in 2.3.41 - how the f* do I get this working on ARM?

[Jes Sorensen]

>>>>> "Jakub" == Jakub Jelinek <jakub en redhat.com> writes:

>>  Hmmm ok I just noticed this and I haven't read that DMA mapping
>> document yet. I'll have to look at it to see how it affects PCI
>> devices that are 64 bit address capable.

Jakub> The whole interface is currently for SAC. For using DAC, you
Jakub> need arch details how to build the DAC address (e.g. on
Jakub> UltraSPARC you usually want 0xfffc in bits 63:50 to set DMA
Jakub> bypass) and it really depends if it is a gain or lose (with SAC
Jakub> and dynamic mapping, you can manage to collapse a bunch of sg
Jakub> chunks into one sg entry, while with DAC you cannot. Also, with
Jakub> SAC on sparc64 PCI chips you can specify whether you want
Jakub> streaming mode or not, while with bypass it is always
Jakub> consistent if I remember well - the cacheability is determined
Jakub> from the physical address though). On the other side with DAC
Jakub> you save filling up the IOPTEs and clearing them after.

Sure for 32 bit cards thats true, however DACs should theoretically
allow us to DMA into the 36 bit address space on the x86 boxes?
However, I was actually mainly thinking about 64 bit PCI cards,
there's a fair amount of them out now and it would be nice to support
it properly on hardware that has 64 bit PCI slots.

>>  The one thing for the m68k is that we have very few machines with
>> PCI, though we still suffer a lot from the DMA coherency problem on
>> the busses we do have.

Jakub> The API is pci_* because it takes a struct pci_dev *. SBUS has
Jakub> identical API with sbus_* which takes struct sbus_dev *.  The
Jakub> goal is to merge all bus device structures into struct pci_dev
Jakub> (but keeping as much as possible bus specific things in
Jakub> sysdata) and call it a generic hardware device structure. Then
Jakub> all those interfaces can be merged, its just the changes need
Jakub> to be incremental (Linus did not like introducing device_t type
Jakub> and casting struct pci_dev etc. structures to it and back so it
Jakub> got removed from the patch).

Long term merge to a generic device interface sounds good to me. The
DMA mappings document got as far as the printer now, next step will be
to read it.

>>  The place where this is a real problem is in drivers where data is
>> shared between the adapter and the host CPU, for instance the
>> 53c7xx driver. On the m68k we currently use a
>> kernel_set_cachemode() function to change the caching of the page
>> allocated for the shared structures, but thats a pretty non
>> portable way of doing it. I would like to see something a
>> get_free_cachecoherent_page() interface instead, what do you think
>> of that?

Jakub> Why cannot you do this in pci_alloc_consistent?

Because the machine in question doesn't have the slightest idea what
PCI means ;-) But yes, I will look at the new PCI interface and see if
we can use that.

Jes

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/