On Wed, Jun 29, 2005 at 03:38:15PM +1000, matthew green wrote:
>    
>    Ideally, no.  As I went on to say, ideally there would be a generic
>    bouncebus psuedo-driver implemented as a shim, purely in terms of the
>    bus_dma interface and simply proxying most of the routines and calls
>    straight through.  I'm not sure if we can presently meet that ideal,
>    though, so I started with the more-specific example.
> 
> 
> bus_dma doesn't work like this.  there aren't ways "proxy" part of
> it.  the tags are setup and how functions work is entirely under
> the control of <machine/bus.h>.  there may not be functions at all,
> they might be macros.  the only way to handle bouncing currently is
> in the MD backend.
> 
> 
> "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.

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