PCI 64-bit API up for testing

As discussed much of last week between Jens and myself, we need a PCI 64-bit API to make progress in certain areas. It is needed for other reasons, but what Jens is trying to solve exacerbates this need.

Jens's current highmem no-bounce patches include this stuff, but we feel it is useful to distribute just these changes independantly. Especially for review and to acquire help from port maintainers.

I held off until today because I wanted to convert a few drivers first for two reasons:

1) To provide useful 64-bit driver examples.
2) To make sure the API worked and was usable. A lot of details were not fleshed out until I actually tried to use the API I had initially created :-)

So this patch serves two purposes. First, it's for review and to get feedback from other hackers and driver authors. Second, it is for platform authors so that they can send me the updates for their port.

Most platforms which are simple and never have more than 4GB ram will simply define the pci_*() routines to pci64_*(), make pci_dac_cycles_ok() always return '0' and define dma64_addr_t to be typedef'd to "u32".

If platform maintainers could do this and send me an incremental diff, I would appreciate it.

Currently it is "ported" and tested on ix86 and Sparc64.

Get the latest at:

ftp://ftp.kernel.org/pub/linux/kernel/people/davem/PCI64/

I've moved the older zerocopy stuff, which used to be at the top level under davem/, to:

ftp://ftp.kernel.org/pub/linux/kernel/people/davem/ZEROCOPY/

Later,
David S. Miller
[email protected]

Here's bits for Alpha vs 2.4.9 + pci64 patch 3. It's not been tested seriously, since I have no 64-bit capable devices. But it looks mostly ok, and continues to boot on a number of machines.

Something that should be mentioned in the documentation for someone implementing these functions is that drivers will call the pci64 interfaces *even if* pci_dac_cycles_ok returns false, which means that one has to remember what decisions were made in that function.

I'm undecided on whether we should consider such nonsense illegal.

On the one hand, it clutters up the pci mapping functions, and it is easy to forget all the proper checks. The sparc64 version, for instance, will do the wrong thing if PCI_DMA_FLAG_HUGE_MAPS is set and the device supports less than 64 bits of addressing.

On the other hand, I can also see that requiring that the driver call the correct sets of functions based on what mode it's in will clutter up driver source. Given that there are more drivers than architectures, it makes sense to keep them as clean as may be.

r~

Thanks tossing this together Richard.

I might swizzle the API a little bit after listening to feedback I have gotten back so far, but I can easily munge your work into whatever I end up with.

Later,
David S. Miller
[email protected]