--whQ8ahty1/0D0Zf+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 27, 2005 at 08:55:28AM +1000, matthew green wrote:
>=20
>    I'm suggesting that we should create logical "bus" drivers to attach
>    these devices to.  They wouldn't actually _do_ anything but act as
>    a shim to set up bus_dma the right way; but they should be sufficient
>    for that, no?
>=20
>=20
> but how?  bus_dma is defined in <machine/bus.h> and afaik there is
> no way to do what you are suggesting (without changing bus_dma.)

I think Thor has in mind something like this (certainly, I do)

pci0 at mainbus0
bouncepci0 at pci0
bouncepci0: using bounce buffers for transfers above 1Gb
bce0 at bouncepci0

bouncepci is a (MD?) bus, which provides implementations of the normal
bus_dma interface that include internal bounce buffers.

Maybe it can be a generic MI bouncebus, and even parent/child bus
independent, if enough of the bus_dma ops are sufficiently transparent
to pass-through.  Otherwise it might need to know more about the
internals of the real bus implementation it is proxying for; only then
might it be necessary to consider changes to the bus_dma interface.

Setting the parameters of what constraints and sizes require bouncing
doesn't have to be part of bus_dma itself, it's part of bouncebus, and
might even simply be something that's done at config time - otherwise
it's part of the if_bce_bounce attachment, which can use
bouncebus-specific routines..

--
Dan.

--whQ8ahty1/0D0Zf+
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCwebxEAVxvV4N66cRAuZpAJ96Ist8jrbnzqhbeoacCikilsI4QQCg3N/a
GOSql0wJWBTPiFuXu7LVtKg=
=qQue
-----END PGP SIGNATURE-----

--whQ8ahty1/0D0Zf+--