linux-origin
[Top] [All Lists]

Re: dynamic dma interface

To: linux-origin@xxxxxxxxxxx
Subject: Re: dynamic dma interface
From: "Leo Dagum" <dagum@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 3 Feb 2000 14:19:19 -0800
In-reply-to: Ralf Baechle <ralf@xxxxxxxxxxx> "Re: dynamic dma interface" (Feb 3, 1:30pm)
References: <200002020735.XAA16262@xxxxxxxxxxxxxxxxxxx> <20000203133058.A734@xxxxxxxxxxxxxx>
Sender: owner-linux-origin@xxxxxxxxxxx
On Feb 3,  1:30pm, Ralf Baechle wrote:
> Subject: Re: dynamic dma interface
> On Tue, Feb 01, 2000 at 11:35:03PM -0800, Leo Dagum wrote:
>
> > Proposal
> > --------
> > The issues above could be addressed fairly easily.  First of all, there's
> > no need for pci_alloc_consistent() to allocate the memory.  Instead let
> > the driver allocate the memory.
>
> The Sparc people won't like the driver doing allocations itself, neither
> would I when considering the various other MIPS DMA implementations.
>
> If you only want to separate the allocaton of memory from the
> pci_alloc_consistent() but still do the actual allocations in the layer of
> pci_*(), no problem with that.  We just want to keep the actual allocation
> outside of the drivers.  Look at the drivers that have been hacked to
> work on MIPS machines and you'll see why ...
>

So the idea is that pci_alloc_consistent() is for quick and dirty
use and pci_map_* are for more advanced use?  Presumably the driver
has done the memory allocation for pci_map_* right?  If that's the
case, I have no problem with it, just a different philosophy on
interfaces than what I'm used to.

> The interface tries to hide issues like cache coherency outside the driver.
> These matter when allocating matter just like obfuscating things like cache
> line size etc., from which pool DMA memory gets allocated etc.  We don't
> want driver writers to deal with these; most of them don't have the
> slightest clue of what these terms mean, believe me :-(
>
> As for flags, getting PCIIO_DMA_{CMD,DATA} would be useful as without hints
> like that we will not be able to use prefetching and write gathhering on the
> Origin.  Another flag that DaveM and Co. already seem to have agreed on are
> r/w flags which are needed for some hardware.

That's great news!  So they're going to add flags to the interface?  Can
we get a flag like PCIIO_DMA_A64 so we can distinguish between 32-bit
and 64-bit capable cards?  Also is there any chance they would consider
splitting the pci_map_* interface into an "allocate_resources" and a
actual "map"?

- leo


-- 
Leo Dagum    SGI  Mountain View, CA 94043 (650-933-2179)

<Prev in Thread] Current Thread [Next in Thread>