> > Main change is the introduction of a 'sizes' array to hold the size
> > for each 'mappings' entry. The result will be an array of (phys addr, size)
> > pairs. This is a more general representation for scattered DMA segments.
>
> (2) as the interface was specified, the sizes of the elements were
> implicitly defined. the DMA map function, and friends, mapped
> from VA -> ISA bus PA, with the assumptions that:
> (1) the virtual addresses were contiguous, and that,
Right, this assumption has not changed.
> (2) there is some correspondence between system physical
> pages (or virtual pages) and ISA bus 'pages.'
Yes, this is assumed to be a one-by-one mapping of pages.
> in other words:
> (1) the interface was _NOT_ meant to do sub-page-size
> scatter-gather DMA; as far as i can tell, that's not
> possible on any ISA implementation i've seen. (though
> the Alpha, for instance, _does_ allow one to do
> scatter-gather DMA with 8k (system page size) granularity.
And here it comes. I did the implementation for an Adaptec 1542C (aha1542.c).
Like many other BUSMASTER DMA controllers this device would be able to do
byte-size scatter-gather DMA. The main reason for the 'sizes' is a more
general interface and simpler usage because there is no need to collect
the 'mappings' returned from 'isadma_map' into individual segments for
scatter-gather DMA.
Throughout the whole kernel scatter-gather is done on (addr,size) pairs.
> If a given piece of hardware can do scatter-gather
> DMA, then one should call the map/copy/unmap functions
> multiple times (at the appropriate times!), once each
> for each 'piece' of the scatter-gather DMA.
Sorry, this is impossible for BUSMASTER DMA. There is no notifaction when
one segment is done. There will be a notification when ALL scatter-gather
segments have ben transferred.
> (2) system pages will not be 'intertwined' on the ISA bus.
>
>
>
> cgd
>
--
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (W Germany)