Re: With Daniel Phillips Patch

["David S. Miller" <davem@redhat.com>]

   From: "Justin T. Gibbs" <gibbs@scsiguy.com>
   Date: Wed, 22 Aug 2001 12:32:17 -0600

   I would like the change much better if the size of dma_addr_t
   simply changed to be 64bits wide if high mem support is enabled
   in your kernel config.

Drivers for SAC only PCI devices shall not be bloated by 64-bit type,
not in any case whatsoever.

   Sure, you need the other API changes to more finely set dma characteristics,
   but having two APIs just complicates life for the device driver.

Either your device is 64-bit capable or not, what is so complicated?
Each driver I converted was like 15 minutes or work, at best!
   
   From the device driver's point of view, this wasn't the case.
   The driver asks to have the data mapped into an address that
   its dma engine can understand and the system is supposed to do that
   mapping.

What is the virtual address of physical address 0x100000000
on a 32-bit cpu system if the page is not currently kmap()'d?

Answer: it doesn't exist.

The only portable way is to use pages.  That is what Jens's and
my work aims to do.  The ia64 API is nonportable and works only
on 64-bit systems.

   >It also assumed that using SAC or DAC addressing was simply a matter of
   >"does the device support it", and the world is far from being that simple :-)
   
   Can you enumerate the devices that actually issue a DAC when loaded with
   a 64bit address with 0's in the most significant 32bits?

Sym53c8xx does this.  You have to configure it to do SAC or DAC
for data, descriptors use SAC always.
   
There will certainly be devices in the future which will only
support DAC cycles.

   Now that I'm supposed to use two differnt apis depending on what
   capabilities I enable in my driver, 

I think you are far overcomplicating things.  I mean, look at how
simple the conversion of some of the networking drivers was.  The
sym53c8xx driver conversion was very simple too, even with it's odd
current behavior due to addressing limitations.

It was nothing more than:

1) Adding probe time code to configure DMA attributes correctly.
   Failing the probe is no suitable mode could be determined.

   You know, it allows you to do something like this:

	pci_set_dma_mask(pdev, 0x1fffffffff);
	if (pci_dac_cycles_ok(pdev)) {
		dac_addressing_method = 1;
		goto dma_configured;
	}
	pci_set_dma_mask(pdev, 0x7ffffffffff);
	if (pci_dac_cycles_ok(pdev)) {
		dac_addressing_method = 2;
		goto dma_configured;
	}
	pci_set_dma_mask(pdev, 0xffffffffffffffff);
	if (pci_dac_cycles_ok(pdev)) {
		dac_addressing_method = 3;
		goto dma_configured;
	}
	if (!pci_dma_supported(pdev, 0xffffffff)) {
		probe_fail_msg();
		return -ENODEV;
	}
	dac_addressing_method = 0; /* Use SAC */

2) sed 's/dma_addr_t/dma64_addr_t/'
   sed 's/pci_{map,unmap,dma_sync}*/pci64_{map,unmap,dma_sync}*/'

And doing a cursory glance over the DMA address references
to make sure they weren't being put into u32's or something
similar.

Justin, have you even _TRIED_ to use the new API?

I did, on like 6 drivers, and it works just fine.

Later,
David S. Miller
davem@redhat.com