On Thu, Jun 30, 2005 at 09:52:19AM +1000, Daniel Carosone wrote:
> On Wed, Jun 29, 2005 at 11:27:19AM +0200, Manuel Bouyer wrote:
> > > bus_dma doesn't work like this.  there aren't ways "proxy" part of
> > > it. 
> 
> That's what I get for only ever having looked at the consumers of the
> interface in various drivers.  Perhaps its a testament to a good
> interface that this wasn't apparent from there.  Sorry for the noise.
> 
> > > "bus shims" are not possible in a MI fashion with bus_dma(9) as-is.
> > 
> > And, for this specific problem, I don't think we want one. Because such
> > constraints can be solved by other ways than bouncing, e.g. if the
> > memory comes from bus_dmamem_alloc() (in which case we want to say to
> > bus_dmamem_alloc that we want memory below 1G, or with specific alignement),
> > or if the hardware has a IOMMU.
> > 
> > IHMO this can't be solved with an additionnal layer, but with an extention
> > to the bus_dma interface to let know the MD bus_dma implementation the
> > constraints of the device.
> 
> I don't think adding constraints is enough, because not all of the
> memory involved in DMA is allocated according to those constraints:
> data may come from mbufs or even user pages.
> 
> Which means that either:
> 
>  * each MD bus_dma implementation has to grow an internal bounce
>    capability that's invoked automatically under certain
>    constraint-matching failures, which means a complex interface (and
>    again runs into the issues mrg points out, which I had initially
>    misread as the entirety of his point).

The interface wouldn't be much more complex, we just need to add a range
of memory address to the already-existing alignement and boundary constraints.
Some bus_dma implementation already have bounce capability, so just use
this. For some other bus_dma implementation, bounce capability isn't
needed because the hardware offers other way to deal with this.
All bus_dma interfaces would need to be changed at once, but not all need
to deal with the new constraint at once. Just return an error if the
constraint can't be respected.

> 
>  * or all the surrounding code has to be adjusted to deal with new
>    error-reporting of those constraint-matching failures as part of
>    the interface change (even if it uses common convenience methods as
>    part of the response).

Errors from the bus_dma methods already have to be checked anyway.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--