Searched hist:4 (Results 51 - 75 of 17372) sorted by relevance
| /freebsd-10.2-release/sys/sparc64/include/ | ||
| H A D | iommureg.h | diff 185008 Sun Nov 16 20:10:09 MST 2008 marius - Allow the front-end to specify that iommu(4) should disable rerun of the streaming cache for silicon bug workarounds. - Announce the presence of a streaming cache on attach for informational purposes. - For performance reasons don't do unnecessary flushes of the streaming cache when coherent mappings are synced. - Fix some minor style issues. diff 171730 Sun Aug 05 11:56:44 MDT 2007 marius - Divorce the IOTSBs, which so far where handled via a global list instead of per IOMMU, so we no longer need to program all of them identically in systems having multiple IOMMUs. This continues the rototilling of the nexus(4) done about 5 months ago, which amongst others changed nexus(4) and the drivers for host-to-foo bridges to provide bus_get_dma_tag methods, allowing to handle DMA tags in a hierarchical way and to link them with devices. This still doesn't move the silicon bug workarounds for Sabre (and in the uncommitted schizo(4) for Tomatillo) bridges into special bus_dma_tag_create() and bus_dmamap_sync() methods though, as w/o fully newbus'ified bus_dma_tag_create() and bus_dma_tag_destroy() this still requires too much hackery, i.e. per-child parent DMA tags in the parent driver. - Let the host-to-foo drivers supply the maximum physical address of the IOMMU accompanying the bridges. Previously iommu(4) hard- coded an upper limit of 16GB, which actually only applies to the IOMMUs of the Hummingbird and Sabre bridges. The Psycho variants as well as the U2S in fact can can translate to up to 2TB, i.e. translate to 41-bit physical addresses. According to the recently available Tomatillo documentation these bridges even translate to 43-bit physical addresses and hints at the Schizo bridges doing 43 bits as well. This fixes the issue the FreeBSD 6.0 todo list item "Max RAM on sparc64" was refering to and pretty much obsoletes the lack of support for bounce buffers on sparc64. Thanks to Nathan Whitehorn for pointing me at the Tomatillo manual. Approved by: re (kensmith) diff 171730 Sun Aug 05 11:56:44 MDT 2007 marius - Divorce the IOTSBs, which so far where handled via a global list instead of per IOMMU, so we no longer need to program all of them identically in systems having multiple IOMMUs. This continues the rototilling of the nexus(4) done about 5 months ago, which amongst others changed nexus(4) and the drivers for host-to-foo bridges to provide bus_get_dma_tag methods, allowing to handle DMA tags in a hierarchical way and to link them with devices. This still doesn't move the silicon bug workarounds for Sabre (and in the uncommitted schizo(4) for Tomatillo) bridges into special bus_dma_tag_create() and bus_dmamap_sync() methods though, as w/o fully newbus'ified bus_dma_tag_create() and bus_dma_tag_destroy() this still requires too much hackery, i.e. per-child parent DMA tags in the parent driver. - Let the host-to-foo drivers supply the maximum physical address of the IOMMU accompanying the bridges. Previously iommu(4) hard- coded an upper limit of 16GB, which actually only applies to the IOMMUs of the Hummingbird and Sabre bridges. The Psycho variants as well as the U2S in fact can can translate to up to 2TB, i.e. translate to 41-bit physical addresses. According to the recently available Tomatillo documentation these bridges even translate to 43-bit physical addresses and hints at the Schizo bridges doing 43 bits as well. This fixes the issue the FreeBSD 6.0 todo list item "Max RAM on sparc64" was refering to and pretty much obsoletes the lack of support for bounce buffers on sparc64. Thanks to Nathan Whitehorn for pointing me at the Tomatillo manual. Approved by: re (kensmith) diff 171730 Sun Aug 05 11:56:44 MDT 2007 marius - Divorce the IOTSBs, which so far where handled via a global list instead of per IOMMU, so we no longer need to program all of them identically in systems having multiple IOMMUs. This continues the rototilling of the nexus(4) done about 5 months ago, which amongst others changed nexus(4) and the drivers for host-to-foo bridges to provide bus_get_dma_tag methods, allowing to handle DMA tags in a hierarchical way and to link them with devices. This still doesn't move the silicon bug workarounds for Sabre (and in the uncommitted schizo(4) for Tomatillo) bridges into special bus_dma_tag_create() and bus_dmamap_sync() methods though, as w/o fully newbus'ified bus_dma_tag_create() and bus_dma_tag_destroy() this still requires too much hackery, i.e. per-child parent DMA tags in the parent driver. - Let the host-to-foo drivers supply the maximum physical address of the IOMMU accompanying the bridges. Previously iommu(4) hard- coded an upper limit of 16GB, which actually only applies to the IOMMUs of the Hummingbird and Sabre bridges. The Psycho variants as well as the U2S in fact can can translate to up to 2TB, i.e. translate to 41-bit physical addresses. According to the recently available Tomatillo documentation these bridges even translate to 43-bit physical addresses and hints at the Schizo bridges doing 43 bits as well. This fixes the issue the FreeBSD 6.0 todo list item "Max RAM on sparc64" was refering to and pretty much obsoletes the lack of support for bounce buffers on sparc64. Thanks to Nathan Whitehorn for pointing me at the Tomatillo manual. Approved by: re (kensmith) diff 171730 Sun Aug 05 11:56:44 MDT 2007 marius - Divorce the IOTSBs, which so far where handled via a global list instead of per IOMMU, so we no longer need to program all of them identically in systems having multiple IOMMUs. This continues the rototilling of the nexus(4) done about 5 months ago, which amongst others changed nexus(4) and the drivers for host-to-foo bridges to provide bus_get_dma_tag methods, allowing to handle DMA tags in a hierarchical way and to link them with devices. This still doesn't move the silicon bug workarounds for Sabre (and in the uncommitted schizo(4) for Tomatillo) bridges into special bus_dma_tag_create() and bus_dmamap_sync() methods though, as w/o fully newbus'ified bus_dma_tag_create() and bus_dma_tag_destroy() this still requires too much hackery, i.e. per-child parent DMA tags in the parent driver. - Let the host-to-foo drivers supply the maximum physical address of the IOMMU accompanying the bridges. Previously iommu(4) hard- coded an upper limit of 16GB, which actually only applies to the IOMMUs of the Hummingbird and Sabre bridges. The Psycho variants as well as the U2S in fact can can translate to up to 2TB, i.e. translate to 41-bit physical addresses. According to the recently available Tomatillo documentation these bridges even translate to 43-bit physical addresses and hints at the Schizo bridges doing 43 bits as well. This fixes the issue the FreeBSD 6.0 todo list item "Max RAM on sparc64" was refering to and pretty much obsoletes the lack of support for bounce buffers on sparc64. Thanks to Nathan Whitehorn for pointing me at the Tomatillo manual. Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) |
| /freebsd-10.2-release/share/vt/fonts/ | ||
| H A D | vgarom-thin-8x16.hex | diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation 267400 Thu Jun 12 15:40:13 MDT 2014 emaste Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. 267400 Thu Jun 12 15:40:13 MDT 2014 emaste Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. |
| H A D | vgarom-thin-8x8.hex | diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation 267400 Thu Jun 12 15:40:13 MDT 2014 emaste Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. 267400 Thu Jun 12 15:40:13 MDT 2014 emaste Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. |
| H A D | Makefile | diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation |
| H A D | gallant.fnt.uu | diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation 266841 Thu May 29 14:55:59 MDT 2014 ray Add gallant vt(4) font as an example of font loading for vt(4). MFC after: 7 days Sponsored by: The FreeBSD Foundation 266841 Thu May 29 14:55:59 MDT 2014 ray Add gallant vt(4) font as an example of font loading for vt(4). MFC after: 7 days Sponsored by: The FreeBSD Foundation |
| H A D | vgarom-8x14.hex | diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation 267306 Mon Jun 09 21:08:52 MDT 2014 emaste Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. |
| H A D | vgarom-8x16.hex | diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation 267306 Mon Jun 09 21:08:52 MDT 2014 emaste Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. |
| H A D | vgarom-8x8.hex | diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation diff 271333 Tue Sep 09 20:37:00 MDT 2014 emaste MFC improved vt(4) font generation r266851: Add VGAROM 8x8, 8x14 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437 fonts. r267306: Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. r267400: Add thin versions of VGAROM 8x8 and 8x16 fonts for vt(4) These are converted from syscons(4) cp437-thin-8x* fonts. r267423: Build vt(4) fonts during buildworld vtfontcvt(8) is now built during buildworld, so can be used as a bootstrap tool to create vt(4) fonts from source .hex or .bdf font files, rather than having uuencoded binary fonts in the tree. r267578: Add glyphs from converted syscons iso* fonts This consists of the unique glyphs from the following font files in /usr/share/syscons/fonts: iso*.fnt ISO-8859-1 West European iso02*.fnt ISO-8859-2 Central European iso04*.fnt ISO-8859-4 Baltic iso05*.fnt ISO-8859-5 Cyrillic iso07*.fnt ISO-8859-7 Greek iso08*.fnt ISO-8859-8 Hebrew iso09*.fnt ISO-8859-9 Turkish iso15*.fnt ISO-8859-15 West European r268022: Rename the WITHOUT_VT_SUPPORT knob to WITHOUT_VT The _SUPPORT knobs have a consistent meaning which differs from the behaviour controlled by this knob. As the knob is opt-out and has not appeared in a release the impact should be low. Approved by: re Sponsored by: The FreeBSD Foundation 267306 Mon Jun 09 21:08:52 MDT 2014 emaste Add vgarom font source These are in 'GNU Unifont' format, and are converted from syscons(4) cp437 fonts. |
| /freebsd-10.2-release/sys/dev/vt/ | ||
| H A D | vt_consolectl.c | diff 271952 Mon Sep 22 10:22:44 MDT 2014 ray MFC 271381-271382,271385,271463-271466,271485,271506 o Add sysctls to enable/disable potentially dengerous key combinations, like reboot/halt/debug. o Add support for most key combinations supported by syscons(4). o Some spelling fixes o Remove stray whitespaces. o Switch vt(4) to traditional behaviour with copy-paste same as syscons(4) do. o Fix stray char on paste. o Fix 'function declaration isn't a prototype' warning. o vt(4): Enclose vt_mouse_paste() prototype inside #ifndef SC_NO_CUTPASTE/#endif Approved by: re (gjb) Sponsored by: The FreeBSD Foundation diff 271952 Mon Sep 22 10:22:44 MDT 2014 ray MFC 271381-271382,271385,271463-271466,271485,271506 o Add sysctls to enable/disable potentially dengerous key combinations, like reboot/halt/debug. o Add support for most key combinations supported by syscons(4). o Some spelling fixes o Remove stray whitespaces. o Switch vt(4) to traditional behaviour with copy-paste same as syscons(4) do. o Fix stray char on paste. o Fix 'function declaration isn't a prototype' warning. o vt(4): Enclose vt_mouse_paste() prototype inside #ifndef SC_NO_CUTPASTE/#endif Approved by: re (gjb) Sponsored by: The FreeBSD Foundation diff 271952 Mon Sep 22 10:22:44 MDT 2014 ray MFC 271381-271382,271385,271463-271466,271485,271506 o Add sysctls to enable/disable potentially dengerous key combinations, like reboot/halt/debug. o Add support for most key combinations supported by syscons(4). o Some spelling fixes o Remove stray whitespaces. o Switch vt(4) to traditional behaviour with copy-paste same as syscons(4) do. o Fix stray char on paste. o Fix 'function declaration isn't a prototype' warning. o vt(4): Enclose vt_mouse_paste() prototype inside #ifndef SC_NO_CUTPASTE/#endif Approved by: re (gjb) Sponsored by: The FreeBSD Foundation diff 271952 Mon Sep 22 10:22:44 MDT 2014 ray MFC 271381-271382,271385,271463-271466,271485,271506 o Add sysctls to enable/disable potentially dengerous key combinations, like reboot/halt/debug. o Add support for most key combinations supported by syscons(4). o Some spelling fixes o Remove stray whitespaces. o Switch vt(4) to traditional behaviour with copy-paste same as syscons(4) do. o Fix stray char on paste. o Fix 'function declaration isn't a prototype' warning. o vt(4): Enclose vt_mouse_paste() prototype inside #ifndef SC_NO_CUTPASTE/#endif Approved by: re (gjb) Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation diff 268366 Mon Jul 07 14:30:40 MDT 2014 ray 267622 Log: Rename vt(4) vga module to dismiss interference with syscons(4) vga module. 267623 Log: Remove stale link to deleted vt(4) xboxfb driver. 267624 Log: syscons(4) and vt(4) can be built together now. 267625 Log: Allow to disable syscons(4) if "hw.syscons.disable" kenv is set. 267626 Log: Suspend vt(4) initialization if "kern.vt.disable" kenv is set. 267965 by emaste@ Log: Use a common tunable to choose between vt(4)/sc(4) With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) 268175 by emaste@ Log: Fix vt(4) detection in kbdcontrol and vidcontrol As sc(4) and vt(4) coexist and are both enabled in GENERIC, the existence of a vt(4) sysctl is not sufficient to determine that vt(4) is in use. Reported by: Trond Endrestøl 268045 by emaste@ Log: Add vt(4) to GENERIC and retire the separate VT config vt(4) and sc(4) can now coexist in the same kernel. To choose the vt driver, set the loader tunable kern.vty=vt . Sponsored by: The FreeBSD Foundation |
| /freebsd-10.2-release/sys/sparc64/sparc64/ | ||
| H A D | sc_machdep.c | diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) |
| /freebsd-10.2-release/sys/dev/fxp/ | ||
| H A D | inphyreg.h | diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. |
| /freebsd-10.2-release/sys/dev/usb/net/ | ||
| H A D | ruephyreg.h | diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. |
| /freebsd-10.2-release/sys/pci/ | ||
| H A D | nfsmb.c | diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. |
| /freebsd-10.2-release/sys/modules/usb/rue/ | ||
| H A D | Makefile | diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. diff 226154 Sat Oct 08 12:39:16 MDT 2011 marius - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. |
| /freebsd-10.2-release/share/man/man4/ | ||
| H A D | nvd.4 | diff 265575 Wed May 07 17:25:05 MDT 2014 jimharris MFC r263303: Update nvme(4) and nvd(4) man pages to clarify the differences between their respective device nodes. diff 265575 Wed May 07 17:25:05 MDT 2014 jimharris MFC r263303: Update nvme(4) and nvd(4) man pages to clarify the differences between their respective device nodes. diff 253178 Thu Jul 11 02:12:30 MDT 2013 jimharris Bump date for nvme(4) and nvd(4). MFC after: 3 days diff 253178 Thu Jul 11 02:12:30 MDT 2013 jimharris Bump date for nvme(4) and nvd(4). MFC after: 3 days diff 253111 Tue Jul 09 21:30:53 MDT 2013 jimharris Update nvme(4) and nvd(4) to reflect recent work and upcoming inclusion in 9.2 release. Sponsored by: Intel MFC after: 3 days diff 253111 Tue Jul 09 21:30:53 MDT 2013 jimharris Update nvme(4) and nvd(4) to reflect recent work and upcoming inclusion in 9.2 release. Sponsored by: Intel MFC after: 3 days 241431 Wed Oct 10 21:38:49 MDT 2012 jimharris Add man pages for nvme(4) and nvd(4). Sponsored by: Intel Reviewed by: joel 241431 Wed Oct 10 21:38:49 MDT 2012 jimharris Add man pages for nvme(4) and nvd(4). Sponsored by: Intel Reviewed by: joel |
| H A D | nvme.4 | diff 265575 Wed May 07 17:25:05 MDT 2014 jimharris MFC r263303: Update nvme(4) and nvd(4) man pages to clarify the differences between their respective device nodes. diff 265575 Wed May 07 17:25:05 MDT 2014 jimharris MFC r263303: Update nvme(4) and nvd(4) man pages to clarify the differences between their respective device nodes. diff 253178 Thu Jul 11 02:12:30 MDT 2013 jimharris Bump date for nvme(4) and nvd(4). MFC after: 3 days diff 253178 Thu Jul 11 02:12:30 MDT 2013 jimharris Bump date for nvme(4) and nvd(4). MFC after: 3 days diff 253111 Tue Jul 09 21:30:53 MDT 2013 jimharris Update nvme(4) and nvd(4) to reflect recent work and upcoming inclusion in 9.2 release. Sponsored by: Intel MFC after: 3 days diff 253111 Tue Jul 09 21:30:53 MDT 2013 jimharris Update nvme(4) and nvd(4) to reflect recent work and upcoming inclusion in 9.2 release. Sponsored by: Intel MFC after: 3 days 241431 Wed Oct 10 21:38:49 MDT 2012 jimharris Add man pages for nvme(4) and nvd(4). Sponsored by: Intel Reviewed by: joel 241431 Wed Oct 10 21:38:49 MDT 2012 jimharris Add man pages for nvme(4) and nvd(4). Sponsored by: Intel Reviewed by: joel |
| H A D | me.4 | diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC |
| H A D | scc.4 | 157299 Thu Mar 30 18:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 18:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 18:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 18:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 18:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. |
| H A D | ixgb.4 | diff 217973 Thu Jan 27 20:08:04 MST 2011 yongari Backout r216577. ixgb(4) does not support altq(4) yet. diff 217973 Thu Jan 27 20:08:04 MST 2011 yongari Backout r216577. ixgb(4) does not support altq(4) yet. diff 216577 Mon Dec 20 00:08:02 MST 2010 yongari Add .Xr to altq(4). diff 161433 Fri Aug 18 10:22:36 MDT 2006 brueffer Use our standard section 4 SYNOPSIS layout. MFC after: 2 weeks diff 138068 Wed Nov 24 19:06:43 MST 2004 brueffer Xref polling.4 and bump .Dd MFC after: 3 days diff 138062 Wed Nov 24 18:45:46 MST 2004 brueffer Note that 4.11 will be the first 4.x based release to include this driver. Discussed with: ru diff 137929 Sat Nov 20 03:10:35 MST 2004 brueffer The ixgb(4) driver actually first appeared in 5.3 (was merged to RELENG_4 after 4.10). MFC after: 3 days diff 137408 Mon Nov 08 20:05:51 MST 2004 brueffer gx(4) is gone, reference em(4) instead diff 137408 Mon Nov 08 20:05:51 MST 2004 brueffer gx(4) is gone, reference em(4) instead 129795 Fri May 28 00:27:31 MDT 2004 tackerman Adding ixgb(4) for Intel 10GbE Adapters |
| H A D | le.4 | diff 166346 Tue Jan 30 08:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 166346 Tue Jan 30 08:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 162005 Mon Sep 04 16:45:08 MDT 2006 marius - Talk about chips rather than chip sets as AMD LANCE and PCnet are single-chip. - Add some more rationale about le(4). - Add/un-comment hardware notes for C-Bus and ISA adapters. diff 155220 Thu Feb 02 14:57:00 MST 2006 marius Correct and improve the description of le(4) vs. pcn(4); apparently I was thinking from the pcn(4) perspective instead of the le(4) one when writing the former version as le(4) supports a superset of the chips supported by pcn(4) and not the other way round. diff 155220 Thu Feb 02 14:57:00 MST 2006 marius Correct and improve the description of le(4) vs. pcn(4); apparently I was thinking from the pcn(4) perspective instead of the le(4) one when writing the former version as le(4) supports a superset of the chips supported by pcn(4) and not the other way round. diff 155220 Thu Feb 02 14:57:00 MST 2006 marius Correct and improve the description of le(4) vs. pcn(4); apparently I was thinking from the pcn(4) perspective instead of the le(4) one when writing the former version as le(4) supports a superset of the chips supported by pcn(4) and not the other way round. diff 155220 Thu Feb 02 14:57:00 MST 2006 marius Correct and improve the description of le(4) vs. pcn(4); apparently I was thinking from the pcn(4) perspective instead of the le(4) one when writing the former version as le(4) supports a superset of the chips supported by pcn(4) and not the other way round. diff 155220 Thu Feb 02 14:57:00 MST 2006 marius Correct and improve the description of le(4) vs. pcn(4); apparently I was thinking from the pcn(4) perspective instead of the le(4) one when writing the former version as le(4) supports a superset of the chips supported by pcn(4) and not the other way round. diff 155220 Thu Feb 02 14:57:00 MST 2006 marius Correct and improve the description of le(4) vs. pcn(4); apparently I was thinking from the pcn(4) perspective instead of the le(4) one when writing the former version as le(4) supports a superset of the chips supported by pcn(4) and not the other way round. 155153 Tue Jan 31 22:40:25 MST 2006 marius Add a man page for le(4), based on the NetBSD one. |
| /freebsd-10.2-release/sys/modules/if_me/ | ||
| H A D | Makefile | diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC 274246 Fri Nov 07 19:22:09 MST 2014 ae Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 Differential Revision: D1023 No objections from: net@ Relnotes: yes Sponsored by: Yandex LLC |
| /freebsd-10.2-release/share/vt/ | ||
| H A D | Makefile | diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation diff 267541 Mon Jun 16 12:44:36 MDT 2014 ray MFC: 266838 266841 267194 Add gallant vt(4) font as an example of font loading for vt(4). Add Ukranian vt(4) keymaps as an example. Sponsored by: The FreeBSD Foundation 266838 Thu May 29 13:57:38 MDT 2014 ray Add gallant vt(4) font as an example of font loading for vt(4). MFC after: 7 days Sponsored by: The FreeBSD Foundation 266838 Thu May 29 13:57:38 MDT 2014 ray Add gallant vt(4) font as an example of font loading for vt(4). MFC after: 7 days Sponsored by: The FreeBSD Foundation |
| /freebsd-10.2-release/sys/i386/include/ | ||
| H A D | nexusvar.h | 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ |
| /freebsd-10.2-release/share/man/man9/ | ||
| H A D | hhook.9 | 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months 218912 Mon Feb 21 12:06:40 MST 2011 lstewart Final commit to round out the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. - Add new man pages for the modular congestion control, Khelp and Hhook frameworks (cc.4, cc.9, khelp.9 and hhook.9). - Add new man pages for each available congestion control algorithm (cc_chd.4, cc_cubic.4, cc_hd.4, cc_htcp.4, cc_newreno.4 and cc_vegas.4). - Add a new man page for the Enhanced Round Trip Time (ERTT) Khelp module (h_ertt.4). - Update the TCP (tcp.4) man page to mention the TCP_CONGESTION socket option, cross reference to cc.4 and remove references to the retired "net.inet.tcp.newreno" sysctl MIB variable. In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation MFC after: 3 months |
| /freebsd-10.2-release/sys/amd64/include/ | ||
| H A D | nexusvar.h | 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ 177157 Thu Mar 13 20:39:04 MDT 2008 jhb Rework how the nexus(4) device works on x86 to better handle the idea of different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@ |
Completed in 950 milliseconds