Subject: Re: Slight optimization for bus_dma(9) API.
To: Jason R Thorpe <email@example.com>
From: Matthew Jacob <firstname.lastname@example.org>
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 <email@example.com>