Date: Wed, 26 Apr 2006 10:47:08 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: scottl@samsco.org Cc: src-committers@FreeBSD.org, bde@zeta.org.au, jhb@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, mj@feral.com Subject: Re: cvs commit: src/sys/dev/bce if_bcereg.h Message-ID: <20060426.104708.85411757.imp@bsdimp.com> In-Reply-To: <20060426.102502.11595340.imp@bsdimp.com> References: <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com> <20060426.102502.11595340.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20060426.102502.11595340.imp@bsdimp.com>
"M. Warner Losh" <imp@bsdimp.com> writes:
: While an individual DMA transfer on the
: PCI-E bus may not cross such a boundary, I bleieve that individual
: resources can consume more than 4G. Our PCI code doesn't handle BARs
: that are > 4G in size correctly, but it does handle BARs that are
: mapped anywhere in a 64-bit address space.
I went ahead and looked it up in the standard. Our current PCI code
does sizing of 64-bit BARs with only 32-bits. But the 2.2 standard
specifically says, in an implementation note, that it should be done
with 64-bits. On page 204 in section 6.2.5.1:
"64-bit (memory) Base Address registers can be handled the
same, except that the second 32-bit register is considered an
extension of the first; ie bits 32-63. Software writes
0xffffffff to both registers, reads them back, and combines
the result into a 64-bit value. Size calculation is done on
the 64-bit value."
Anyway, consider this just a footnote to the conversation. I'm happy
leaving well enough alone for the i386 implementation given the
sentiment expressed in this thread.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060426.104708.85411757.imp>