FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F5.2.0_cvs 2004-01-10T05:53:29Z 2004-01-10T05:53:29Z cvs2svn cvs2svn@FreeBSD.org 2004-01-10T05:53:29Z urn:sha1:58c9ff44c8041f394c663cb9640e9b77fe07bb13 'RELENG_5_2_0_RELEASE'. This commit was manufactured to restore the state of the 5.2-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs. 2003-12-07T03:02:28Z cvs2svn cvs2svn@FreeBSD.org 2003-12-07T03:02:28Z urn:sha1:a348451bd8bd6d66bcb5b23f2aaec00e74c1292f 2003-09-16T14:21:17Z Bruce Evans bde@FreeBSD.org 2003-09-16T14:21:17Z urn:sha1:efcfe9517307f1fc78290ad1185e217ff676784c and some of their bits (i.e., fifo trigger levels, frequency multipliers and divisors, and bits to select the registers for these). This attempts to completely describe the 16950's complicated register selects for 16950-specific registers only. 2003-09-16T14:08:54Z Bruce Evans bde@FreeBSD.org 2003-09-16T14:08:54Z urn:sha1:fec27f507c19d3c2f6dd6a545faabf74fcfc4a15 completes defining the 16650 register numbers but not all of their bits. 2003-09-16T13:52:01Z Bruce Evans bde@FreeBSD.org 2003-09-16T13:52:01Z urn:sha1:2b843bc94b0e2b7e53f032861ae55ee2a88dbaad the description of the data latch registers (they were described as readonly). Added some better and worse aliases for standard registers, mostly taken from the 16950 data sheet. Define deprecated aliases in terms of the preferred one. Don't define com_efr in terms of com_fifo. It is unrelated (in a different bank). 2003-09-16T11:54:29Z Bruce Evans bde@FreeBSD.org 2003-09-16T11:54:29Z urn:sha1:74814b322ab9fb83584a8f2a15635f99036dde1a Merged comments to match (put them at the right of the #defines instead of duplicating them). Sorted the resulting sections on UART type and register bank. Added a comment for each bank. 2003-09-16T08:08:08Z Bruce Evans bde@FreeBSD.org 2003-09-16T08:08:08Z urn:sha1:86fe87393a0d4192ba6070f980da79dc29f2dee9 to ns16550.h. The organization of these files was sort of backwards. The bits in the registers have no driver or bus dependencies but they but the offsets of the registers in bus space are very bus-dependent. However, it does no harm to keep the definitions of the register offsets in ns16550.h provided they are thought of as internal ns*50 offsets. 2003-09-06T23:13:47Z Marcel Moolenaar marcel@FreeBSD.org 2003-09-06T23:13:47Z urn:sha1:27d5dc189c8e2eaf1cbe7e47078bf065854ba210 It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 2003-03-28T06:27:08Z Matthew N. Dodd mdodd@FreeBSD.org 2003-03-28T06:27:08Z urn:sha1:0e91b7d532045763d4714b4c668ccad88fc07ae0 - Be consistent about what we call our softc. - Minor formatting. - Add some register definitions gleaned from NetBSD/Linux. 2002-09-22T08:51:31Z Poul-Henning Kamp phk@FreeBSD.org 2002-09-22T08:51:31Z urn:sha1:c8423e97021edebb1954be8a54bca4bf02e7e7a1 Approved by: bde