[openib-general] [PATCH v2 1/7] IB/core - Add DMA mapping functions to allow device drivers to interpose

Ralph Campbell ralph.campbell at qlogic.com
Wed Dec 6 10:16:34 PST 2006


On Wed, 2006-12-06 at 13:33 +0200, Or Gerlitz wrote:
> Ralph Campbell wrote:
> > On Tue, 2006-12-05 at 23:21 +0200, Or Gerlitz wrote:
> >> On 12/5/06, Roland Dreier <rdreier at cisco.com> wrote:
> > I am not following what you two are saying.
> 
> > The ib_dma_mapping_ops functions as implemented by ib_ipath,
> > are redefining dma_addr_t as a kernel virtual address.
> > When ib_dma_map_single() is called, this is a NOP.
> > When ib_dma_map_sg() is called, the dma_map_sg() replacement needs
> > to convert a struct page pointer into a kernel virtual address.
> > When CONFIG_HIGHMEM is defined, some pages may not be mapped
> > into the kernel virtual address space so the driver needs to
> > call kmap().  Since the driver can't use the struct scattergather
> > to store the kmap() result, a separate table needs to be used
> > so the value can be returned by ib_sg_dma_address().
> 
> Indeed.
> 
> > Doing kmap_atomic() at the point where the kernel virtual
> > address is used is not practical since the driver is not
> > mapping dma_addr_t to struct page * although it is
> > possible to write it that way.  It would mean that
> > ib_map_single() would then be more complex in that a
> > kernel virtual address would need to be converted to a
> > struct page *.
> 
> Basically what Roland suggest is that you need to implement SW IOTLB 
> mapping from dma_addr_t (possibly offset-ed) to kv addr. And do the 
> actual kmap/unmap calls before/after you must touch the data.
> 
> Is this impossible?
> 
> Or.

It is not impossible, just inefficient.  Why add a mapping
table when it isn't needed?  If I needed to implement HIGMEM
support, I would probably make "dma_addr_t" be a physical
memory address, convert to PFN, find the struct page pointer,
and call kmap_atomic() or page_address().  Why go though all
that in the worst case CPU path when doing the conversion
to kernel virtual address outside the critical path is
feasible?





More information about the general mailing list