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 09:53:50
On Thu, 13 Aug 1998, Chuck Cranor wrote:

> >I have an efficient ATM card in my sparc 2 box, and I would like
> >to use it.  It is not in the sparc generic config, so I added the
> >following line
> >When I did 'make depend', it showed two redefinition warnings of
> >bus_space_read_4 and bus_space_write_4 in if_en.c and
> >machine/sbus.h.  
> 
> the problem here is that i created if_en_sbus.c before the sparc
> port had the bus_space functions available so I faked it in midwayreg.h.
> now that sparc has those macros this hack should be turned off.
> 
> there is also the issue of setting up for DMA on systems with IOMMUs
> (sun4m systems).  i don't think that is properly addressed in the
> driver either, but that shouldn't be a problem for the sparc2?
> hard to say since i have not looked at the sparc in a while.   maybe
> pk (when he gets back from holiday) or mrg can fill in the gaps here?

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).  There
also should be calls to bus_dmamap_sync() (which I don't think we're doing
now) before and after accessing any of the memory that was DMA'ed from or
to.  This is needed for any possible flushing of the CPU's cache or any
I/O cache, although this is usually a non-issue since most of our hardware
does consistent DMA.

Lookin in `midwayreg.h', It would be a good idea to remove the
compatibility bus.h stuff since there's the line:

#define vtophys(x) ((u_int32_t)(x))     /* sun4c dvma */

This implies that you will have DVMA issues.

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