Subject: Re: Slight optimization for bus_dma(9) API.
To: Jason R Thorpe <thorpej@zembu.com>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 07/19/2001 00:36:16
Looks good to me. Hey, this is all starting to look like .... 

On Wed, 18 Jul 2001, Jason R Thorpe wrote:

> Hi folks...
> 
> I would like to add 2 flags to the bus_dma(9) API, to be used with
> the bus_dmamap_load*() family of routines.
> 
> 	BUS_DMA_INBOUND		Transfer is BUS->RAM direction.
> 
> 	BUS_DMA_OUTBOUND	Transfer is RAM->BUS direction.
> 
> These flags would be mutually-exclusive.  If you specify one, it
> specifies the direction that the transfer will perform.  It is
> meant to allow machine-dependent code to make optimizations based
> on the direction.  If neither flag is specified, no directional
> optimization will be performed.
> 
> I want this primarily for the Alpha port.  For the Alpha SGMAP
> (DMA address MMU), for the RAM->BUS (OUTBOUND) direction, the
> PCI controller will pre-fetch the next page of memory if the
> current DMA address comes within a certain distance of the next
> page.  This is meant to prevent the DMA pipeline from stalling.
> 
> Unfortunately, if you reach the prefetch threshold on the *last
> page* of the DMA transfer, then you need to have an extra PTE
> after the end of the buffer to map a "spill page".  Otherwise,
> you will get a machine check when the PCI controller attempts
> to fetch a page that is not mapped by the DMA MMU.
> 
> If I know which the direction is going to be used when the map
> is loaded, I can avoid allocating the spill page in certain
> cases, for example, for all in-bound traffic :-)
> 
> It was also suggested to me that you could cache a pointer to
> a dmamap_sync routine that performs fewer tests, as well.
> 
> Note that machine dependent code can choose to ignore the flags,
> and drivers can choose not to use them.  They are merely to
> allow for an optimization.
> 
> If there are no objections, I'll go ahead and add this before the
> end of the week.
> 
> -- 
>         -- Jason R. Thorpe <thorpej@zembu.com>
>