Subject: Re: bus_dmamap_sync() in ti(4) or the lack thereof
To: Tobias Nygren <tnn+nbsd@nygren.pp.se>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: tech-kern
Date: 03/01/2007 18:53:11
On Wed, Feb 28, 2007 at 12:52:21AM +0100, Tobias Nygren wrote:
> Izumi Tsutsui wrote:
> >tnn+nbsd@nygren.pp.se wrote:
> >
> >  
> >>ti(4) doesn't work right on sparc64. With DIAGNOSTIC i get tons
> >>of "iommu_dvmamap_load: map still in use".
> >>    
> >
> >This is usually caused by missing bus_dmamap_unload(9).
> >(IMHO other ports should have the similar assersions)
> >
> >  
> >>I took a glance at the ti(4) code and noticed the absence of any
> >>preread/postread dma syncs, despite the fact that the driver relies
> >>heavily on reuse of dma maps. This can't be right, can it?
> >>    
> >
> >It should have proper sync calls otherwise it won't work on
> >non DMA coherent architecture (like sgimips O2) or architectures
> >which require bounce buffer (like some alpha), but many FreeBSD's
> >drivers often lack them since they are not required by "major" ports ;-p
> >
> >  
> >>The fact that the driver appears to reload maps without unloading
> >>them first might be caused by something else, though.
> >>    
> >
> >It seems bus_dmamap_unload(9) is needed before calling ti_newbuf_jumbo()
> >or ti_newbuf_mini() in ti_rxeof().
> >---
> >Izumi Tsutsui
> >  
> 
> For what it's worth, this patch fixes the problems I had.
> I'm not sure what to do about the jumbo case, because it uses a single
> dmamap for all descriptors.

For jumbo frame you have to bus_dmamap_sync() with the offset/size of the
packet inside the large buffer. For example see the code I added
recently to bge.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--