Searched hist:163805 (Results 1 - 4 of 4) sorted by relevance
/freebsd-9.3-release/sys/dev/pci/ | ||
H A D | pci_pci.c | diff 163805 Mon Oct 30 17:18:46 MST 2006 imp More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses. |
H A D | pci_subr.c | diff 163805 Mon Oct 30 17:18:46 MST 2006 imp More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses. |
H A D | pcivar.h | diff 163805 Mon Oct 30 17:18:46 MST 2006 imp More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses. |
H A D | pci.c | diff 163805 Mon Oct 30 17:18:46 MST 2006 imp More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses. |
Completed in 141 milliseconds