--NEyDxzWoNuWHH9Kb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.=20

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.
>=20
> 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 alignemen=
t),
> or if the hardware has a IOMMU.
>=20
> 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).

 * 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).

There are things to dislike strongly in either of these proposals,
though I suspect both are preferable to special-case implementations
in each MI driver, especially as the constraints and responses are
MD..

--
Dan.
--NEyDxzWoNuWHH9Kb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFCwzQzEAVxvV4N66cRAvgbAKDFxMuvX+6yS9OFMPofklV1zcoUuQCg5qPV
TkJ3TfI1xh+PyKN2+IlSD1c=
=Dqlr
-----END PGP SIGNATURE-----

--NEyDxzWoNuWHH9Kb--