On Thu, Feb 03, 2000 at 02:19:19PM -0800, Leo Dagum wrote:
> So the idea is that pci_alloc_consistent() is for quick and dirty
> use and pci_map_* are for more advanced use? Presumably the driver
> has done the memory allocation for pci_map_* right? If that's the
> case, I have no problem with it, just a different philosophy on
> interfaces than what I'm used to.
No, the idea is that pci_alloc_consistent is used for dma areas that
are used multiple times, like Ethernet rings buffers or SCSI HA CDB's.
The allocation of the memory really needs to be done outside of the
driver because which Intel hacker would know that on MIPS I might need
to access my Ethernet ring buffers via KSEG1?
pci_{,un}map_{single,sg} are for _streaming_ mappings. A typical use
would be for data to/from disk. The document says explicitly
streaming, I also didn't noticed this before. So you could think of
them basically like implicitly having set the flag PCIIO_DMA_DATA.
The expectation is that it's being used for mappings which are relativly
large and also sufficiently aligned, such that the driver doing it's
own allocation would not be a problem.
(Even silly stuff like the Deskstation Tyne's 512kb DMA buffer SRAM,
basically a bounce buffer for DMA data, could be hidden there.)
> That's great news! So they're going to add flags to the interface? Can
> we get a flag like PCIIO_DMA_A64 so we can distinguish between 32-bit
> and 64-bit capable cards?
All routines get a struct pci_dev * as the first argument. I wonder
if 64-bitiness of a device can be enquired via this pointer? Somebody
with a PCI spec know the answer?
> Also is there any chance they would consider
> splitting the pci_map_* interface into an "allocate_resources" and a
> actual "map"?
Don't know.
Ralf
|