Date: Wed, 16 Feb 2005 12:23:11 +1030 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: freebsd-hackers@freebsd.org Cc: gallatin@cs.duke.edu Subject: Re: mapping small parts of a pci card to conserve KVA Message-ID: <200502161223.13075.doconnor@gsoft.com.au> In-Reply-To: <20050215.135343.104086484.imp@bsdimp.com> References: <16914.22016.593790.719399@grasshopper.cs.duke.edu> <20050215.135343.104086484.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1181563.LWCu8OVLV4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 16 Feb 2005 07:23, Warner Losh wrote: > > At least on 5.3R, I seem to get back the same struct resource * from > > each call. rman_get_virtual() returns a different kva for each > > mapping, yet they all seem to map to the same physical address. > > Eg, I call vtophys() on the results of rman_get_virtual(), > > for each segment, and they all map to 0xf9000000. > > > > Is there a way to just map what I need? > > There's no way to map part of a resource currently. I'd like to > create an API to do that, since it would be useful for a lot of > things, but none exists today. As soon as bus_activate_resource is > called, it gets mapped. You could do something like puc does and attach a child driver to part of i= t=20 right? (Stab in dark :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1181563.LWCu8OVLV4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCEqeI5ZPcIHs/zowRAustAJ0VO1TpxQFZpgLsYfxC3fqZflM/CACgjybQ oxt3L7/deob4c5QDAuM+wCs= =fJao -----END PGP SIGNATURE----- --nextPart1181563.LWCu8OVLV4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502161223.13075.doconnor>