d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
76eaf53752
freebsd-nq/sys/dev/uart/uart_dev_z8530.c

624 lines
14 KiB
C
Raw Normal View History

Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +00:00
/*-
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
* Copyright (c) 2003 Marcel Moolenaar
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/bus.h>
#include <sys/conf.h>
#include <machine/bus.h>
#include <dev/uart/uart.h>
#include <dev/uart/uart_cpu.h>
#include <dev/uart/uart_bus.h>
Include the header with the register definitions from sys/dev/ic. They are shared now.
2004-11-21 01:43:27 +00:00
#include <dev/ic/z8530.h>
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
#include "uart_if.h"
#define DEFAULT_RCLK 307200
On PowerPC the clock for the BRG comes from RTxC, not PCLK. Add a quick hack to deal with this. We may need to formalize this better and have this information come from the bus attachments.
2006-07-26 17:29:37 +00:00
/* Hack! */
#ifdef __powerpc__
#define UART_PCLK 0
#else
#define UART_PCLK MCB2_PCLK
#endif
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
/* Multiplexed I/O. */
static __inline void
uart_setmreg(struct uart_bas *bas, int reg, int val)
{
uart_setreg(bas, REG_CTRL, reg);
uart_barrier(bas);
uart_setreg(bas, REG_CTRL, val);
}
static __inline uint8_t
uart_getmreg(struct uart_bas *bas, int reg)
{
uart_setreg(bas, REG_CTRL, reg);
uart_barrier(bas);
return (uart_getreg(bas, REG_CTRL));
}
static int
z8530_divisor(int rclk, int baudrate)
{
int act_baud, divisor, error;
if (baudrate == 0)
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
return (-1);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
divisor = (rclk + baudrate) / (baudrate << 1) - 2;
In z8530_divisor() return 0 if the calculated divisor is less than 0. This happens when the baudrate is too high for the given RCLK.
2006-04-04 01:16:16 +00:00
if (divisor < 0 || divisor >= 65536)
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
return (-1);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
act_baud = rclk / 2 / (divisor + 2);
/* 10 times error in percent: */
error = ((act_baud - baudrate) * 2000 / baudrate + 1) >> 1;
/* 3.0% maximum error tolerance: */
if (error < -30 || error > 30)
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
return (-1);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (divisor);
}
static int
z8530_param(struct uart_bas *bas, int baudrate, int databits, int stopbits,
int parity, uint8_t *tpcp)
{
int divisor;
uint8_t mpm, rpc, tpc;
rpc = RPC_RXE;
mpm = MPM_CM16;
tpc = TPC_TXE | (*tpcp & (TPC_DTR | TPC_RTS));
if (databits >= 8) {
rpc |= RPC_RB8;
tpc |= TPC_TB8;
} else if (databits == 7) {
rpc |= RPC_RB7;
tpc |= TPC_TB7;
} else if (databits == 6) {
rpc |= RPC_RB6;
tpc |= TPC_TB6;
} else {
rpc |= RPC_RB5;
tpc |= TPC_TB5;
}
mpm |= (stopbits > 1) ? MPM_SB2 : MPM_SB1;
switch (parity) {
case UART_PARITY_EVEN: mpm |= MPM_PE | MPM_EVEN; break;
case UART_PARITY_NONE: break;
case UART_PARITY_ODD: mpm |= MPM_PE; break;
default: return (EINVAL);
}
if (baudrate > 0) {
divisor = z8530_divisor(bas->rclk, baudrate);
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
if (divisor == -1)
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (EINVAL);
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
} else
divisor = -1;
On PowerPC the clock for the BRG comes from RTxC, not PCLK. Add a quick hack to deal with this. We may need to formalize this better and have this information come from the bus attachments.
2006-07-26 17:29:37 +00:00
uart_setmreg(bas, WR_MCB2, UART_PCLK);
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
uart_barrier(bas);
if (divisor >= 0) {
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_setmreg(bas, WR_TCL, divisor & 0xff);
uart_barrier(bas);
uart_setmreg(bas, WR_TCH, (divisor >> 8) & 0xff);
uart_barrier(bas);
}
uart_setmreg(bas, WR_RPC, rpc);
uart_barrier(bas);
uart_setmreg(bas, WR_MPM, mpm);
uart_barrier(bas);
uart_setmreg(bas, WR_TPC, tpc);
uart_barrier(bas);
On PowerPC the clock for the BRG comes from RTxC, not PCLK. Add a quick hack to deal with this. We may need to formalize this better and have this information come from the bus attachments.
2006-07-26 17:29:37 +00:00
uart_setmreg(bas, WR_MCB2, UART_PCLK | MCB2_BRGE);
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
uart_barrier(bas);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
*tpcp = tpc;
return (0);
}
static int
z8530_setup(struct uart_bas *bas, int baudrate, int databits, int stopbits,
int parity)
{
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uint8_t tpc;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
if (bas->rclk == 0)
bas->rclk = DEFAULT_RCLK;
/* Assume we don't need to perform a full hardware reset. */
Revert the introduction of iobase in struct uart_bas. Both the SAB82532 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-26 05:14:56 +00:00
switch (bas->chan) {
case 1:
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uart_setmreg(bas, WR_MIC, MIC_NV | MIC_CRA);
Revert the introduction of iobase in struct uart_bas. Both the SAB82532 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-26 05:14:56 +00:00
break;
case 2:
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uart_setmreg(bas, WR_MIC, MIC_NV | MIC_CRB);
Revert the introduction of iobase in struct uart_bas. Both the SAB82532 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-26 05:14:56 +00:00
break;
}
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_barrier(bas);
o A divisor of 0 is perfectly valid. Reserve -1 for an invalid divisor. This allows us to set the line speed to the maximum of 1/4 of the device clock. o Disable the baudrate generator before programming the line settings, including baudrate, and enable it afterwards.
2006-05-12 23:24:45 +00:00
/* Set clock sources. */
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_setmreg(bas, WR_CMC, CMC_RC_BRG | CMC_TC_BRG);
On PowerPC the clock for the BRG comes from RTxC, not PCLK. Add a quick hack to deal with this. We may need to formalize this better and have this information come from the bus attachments.
2006-07-26 17:29:37 +00:00
uart_setmreg(bas, WR_MCB2, UART_PCLK);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_barrier(bas);
/* Set data encoding. */
uart_setmreg(bas, WR_MCB1, MCB1_NRZ);
uart_barrier(bas);
tpc = TPC_DTR | TPC_RTS;
z8530_param(bas, baudrate, databits, stopbits, parity, &tpc);
return (int)tpc;
}
/*
* Low-level UART interface.
*/
static int z8530_probe(struct uart_bas *bas);
static void z8530_init(struct uart_bas *bas, int, int, int, int);
static void z8530_term(struct uart_bas *bas);
static void z8530_putc(struct uart_bas *bas, int);
- Add a uart_rxready() and corresponding device-specific implementations that can be used to check whether receive data is ready, i.e. whether the subsequent call of uart_poll() should return a char, and unlike uart_poll() doesn't actually receive data. - Remove the device-specific implementations of uart_poll() and implement uart_poll() in terms of uart_getc() and the newly added uart_rxready() in order to minimize code duplication. - In sunkbd(4) take advantage of uart_rxready() and use it to implement the polled mode part of sunkbd_check() so we don't need to buffer a potentially read char in the softc. - Fix some mis-indentation in sunkbd_read_char(). Discussed with: marcel
2007-01-18 22:01:19 +00:00
static int z8530_rxready(struct uart_bas *bas);
Don't hold the hardware mutex across getc(). It can wait indefinitely for a character to be received. Instead let getc() do any necesary locking.
2006-04-01 19:04:54 +00:00
static int z8530_getc(struct uart_bas *bas, struct mtx *);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
Don't expose the uart_ops structure directly, but instead have it obtained through the uart_class structure. This allows us to declare the uart_class structure as weak and as such allows us to reference it even when it's not compiled-in. It also allows is to get the uart_ops structure by name, which makes it possible to implement the dt tag handling in uart_getenv(). The side-effect of all this is that we're using the uart_class structure more consistently which means that we now also have access to the size of the bus space block needed by the hardware when we map the bus space, eliminating any hardcoding.
2007-04-02 22:00:22 +00:00
static struct uart_ops uart_z8530_ops = {
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
.probe = z8530_probe,
.init = z8530_init,
.term = z8530_term,
.putc = z8530_putc,
- Add a uart_rxready() and corresponding device-specific implementations that can be used to check whether receive data is ready, i.e. whether the subsequent call of uart_poll() should return a char, and unlike uart_poll() doesn't actually receive data. - Remove the device-specific implementations of uart_poll() and implement uart_poll() in terms of uart_getc() and the newly added uart_rxready() in order to minimize code duplication. - In sunkbd(4) take advantage of uart_rxready() and use it to implement the polled mode part of sunkbd_check() so we don't need to buffer a potentially read char in the softc. - Fix some mis-indentation in sunkbd_read_char(). Discussed with: marcel
2007-01-18 22:01:19 +00:00
.rxready = z8530_rxready,
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
.getc = z8530_getc,
};
static int
z8530_probe(struct uart_bas *bas)
{
return (0);
}
static void
z8530_init(struct uart_bas *bas, int baudrate, int databits, int stopbits,
int parity)
{
z8530_setup(bas, baudrate, databits, stopbits, parity);
}
static void
z8530_term(struct uart_bas *bas)
{
}
static void
z8530_putc(struct uart_bas *bas, int c)
{
Make the Z8530 more reliable as low-level console by making use of the fact that access to RR0 does not need a prior write to the register index because the index always reverts to 0 after the indexed register has been accessed. Typically when a RR or WR is to accessed, one programs the index (which is a write to the control register), followed by a read or write to the actual indexed register (a read pr write to the same control register). When this non-atomic sequence is interrupted after having written the index and low-level console I/O is done in that situation, the write to program the index will actually write to the indexed register and nuke state. This almost always yields a wedge. By not programming the index register and instead just reading from RR0, the worst case scenario is non-fatal. For if we don't actually read from RR0 but some other register we get an invalid status, which may lead us to conclude that the transit data register is empty when it's not or that the receive data register contains data when it doesn't. Hence, we may lose an output character or get a sporadic input character, but given the situation this is a non-issue. Full serialization is not possible due to the fact that this code needs to work from DDB and before mutex initialization has happened. In collaboration with: kris@, marius@ Tested by: kris@ MFC after: 1 day X-MFC: 5.4-RELEASE candidate
2005-04-27 21:57:51 +00:00
while (!(uart_getreg(bas, REG_CTRL) & BES_TXE))
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
;
uart_setreg(bas, REG_DATA, c);
uart_barrier(bas);
}
static int
- Add a uart_rxready() and corresponding device-specific implementations that can be used to check whether receive data is ready, i.e. whether the subsequent call of uart_poll() should return a char, and unlike uart_poll() doesn't actually receive data. - Remove the device-specific implementations of uart_poll() and implement uart_poll() in terms of uart_getc() and the newly added uart_rxready() in order to minimize code duplication. - In sunkbd(4) take advantage of uart_rxready() and use it to implement the polled mode part of sunkbd_check() so we don't need to buffer a potentially read char in the softc. - Fix some mis-indentation in sunkbd_read_char(). Discussed with: marcel
2007-01-18 22:01:19 +00:00
z8530_rxready(struct uart_bas *bas)
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
{
- Add a uart_rxready() and corresponding device-specific implementations that can be used to check whether receive data is ready, i.e. whether the subsequent call of uart_poll() should return a char, and unlike uart_poll() doesn't actually receive data. - Remove the device-specific implementations of uart_poll() and implement uart_poll() in terms of uart_getc() and the newly added uart_rxready() in order to minimize code duplication. - In sunkbd(4) take advantage of uart_rxready() and use it to implement the polled mode part of sunkbd_check() so we don't need to buffer a potentially read char in the softc. - Fix some mis-indentation in sunkbd_read_char(). Discussed with: marcel
2007-01-18 22:01:19 +00:00
return ((uart_getreg(bas, REG_CTRL) & BES_RXA) != 0 ? 1 : 0);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
static int
Don't hold the hardware mutex across getc(). It can wait indefinitely for a character to be received. Instead let getc() do any necesary locking.
2006-04-01 19:04:54 +00:00
z8530_getc(struct uart_bas *bas, struct mtx *hwmtx)
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
{
Don't hold the hardware mutex across getc(). It can wait indefinitely for a character to be received. Instead let getc() do any necesary locking.
2006-04-01 19:04:54 +00:00
int c;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
Don't hold the hardware mutex across getc(). It can wait indefinitely for a character to be received. Instead let getc() do any necesary locking.
2006-04-01 19:04:54 +00:00
uart_lock(hwmtx);
while (!(uart_getreg(bas, REG_CTRL) & BES_RXA)) {
uart_unlock(hwmtx);
DELAY(10);
uart_lock(hwmtx);
}
c = uart_getreg(bas, REG_DATA);
uart_unlock(hwmtx);
return (c);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
/*
* High-level UART interface.
*/
struct z8530_softc {
struct uart_softc base;
uint8_t tpc;
Fix hangs caused by z8530_bus_ipend() returning UART_IPEND_TXIDLE not as a pending interrupt status, but as a matter of status quo. Consequently, when there's no data to be transmitted the condition is not cleared and uart_intr() is stuck in an infinite loop trying to clear the UART_IPEND_TXIDLE status. The z8530_bus_ipend() function is changed to return idle only once after having sent any data. The root cause for this problem is that we cannot use the interrupt status bits of the SCC itself. The register that holds the interrupt status can only be accessed by channel A and holds the status for both channels. Using the interrupt status register would complicate the driver because we need to synchronize access to the SCC between the channels. Elementary testing: marius
2004-05-04 06:58:10 +00:00
uint8_t txidle;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
};
static int z8530_bus_attach(struct uart_softc *);
static int z8530_bus_detach(struct uart_softc *);
static int z8530_bus_flush(struct uart_softc *, int);
static int z8530_bus_getsig(struct uart_softc *);
static int z8530_bus_ioctl(struct uart_softc *, int, intptr_t);
static int z8530_bus_ipend(struct uart_softc *);
static int z8530_bus_param(struct uart_softc *, int, int, int, int);
static int z8530_bus_probe(struct uart_softc *);
static int z8530_bus_receive(struct uart_softc *);
static int z8530_bus_setsig(struct uart_softc *, int);
static int z8530_bus_transmit(struct uart_softc *);
static kobj_method_t z8530_methods[] = {
KOBJMETHOD(uart_attach, z8530_bus_attach),
KOBJMETHOD(uart_detach, z8530_bus_detach),
KOBJMETHOD(uart_flush, z8530_bus_flush),
KOBJMETHOD(uart_getsig, z8530_bus_getsig),
KOBJMETHOD(uart_ioctl, z8530_bus_ioctl),
KOBJMETHOD(uart_ipend, z8530_bus_ipend),
KOBJMETHOD(uart_param, z8530_bus_param),
KOBJMETHOD(uart_probe, z8530_bus_probe),
KOBJMETHOD(uart_receive, z8530_bus_receive),
KOBJMETHOD(uart_setsig, z8530_bus_setsig),
KOBJMETHOD(uart_transmit, z8530_bus_transmit),
{ 0, 0 }
};
struct uart_class uart_z8530_class = {
Don't expose the uart_ops structure directly, but instead have it obtained through the uart_class structure. This allows us to declare the uart_class structure as weak and as such allows us to reference it even when it's not compiled-in. It also allows is to get the uart_ops structure by name, which makes it possible to implement the dt tag handling in uart_getenv(). The side-effect of all this is that we're using the uart_class structure more consistently which means that we now also have access to the size of the bus space block needed by the hardware when we map the bus space, eliminating any hardcoding.
2007-04-02 22:00:22 +00:00
"z8530",
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
z8530_methods,
sizeof(struct z8530_softc),
Don't expose the uart_ops structure directly, but instead have it obtained through the uart_class structure. This allows us to declare the uart_class structure as weak and as such allows us to reference it even when it's not compiled-in. It also allows is to get the uart_ops structure by name, which makes it possible to implement the dt tag handling in uart_getenv(). The side-effect of all this is that we're using the uart_class structure more consistently which means that we now also have access to the size of the bus space block needed by the hardware when we map the bus space, eliminating any hardcoding.
2007-04-02 22:00:22 +00:00
.uc_ops = &uart_z8530_ops,
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
.uc_range = 2,
.uc_rclk = DEFAULT_RCLK
};
#define SIGCHG(c, i, s, d) \
if (c) { \
i |= (i & s) ? s : s | d; \
} else { \
i = (i & s) ? (i & ~s) | d : i; \
}
static int
z8530_bus_attach(struct uart_softc *sc)
{
struct z8530_softc *z8530 = (struct z8530_softc*)sc;
struct uart_bas *bas;
struct uart_devinfo *di;
bas = &sc->sc_bas;
if (sc->sc_sysdev != NULL) {
di = sc->sc_sysdev;
z8530->tpc = TPC_DTR|TPC_RTS;
z8530_param(bas, di->baudrate, di->databits, di->stopbits,
di->parity, &z8530->tpc);
} else {
z8530->tpc = z8530_setup(bas, 9600, 8, 1, UART_PARITY_NONE);
z8530->tpc &= ~(TPC_DTR|TPC_RTS);
}
MFp4: Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
2006-02-24 02:42:26 +00:00
z8530->txidle = 1; /* Report SER_INT_TXIDLE. */
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
sc->sc_rxfifosz = 3;
sc->sc_txfifosz = 1;
(void)z8530_bus_getsig(sc);
uart_setmreg(bas, WR_IC, IC_BRK | IC_CTS | IC_DCD);
uart_barrier(bas);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uart_setmreg(bas, WR_IDT, IDT_XIE | IDT_TIE | IDT_RIA);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_barrier(bas);
uart_setmreg(bas, WR_IV, 0);
uart_barrier(bas);
uart_setmreg(bas, WR_TPC, z8530->tpc);
uart_barrier(bas);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uart_setmreg(bas, WR_MIC, MIC_NV | MIC_MIE);
uart_barrier(bas);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (0);
}
static int
z8530_bus_detach(struct uart_softc *sc)
{
return (0);
}
static int
z8530_bus_flush(struct uart_softc *sc, int what)
{
return (0);
}
static int
z8530_bus_getsig(struct uart_softc *sc)
{
uint32_t new, old, sig;
uint8_t bes;
do {
old = sc->sc_hwsig;
sig = old;
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_lock(sc->sc_hwmtx);
Add locking to the hardware drivers. I intended to figure out more precisely where locking would be needed before adding it, but it seems uart(4) draws slightly too much attention to have it without locking for too long. The lock added is a spinlock that protects access to the underlying hardware. As a first and obvious stab at this, each method of the hardware interface grabs the lock. Roughly speaking this serializes the methods. Exceptions are the probe, attach and detach methods.
2003-09-17 01:41:21 +00:00
bes = uart_getmreg(&sc->sc_bas, RR_BES);
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_unlock(sc->sc_hwmtx);
Use the new serial port definitions for modemsignals.
2004-06-24 10:07:28 +00:00
SIGCHG(bes & BES_CTS, sig, SER_CTS, SER_DCTS);
SIGCHG(bes & BES_DCD, sig, SER_DCD, SER_DDCD);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
SIGCHG(bes & BES_SYNC, sig, SER_DSR, SER_DDSR);
Replace our local UART_SIGMASK_* with the global SER_MASK_*.
2006-02-24 05:40:17 +00:00
new = sig & ~SER_MASK_DELTA;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
} while (!atomic_cmpset_32(&sc->sc_hwsig, old, new));
return (sig);
}
static int
z8530_bus_ioctl(struct uart_softc *sc, int request, intptr_t data)
{
struct z8530_softc *z8530 = (struct z8530_softc*)sc;
struct uart_bas *bas;
Implement UART_IOCTL_BAUD for the Z8530. This allows a serial console on PowerPC use the current setting of the hardware and not second guess what the OFW does on various machines.
2006-07-26 17:21:59 +00:00
int baudrate, divisor, error;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
bas = &sc->sc_bas;
Add locking to the hardware drivers. I intended to figure out more precisely where locking would be needed before adding it, but it seems uart(4) draws slightly too much attention to have it without locking for too long. The lock added is a spinlock that protects access to the underlying hardware. As a first and obvious stab at this, each method of the hardware interface grabs the lock. Roughly speaking this serializes the methods. Exceptions are the probe, attach and detach methods.
2003-09-17 01:41:21 +00:00
error = 0;
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_lock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
switch (request) {
case UART_IOCTL_BREAK:
if (data)
z8530->tpc |= TPC_BRK;
else
z8530->tpc &= ~TPC_BRK;
uart_setmreg(bas, WR_TPC, z8530->tpc);
uart_barrier(bas);
break;
Implement UART_IOCTL_BAUD for the Z8530. This allows a serial console on PowerPC use the current setting of the hardware and not second guess what the OFW does on various machines.
2006-07-26 17:21:59 +00:00
case UART_IOCTL_BAUD:
divisor = uart_getmreg(bas, RR_TCH);
divisor = (divisor << 8) | uart_getmreg(bas, RR_TCL);
baudrate = bas->rclk / 2 / (divisor + 2);
*(int*)data = baudrate;
break;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
default:
Add locking to the hardware drivers. I intended to figure out more precisely where locking would be needed before adding it, but it seems uart(4) draws slightly too much attention to have it without locking for too long. The lock added is a spinlock that protects access to the underlying hardware. As a first and obvious stab at this, each method of the hardware interface grabs the lock. Roughly speaking this serializes the methods. Exceptions are the probe, attach and detach methods.
2003-09-17 01:41:21 +00:00
error = EINVAL;
break;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_unlock(sc->sc_hwmtx);
Add locking to the hardware drivers. I intended to figure out more precisely where locking would be needed before adding it, but it seems uart(4) draws slightly too much attention to have it without locking for too long. The lock added is a spinlock that protects access to the underlying hardware. As a first and obvious stab at this, each method of the hardware interface grabs the lock. Roughly speaking this serializes the methods. Exceptions are the probe, attach and detach methods.
2003-09-17 01:41:21 +00:00
return (error);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
static int
z8530_bus_ipend(struct uart_softc *sc)
{
Fix hangs caused by z8530_bus_ipend() returning UART_IPEND_TXIDLE not as a pending interrupt status, but as a matter of status quo. Consequently, when there's no data to be transmitted the condition is not cleared and uart_intr() is stuck in an infinite loop trying to clear the UART_IPEND_TXIDLE status. The z8530_bus_ipend() function is changed to return idle only once after having sent any data. The root cause for this problem is that we cannot use the interrupt status bits of the SCC itself. The register that holds the interrupt status can only be accessed by channel A and holds the status for both channels. Using the interrupt status register would complicate the driver because we need to synchronize access to the SCC between the channels. Elementary testing: marius
2004-05-04 06:58:10 +00:00
struct z8530_softc *z8530 = (struct z8530_softc*)sc;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
struct uart_bas *bas;
int ipend;
uint32_t sig;
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uint8_t bes, ip, iv, src;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
bas = &sc->sc_bas;
ipend = 0;
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_lock(sc->sc_hwmtx);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
switch (bas->chan) {
case 1:
ip = uart_getmreg(bas, RR_IP);
break;
case 2: /* XXX hack!!! */
iv = uart_getmreg(bas, RR_IV) & 0x0E;
switch (iv) {
case IV_TEB: ip = IP_TIA; break;
case IV_XSB: ip = IP_SIA; break;
case IV_RAB: ip = IP_RIA; break;
default: ip = 0; break;
}
break;
default:
ip = 0;
break;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
if (ip & IP_RIA)
MFp4: Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
2006-02-24 02:42:26 +00:00
ipend |= SER_INT_RXREADY;
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
if (ip & IP_TIA) {
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_setreg(bas, REG_CTRL, CR_RSTTXI);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uart_barrier(bas);
if (z8530->txidle) {
MFp4: Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
2006-02-24 02:42:26 +00:00
ipend |= SER_INT_TXIDLE;
z8530->txidle = 0; /* Mask SER_INT_TXIDLE. */
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
}
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
if (ip & IP_SIA) {
uart_setreg(bas, REG_CTRL, CR_RSTXSI);
uart_barrier(bas);
bes = uart_getmreg(bas, RR_BES);
if (bes & BES_BRK)
MFp4: Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
2006-02-24 02:42:26 +00:00
ipend |= SER_INT_BREAK;
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
sig = sc->sc_hwsig;
SIGCHG(bes & BES_CTS, sig, SER_CTS, SER_DCTS);
SIGCHG(bes & BES_DCD, sig, SER_DCD, SER_DDCD);
SIGCHG(bes & BES_SYNC, sig, SER_DSR, SER_DDSR);
Replace our local UART_SIGMASK_* with the global SER_MASK_*.
2006-02-24 05:40:17 +00:00
if (sig & SER_MASK_DELTA)
MFp4: Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
2006-02-24 02:42:26 +00:00
ipend |= SER_INT_SIGCHG;
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
src = uart_getmreg(bas, RR_SRC);
if (src & SRC_OVR) {
uart_setreg(bas, REG_CTRL, CR_RSTERR);
uart_barrier(bas);
MFp4: Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
2006-02-24 02:42:26 +00:00
ipend |= SER_INT_OVERRUN;
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
}
}
if (ipend) {
uart_setreg(bas, REG_CTRL, CR_RSTIUS);
uart_barrier(bas);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_unlock(sc->sc_hwmtx);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (ipend);
}
static int
z8530_bus_param(struct uart_softc *sc, int baudrate, int databits,
int stopbits, int parity)
{
struct z8530_softc *z8530 = (struct z8530_softc*)sc;
int error;
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_lock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
error = z8530_param(&sc->sc_bas, baudrate, databits, stopbits, parity,
&z8530->tpc);
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_unlock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (error);
}
static int
z8530_bus_probe(struct uart_softc *sc)
{
char buf[80];
int error;
Revert the introduction of iobase in struct uart_bas. Both the SAB82532 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-26 05:14:56 +00:00
char ch;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
error = z8530_probe(&sc->sc_bas);
if (error)
return (error);
Revert the introduction of iobase in struct uart_bas. Both the SAB82532 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-26 05:14:56 +00:00
ch = sc->sc_bas.chan - 1 + 'A';
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
Revert the introduction of iobase in struct uart_bas. Both the SAB82532 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-26 05:14:56 +00:00
snprintf(buf, sizeof(buf), "z8530, channel %c", ch);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
device_set_desc_copy(sc->sc_dev, buf);
return (0);
}
static int
z8530_bus_receive(struct uart_softc *sc)
{
struct uart_bas *bas;
int xc;
uint8_t bes, src;
bas = &sc->sc_bas;
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_lock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
bes = uart_getmreg(bas, RR_BES);
In uart_intr() loop until all interrupts have been handled. Previously an UART interface could get stuck when a new interrupt condition arose while servicing a previous interrupt. Since an interrupt was already pending, no new interrupt would be triggered. Avoid infinite recursion by flushing the Rx FIFO and marking an overrun condition when we could not move the data from the Rx FIFO to the receive buffer in toto. Failure to flush the Rx FIFO would leave the Rx ready condition pending. Note that the SAB 82532 already did this due to the nature of the chip.
2003-09-17 03:11:32 +00:00
while (bes & BES_RXA) {
if (uart_rx_full(sc)) {
sc->sc_rxbuf[sc->sc_rxput] = UART_STAT_OVERRUN;
break;
}
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
xc = uart_getreg(bas, REG_DATA);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uart_barrier(bas);
src = uart_getmreg(bas, RR_SRC);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
if (src & SRC_FE)
xc |= UART_STAT_FRAMERR;
if (src & SRC_PE)
xc |= UART_STAT_PARERR;
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
if (src & SRC_OVR)
xc |= UART_STAT_OVERRUN;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_rx_put(sc, xc);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
if (src & (SRC_FE | SRC_PE | SRC_OVR)) {
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
uart_setreg(bas, REG_CTRL, CR_RSTERR);
In uart_intr() loop until all interrupts have been handled. Previously an UART interface could get stuck when a new interrupt condition arose while servicing a previous interrupt. Since an interrupt was already pending, no new interrupt would be triggered. Avoid infinite recursion by flushing the Rx FIFO and marking an overrun condition when we could not move the data from the Rx FIFO to the receive buffer in toto. Failure to flush the Rx FIFO would leave the Rx ready condition pending. Note that the SAB 82532 already did this due to the nature of the chip.
2003-09-17 03:11:32 +00:00
uart_barrier(bas);
}
bes = uart_getmreg(bas, RR_BES);
}
/* Discard everything left in the Rx FIFO. */
while (bes & BES_RXA) {
(void)uart_getreg(bas, REG_DATA);
o Fix the various interrupt related problems caused by reverse engineering the pending interrupt sources from the current state of the controller. For channel A we can always read the interrupt pending register (RR3). For channel B we can read the interrupt vector register (RR2) because it contains the modified vector and thus includes the interrupt source. Since we currently need puc(4) for the Z8530, we know that the interrupt handler for both channels will be called and thus that RR3 will always be read at least once, even if ch A has no pending interrupt. NOTE: The modified interrupt vector has no value that represent a lack of pending interrupt for channel B. That is, the value read when no interrupts are pending is the same as the value for the special receive condition. Fortunately, we don't actually have to depend on that interrupt source. This does mean that we need to properly handle the overflow condition, when we read received character from the chip. o The DSR signal is represented by the SYNC bit in the external status register (RR0). We now properly track DSR. o It's save to enable the external/status interrupt source. We now get interrupts when line signals (DSR, DCD or CTS) change. Problems fixes: o interrupt storms. o blocked open(2). o lack of (hardware) flow control. o unable to report DSR. MFC after: 5 days
2005-01-30 09:00:50 +00:00
uart_barrier(bas);
src = uart_getmreg(bas, RR_SRC);
if (src & (SRC_FE | SRC_PE | SRC_OVR)) {
In uart_intr() loop until all interrupts have been handled. Previously an UART interface could get stuck when a new interrupt condition arose while servicing a previous interrupt. Since an interrupt was already pending, no new interrupt would be triggered. Avoid infinite recursion by flushing the Rx FIFO and marking an overrun condition when we could not move the data from the Rx FIFO to the receive buffer in toto. Failure to flush the Rx FIFO would leave the Rx ready condition pending. Note that the SAB 82532 already did this due to the nature of the chip.
2003-09-17 03:11:32 +00:00
uart_setreg(bas, REG_CTRL, CR_RSTERR);
uart_barrier(bas);
}
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
bes = uart_getmreg(bas, RR_BES);
}
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_unlock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (0);
}
static int
z8530_bus_setsig(struct uart_softc *sc, int sig)
{
struct z8530_softc *z8530 = (struct z8530_softc*)sc;
struct uart_bas *bas;
uint32_t new, old;
bas = &sc->sc_bas;
do {
old = sc->sc_hwsig;
new = old;
Use the new serial port definitions for modemsignals.
2004-06-24 10:07:28 +00:00
if (sig & SER_DDTR) {
SIGCHG(sig & SER_DTR, new, SER_DTR,
SER_DDTR);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
Use the new serial port definitions for modemsignals.
2004-06-24 10:07:28 +00:00
if (sig & SER_DRTS) {
SIGCHG(sig & SER_RTS, new, SER_RTS,
SER_DRTS);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
}
} while (!atomic_cmpset_32(&sc->sc_hwsig, old, new));
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_lock(sc->sc_hwmtx);
Use the new serial port definitions for modemsignals.
2004-06-24 10:07:28 +00:00
if (new & SER_DTR)
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
z8530->tpc |= TPC_DTR;
else
z8530->tpc &= ~TPC_DTR;
Use the new serial port definitions for modemsignals.
2004-06-24 10:07:28 +00:00
if (new & SER_RTS)
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
z8530->tpc |= TPC_RTS;
else
z8530->tpc &= ~TPC_RTS;
uart_setmreg(bas, WR_TPC, z8530->tpc);
uart_barrier(bas);
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_unlock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (0);
}
static int
z8530_bus_transmit(struct uart_softc *sc)
{
Fix hangs caused by z8530_bus_ipend() returning UART_IPEND_TXIDLE not as a pending interrupt status, but as a matter of status quo. Consequently, when there's no data to be transmitted the condition is not cleared and uart_intr() is stuck in an infinite loop trying to clear the UART_IPEND_TXIDLE status. The z8530_bus_ipend() function is changed to return idle only once after having sent any data. The root cause for this problem is that we cannot use the interrupt status bits of the SCC itself. The register that holds the interrupt status can only be accessed by channel A and holds the status for both channels. Using the interrupt status register would complicate the driver because we need to synchronize access to the SCC between the channels. Elementary testing: marius
2004-05-04 06:58:10 +00:00
struct z8530_softc *z8530 = (struct z8530_softc*)sc;
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
struct uart_bas *bas;
bas = &sc->sc_bas;
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_lock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
while (!(uart_getmreg(bas, RR_BES) & BES_TXE))
;
uart_setreg(bas, REG_DATA, sc->sc_txbuf[0]);
uart_barrier(bas);
sc->sc_txbusy = 1;
MFp4: Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
2006-02-24 02:42:26 +00:00
z8530->txidle = 1; /* Report SER_INT_TXIDLE again. */
Add support for scc(4).
2006-03-30 18:37:03 +00:00
uart_unlock(sc->sc_hwmtx);
The uart(4) driver is an universal driver for various UART hardware. 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-09-06 23:13:47 +00:00
return (0);
}
Reference in New Issue Copy Permalink