Commit Graph

22 Commits

Author SHA1 Message Date
Marcel Moolenaar
f8100ce2a7 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
Marius Strobl
97202af2dc - 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
Marcel Moolenaar
54cfafcf98 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
Marcel Moolenaar
afd396ac93 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
Marcel Moolenaar
ace86f3f27 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
Marcel Moolenaar
a24d2e121e 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
Marcel Moolenaar
634e63c986 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
Marcel Moolenaar
8af03381d8 Add support for scc(4). 2006-03-30 18:37:03 +00:00
Marcel Moolenaar
ea54941449 Replace our local UART_SIGMASK_* with the global SER_MASK_*. 2006-02-24 05:40:17 +00:00
Marcel Moolenaar
2d5118050a 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
Marcel Moolenaar
ca83142fc3 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
Marcel Moolenaar
c3c16fcb7b 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
Warner Losh
098ca2bda9 Start each of the license/copyright comments with /*-, minor shuffle of lines 2005-01-06 01:43:34 +00:00
Marcel Moolenaar
0204ed7a3f Include the header with the register definitions from sys/dev/ic. They
are shared now.
2004-11-21 01:43:27 +00:00
Poul-Henning Kamp
28710806cb Use the new serial port definitions for modemsignals. 2004-06-24 10:07:28 +00:00
Marcel Moolenaar
eced428604 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
Marcel Moolenaar
875f70dba4 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
Yoshihiro Takahashi
c423dba334 - Keep the base address in struct uart_bas for sab82532 and z8530 modules.
- Remove buggy uart_cpu_busaddr() function.
2003-09-23 09:25:38 +00:00
Marcel Moolenaar
44ed791b92 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
Marcel Moolenaar
06287620b4 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
Marcel Moolenaar
5cc705512d Remove the assumption that a bus_space_handle_t is an I/O address
from the SAB82532 and the Z8530 hardware drivers by introducing
uart_cpu_busaddr(). The assumption is not true on pc98 where
bus_space_handle_t is a pointer to a structure.
The uart_cpu_busaddr() function will return the bus address
corresponding the tag and handle given to it by the BAS.

WARNING: the intend of the function is STRICTLY to allow hardware
drivers to determine which logical channel they control and is NOT
to be used for actual I/O. It is therefore EXPLICITLY allowed that
uart_cpu_busaddr() returns only the lower 8 bits of the address
and garbage in all other bits. No mistakes...
2003-09-07 21:51:03 +00:00
Marcel Moolenaar
27d5dc189c 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