Subject: Re: FreeBSD Bus DMA (was Re: AdvanSys board support)
To: None <tech-kern@NetBSD.ORG>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-kern
Date: 06/11/1998 22:12:12
[ BTW, I'm trimming the CC list from now on; I know I'm tired of the
duplicate messages, and I'm sure others are, too. ]
On Thu, 11 Jun 1998 20:03:25 -0700 (PDT)
"Dr. Bill Studenmund" <wrstuden@loki.stanford.edu> wrote:
> If so, would a sutable compromise be to make dm_segs be private to the
> implimentation, and bus_dma_segment_t *dm_segs[1]. For implimentations
> where the state represented by dma segments is more "expensive" than the
> memory they occupy, dm_segs points to a long-lived table of dma segments,
> which is handed to the call-back routine. For implimentations where the
> memory is more "expensive," the segment table is created on the fly?
For the record, that is already allowed in the NetBSD interface. To
quote the manual page:
The dm_segs member may be an array of segments or a pointer to an
array of segments. The dm_nsegs member indicates the number of
segments in dm_segs.
It was specifically worded to allow the underlying implementation to
allocate them on the fly if it desires. The client merely needs to
make sure that it pays attention to dm_nsegs. It doesn't matter to
the client since an array and a pointer to an array are accessed
the same way (i.e. foo[7]).
In other words, if it's _REALLY_ that important, it is possible to allocate
these things at load time, and free them at unload time (I really want
them to be accessible from the bus_dmamap_t, though, for devices where
this is important, and interface consistency when it's not).
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-5 Work: +1 650 604 0935
Moffett Field, CA 94035 Pager: +1 650 428 6939