On Tue, Mar 07, 2000 at 12:59:53AM -0800, David S. Miller wrote:
> You want the equivalent of bus_to_virt(), most people
> don't need the facility because the driver either
>
> 1) Doesn't need a bus_to_virt() operation
>
> or
>
> 2) Does need it, but can easily keep track of the dma vs.
> cpu pointers to accomplish the same goal, and because we
> lack this interface the implementation for a given architecture is
> simpler and less complex
>
> That is why, so make your driver do #2. Store the DMA address and
> CPU address somewhere in your driver software state, and then you
> can easily convert a pointer within one view to a pointer in the
> other, and vice versa.
>
> The bus_to_virt() interface is just for lazy driver authors :-)
I would hope I'm not too lazy, but I don't want to add unnecessary
overhead to my code.
A bit of background... the hardware I'm using is passed descriptors
(big endian bus addresses) in queues. There is a pair of transmit
queues (pending items and completions) and four pairs of receive
queues. An item in an outgoing receive queue consists of the skb->data
pointer and an opaque (to the adapter) u32 handle. An item in an
incoming receive queue consists of the handle plus some status info.
Similar things happen with trasmit descriptors. [ambassador.h]
My existing driver uses u32 handle = bus_to_virt(skb). There is no
equivalent under the new DMA mapping scheme. Any change to the driver
would involve more state handling (space and time costs) to all archs.
Making an inverse mapping function available would allow me to change
to the new API without impacting the 32-bit ones. As an aside, note
that this would be a non-buggy use of
pci_map_single (dev->pci_dev, skb, 0?, PCI_DMA_NONE).
I suppose there are two questions:
1. can an inverse even be defined?
I would imagine yes, as how else does/will pci_unmap_single work? - it
would probably be enough to make pci_unmap_single return the original
CPU address, or add a separate function if this would slow down
pci_unmap_single or if you don't always want to unmap at this point.
2. in the architectures (or current architectures in the future) where
mapping actually does something, is
handle = pci_map_single(address); address = pci_invertmap_single(handle)
that I suggest above going to be cheaper or more expensive than the driver
carrying extra state around?
If it would be much more expensive then I would ask for a #if define
to made available so that I can conditionally include the extra state
handling (or it might even be possible to do it generically and
magically like spinlocks with respect to CONFIG_SMP).
If it would be cheaper, then the invert map function ought to (well,
certainly _could_) be added (trivially in the case of the u32 archs).
> and why ia64 has a 64-bit dma_addr_t.
>
> It probably shouldn't, because it represents 32-bit
> addresses in all the cases the pci.h interface supports.
> (and this does not exclude 64-bit PCI devices, they
> just will use a 32-bit single-address-cycle since
> the high 32-bits of a DMA address will be all zeros,
> as per the PCI specs)
Good!
Giuliano.
-- mail: gprocida@madge.com / myxie@debian.org | public PGP key ID: 93898735 home: +44 181 351 1172 / Flat 5, 135 Palmerston Road, London N22 8RW, UK work: +44 1753 661 305 / Madge Networks, Wexham Springs, Slough SL3 6PJ, UK- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:22 EST