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/
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 22:00:49 EST