FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F6.2.0_cvs 2007-01-11T22:54:46Z 2007-01-11T22:54:46Z cvs2svn cvs2svn@FreeBSD.org 2007-01-11T22:54:46Z urn:sha1:201f78d6b90635d961fa373ecd706e3786333b7e 'RELENG_6_2_0_RELEASE'. This commit was manufactured to restore the state of the 6.2-RELEASE image. 2005-06-16T18:06:38Z Marcel Moolenaar marcel@FreeBSD.org 2005-06-16T18:06:38Z urn:sha1:d382695820c8c01eb3cdc914f946d6b957c1ebce not only means that it's possible (though unlikely) that we hand out differing tags for the same bus space, it also means that the tags we handed out are not used during bus enumeration. Both affect our ability to compare tags. Fix the first by initializing our tags only once. Fix the second by testing if one of the tags to compare is our tag and the other is a busspace_isa_{io|mem} tag and declare them equal if so. This fixes using uart(4) as the serial console on a ds10. That is, the low-level console worked, but we could not match the resources to one of the UARTs found during bus enumeration, which prevented uart(4) from becoming the console in single- or multi-user mode. Approved by: re (kensmith) MFC after: 2 days Thanks to: all involved in getting a ds10 to me; directly or indirectly. Special thanks to: Dave Knight, ISC (for not scratching my Porsche :-) 2005-01-06T01:43:34Z Warner Losh imp@FreeBSD.org 2005-01-06T01:43:34Z urn:sha1:098ca2bda93c701c5331d4e6aace072495b4caaa 2004-11-17T20:01:43Z Marius Strobl marius@FreeBSD.org 2004-11-17T20:01:43Z urn:sha1:37f37506de8f6eb65759e8604c38465185eadae4 used on sparc64 they are only stubs on all architectures and it doesn't look like if we would need it in the near future again. Ok'ed by: marcel 2004-08-14T23:54:27Z Marius Strobl marius@FreeBSD.org 2004-08-14T23:54:27Z urn:sha1:efa79eb77e9583863d9f6e8c0c935ae90ca1c2b1 and that can be used as an identify function for all kinds of busses on a certain platform. Expect for sparc64 these are only stubs right now. [1] - For sparc64, add code to its uart_cpu_identify() for registering the on- board ISA UARTs and their resources based on information obtained from Open Firmware. It would be better if this would be done in the OFW ISA code. However, due to the common FreeBSD ISA code and PNP-IDs not always being present in the properties of the ISA nodes there seems to be no good way to implement that. Therefore special casing UARTs as the sole really relevant ISA devices on sparc64 seemed reasonable. [2] Approved by: marcel Discussed with: marcel [1], tmm [2] Tested by: make universe 2004-03-20T02:14:02Z Marcel Moolenaar marcel@FreeBSD.org 2004-03-20T02:14:02Z urn:sha1:2ae4f1fd16329a591fad7e1da5a2fe0ac8769db5 to select a serial console and debug port (resp). On ia64 these replace the use of hints completely and take precedence over hints on alpha, amd64 and i386. On sparc64 these variables are not yet recognised. The reasons for introducing these variables are: 1. Hints have side-effects. They reserve the unit number for use by isa or acpi devices and therefore cannot be used to select a pci device. Also, the use of a unit number to select a device prior to bus enumeration is nonsense. The new variables have no side- effects and are not based on unit numbers. 2. Hints don't have the expression power to allow the sysadmin to select UARTs that are not legacy PC devices and need the support of compile-time constants to give the sysadmin some level of flexibility. The hw.uart.console and hw.uart.dbgport variables specify a list of attributes. An attribute is a tag-value pair, seperated by a colon. Attributes are seperated by a comma. Where possible, tags are the same as those in /etc/remote (only br and pa in practice). Details can be found in the manpage (not part of this commit). Not tested on: amd64, pc98 2003-09-26T05:14:56Z Marcel Moolenaar marcel@FreeBSD.org 2003-09-26T05:14:56Z urn:sha1:875f70dba4ac5331af98ce31da9e3f02bdf2af21 and the Z8530 drivers used the I/O address as a quick and dirty way to determine which channel they operated on, but formalizing this by introducing iobase is not a solution. How for example would a driver know which channel it controls for a multi-channel UART that only has a single I/O range? Instead, add an explicit field, called chan, to struct uart_bas that holds the channel within a device, or 0 otherwise. The chan field is initialized both by the system device probing (i.e. a system console) or it is passed down to uart_bus_probe() by any of the bus front-ends. As such, it impacts all platforms and bus drivers and makes it a rather large commit. Remove the use of iobase in uart_cpu_eqres() for pc98. It is expected that platforms have the capability to compare tag and handle pairs for equality; as to determine whether two pairs access the same device or not. The use of iobase for pc98 makes it impossible to formalize this and turn it into a real newbus function later. This commit reverts uart_cpu_eqres() for pc98 to an unimplemented function. It has to be reimplemented using only the tag and handle fields in struct uart_bas. Rewrite the SAB82532 and Z8530 drivers to use the chan field in struct uart_bas. Remove the IS_CHANNEL_A and IS_CHANNEL_B macros. We don't need to abstract anything anymore. Discussed with: nyan Tested on: i386, ia64, sparc64 2003-09-23T13:03:22Z Yoshihiro Takahashi nyan@FreeBSD.org 2003-09-23T13:03:22Z urn:sha1:312ebe0323fc59785bbb68fd4b7366eacc5cc7ed 2003-09-23T09:25:38Z Yoshihiro Takahashi nyan@FreeBSD.org 2003-09-23T09:25:38Z urn:sha1:c423dba33446cdad2bea753403c9520ceb9ac488 - Remove buggy uart_cpu_busaddr() function. 2003-09-23T08:38:49Z Yoshihiro Takahashi nyan@FreeBSD.org 2003-09-23T08:38:49Z urn:sha1:81a11def25e5cb23c9f4672a866d0b2720effe65