Messages in this thread | | | Date | Fri, 28 Feb 2003 11:17:29 -0700 | From | Deepak Saxena <> | Subject | Re: Proposal: Eliminate GFP_DMA |
| |
On Feb 28 2003, at 10:58, Jeff Garzik was caught saying: > On Fri, Feb 28, 2003 at 09:44:14PM +0600, Dmitry A. Fedorov wrote: > > > > But why drivers of ISA bus devices with DMA should use pci_* functions? > > > > I'm personally wouldn't have too much pain with GFP_DMA because I have > > compatibility headers and proposed change for them is tiny. > > Do not let the name "pci_" distract, it works for ISA too :) > > We can #define pci_xxx isa_xxx if you like :) > > Jeff
This discussion raises an issue that I've been meaning to bring up for a bit. Currently, the DMA-API is defined as returning a cpu physical address [1], but should the API be redefined as returning an address which is valid on the bus which the device sits on? For example, on most xscale systems I deal with, there's not a 1:1 mapping from physical to PCI memory space, so the address which is valid on the bus is not a valid CPU physical address. Imagine an SOC system with on-chip Ethernets and such that that have direct access to the physical bus, plus non-1:1 PCI translation. In such a case, I would need a physical address for the on-chip devices and a PCI bus address for the PCI devices. We can extend this case to a SOC which has on-chip peripherals on some custom FooBus with non-1:1 translation into physical memory. Now, depending on whether my device is on the PCI bus or on said FooBus, my dma_addr needs to have a different meaning.
One easy answer is to provide bus-specific bus_map/unmap/etc functions such as is done with PCI, but this seems rather ugly to me as now every custom bus needs a new set of functions which IMNHO defeats the purpose of a Generic DMA API. I think it would be a much cleaner solution to define the DMA API itself to return an address that is valid on the the bus pointed to by dev->bus. I don't think this would require any implementation changes at the moment, but it would be a more flexible definition of the API allowing for easy addition of new bus types with DMA capabilities. All the bus-specific magic would be hidden in the architecture-specific implementations on platforms that require different mappings for different buses, making the life of driver writers much simpler. On systems in which everything is 1:1 mapped between physical, PCI, and FooBuses, no changes would be required.
~Deepak
[1] From Documentation/DMA-API.txt in the 2.5 BK tree:
dma_addr_t dma_map_single(struct device *dev, void *cpu_addr, size_t size, enum dma_data_direction direction) dma_addr_t pci_map_single(struct device *dev, void *cpu_addr, size_t size, int direction)
Maps a piece of processor virtual memory so it can be accessed by the device and returns the _physical_ handle of the memory.
-- Deepak Saxena, Code Monkey - Ph:480.517.0372 Fax:480.517.0262 MontaVista Software - Powering the Embedded Revolution - www.mvista.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |