Subject: Re: ATM en0 driver on sbus
To: Chuck Cranor <chuck@maria.wustl.edu>
From: Eduardo E. Horvath <eeh@one-o.com>
List: port-sparc
Date: 08/14/1998 11:23:34
On Fri, 14 Aug 1998, Chuck Cranor wrote:

> In your letter dated Fri, 14 Aug 1998 09:53:50 -0700 (PDT), you wrote:
> >You should be using bus_dmamem_alloc() and bus_dmamem_map() for any memory
> >that the chip will be doing DMA to/from (see dev/sbus/if_le.c).  
> 
> right, although it will be much more complicated for the midway
> because the driver DMAs directly to/from the data areas of an mbuf.
> [i.e. it doesn't do any data copying at the driver layer...]  
> so you will have to map and unmap each mbuf you get as you receive
> them.  i don't think bus_dmamem_alloc() will be useful since we
> always deal with mbufs whose data areas are already allocated?

Oh, I thought it was like le in that the DMA memory was pre-allocated.
This is much easier, even though `bus_dmamap_load_mbuf()' does not exist
yet.  Use `bus_dmamap_create()' for each concurrent DMA mapping you want,
`bus_dmamap_load()' to associate itself with the mbuf, load the
sc_dmamap->dm_segs[0].ds_addr into the DMA engine, and then call
`bus_dmamap_unload()' when the DMA is finished.  No need to destroy the
dmamap.  

You can look at dma.c in either arch/sparc/dev or arch/sparc64/dev as an
example.  The esp portion of the driver uses this technique, although
since it only has one unintelligent DMA engine it only uses one dmamap per
driver instance.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me