History log of /freebsd/sys/dev/uart/uart_tty.c (Results 76 – 100 of 117)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0
# 6dcf0a53 28-Sep-2003 Marcel Moolenaar <marcel@FreeBSD.org>

Don't explicitly initialize d_maj in the cdevsw with MAJOR_AUTO, as
per the intentions of conf.h, rev 1.176. This change is a no-op as
MAJOR_AUTO equals to 0.


# 12d984b6 26-Sep-2003 Marcel Moolenaar <marcel@FreeBSD.org>

Catch up with the console interface change: the use of makedev() has
been abandoned in favor of a (device) name-based approach.

Submitted by: phk
Tested on: alpha


# 8194412b 12-Sep-2003 Marcel Moolenaar <marcel@FreeBSD.org>

Add support for using uart(4) for pulse capturing for the Pulse Per
Second (PPS) timing interface. The support is non-optional and by
default uses the DCD line signal as the pulse input. A compile-ti

Add support for using uart(4) for pulse capturing for the Pulse Per
Second (PPS) timing interface. The support is non-optional and by
default uses the DCD line signal as the pulse input. A compile-time
option (UART_PPS_ON_CTS) can be used to have uart(4) use the CTS line
signal.

Include <sys/timepps.h> in uart_bus.h to avoid having to add the
inclusion of that header in all source files.

Reviewed by: phk

show more ...


# 27d5dc18 07-Sep-2003 Marcel Moolenaar <marcel@FreeBSD.org>

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

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.

show more ...


# 9199c09a 06-Jan-2010 Warner Losh <imp@FreeBSD.org>

Merge from head at r201628.

# This hasn't been tested, and there are at least three bad commits
# that need to be backed out before the branch will be stable again.


# f02d50a3 28-Nov-2009 Ed Schouten <ed@FreeBSD.org>

Remove unneeded includes of <sys/termios.h>.


Revision tags: release/8.0.0_cvs, release/8.0.0
# 874108ae 12-Nov-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

MFC @199204


# 0acb3c4a 03-Oct-2009 Marcel Moolenaar <marcel@FreeBSD.org>

Fix RTS/CTS flow control, broken by the TTY overhaul. The new TTY
interface is fairly simple WRT dealing with flow control, but
needed 2 new RX buffer functions with "get-char-from-buf" separated
fro

Fix RTS/CTS flow control, broken by the TTY overhaul. The new TTY
interface is fairly simple WRT dealing with flow control, but
needed 2 new RX buffer functions with "get-char-from-buf" separated
from "advance-buf-pointer" so that the pointer could be advanced
only when ttydisc_rint() succeeded.

MFC after: 1 week

show more ...


# 7e857dd1 12-Jun-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- Merge from HEAD


# c5e30cc0 29-May-2009 Ed Schouten <ed@FreeBSD.org>

Last minute TTY API change: remove mutex argument from tty_alloc().

I don't want people to override the mutex when allocating a TTY. It has
to be there, to keep drivers like syscons happy. So I'm cr

Last minute TTY API change: remove mutex argument from tty_alloc().

I don't want people to override the mutex when allocating a TTY. It has
to be there, to keep drivers like syscons happy. So I'm creating a
tty_alloc_mutex() which can be used in those cases. tty_alloc_mutex()
should eventually be removed.

The advantage of this approach, is that we can just remove a function,
without breaking the regular API in the future.

show more ...


Revision tags: release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0
# 7d376cbc 27-Dec-2008 Alexander Kabaev <kan@FreeBSD.org>

Minor style(9) compliance change.


Revision tags: release/6.4.0_cvs, release/6.4.0
# 9b866e4e 23-Oct-2008 Ed Schouten <ed@FreeBSD.org>

Fix detaching of uart(4) devices.

With our new TTY layer we use a two step device destruction procedure.
The TTY first gets abandoned by the device driver. When the TTY layer
notices all threads hav

Fix detaching of uart(4) devices.

With our new TTY layer we use a two step device destruction procedure.
The TTY first gets abandoned by the device driver. When the TTY layer
notices all threads have left the TTY layer, it deallocates the TTY.

This means that the device unit number should not be reused before a
callback from the TTY layer to the device driver has been made. newbus
doesn't seem to support this concept (yet), so right now just add a
destructor with a big comment in it. It's not ideal, but at least it's
better than panicing.

Reported by: rnoland

show more ...


# bc093719 20-Aug-2008 Ed Schouten <ed@FreeBSD.org>

Integrate the new MPSAFE TTY layer to the FreeBSD operating system.

The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve

Integrate the new MPSAFE TTY layer to the FreeBSD operating system.

The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve the following:

- Improved driver model:

The old TTY layer has a driver model that is not abstract enough to
make it friendly to use. A good example is the output path, where the
device drivers directly access the output buffers. This means that an
in-kernel PPP implementation must always convert network buffers into
TTY buffers.

If a PPP implementation would be built on top of the new TTY layer
(still needs a hooks layer, though), it would allow the PPP
implementation to directly hand the data to the TTY driver.

- Improved hotplugging:

With the old TTY layer, it isn't entirely safe to destroy TTY's from
the system. This implementation has a two-step destructing design,
where the driver first abandons the TTY. After all threads have left
the TTY, the TTY layer calls a routine in the driver, which can be
used to free resources (unit numbers, etc).

The pts(4) driver also implements this feature, which means
posix_openpt() will now return PTY's that are created on the fly.

- Improved performance:

One of the major improvements is the per-TTY mutex, which is expected
to improve scalability when compared to the old Giant locking.
Another change is the unbuffered copying to userspace, which is both
used on TTY device nodes and PTY masters.

Upgrading should be quite straightforward. Unlike previous versions,
existing kernel configuration files do not need to be changed, except
when they reference device drivers that are listed in UPDATING.

Obtained from: //depot/projects/mpsafetty/...
Approved by: philip (ex-mentor)
Discussed: on the lists, at BSDCan, at the DevSummit
Sponsored by: Snow B.V., the Netherlands
dcons(4) fixed by: kan

show more ...


Revision tags: release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0
# dd5b096f 27-Jul-2006 Marcel Moolenaar <marcel@FreeBSD.org>

Properly propagate overrun conditions to the TTY layer.

MFC after: 3 days


# 7672c959 26-May-2006 Poul-Henning Kamp <phk@FreeBSD.org>

Convert to new console api


Revision tags: release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0
# 793bcd17 30-Mar-2006 Marcel Moolenaar <marcel@FreeBSD.org>

Don't open if we're going away.


# 2d511805 24-Feb-2006 Marcel Moolenaar <marcel@FreeBSD.org>

MFp4:
Stop using our local UART_IPEND_* and instead use the global SER_INT_*
as defined in <sys/serial.h>.


Revision tags: release/6.0.0_cvs, release/6.0.0
# 284b6708 26-Oct-2005 John Baldwin <jhb@FreeBSD.org>

- Use swi_remove() to teardown swi handlers rather than
intr_event_remove_handler().
- Remove tty: prefix from a couple of swi handler names.


# e0f66ef8 25-Oct-2005 John Baldwin <jhb@FreeBSD.org>

Reorganize the interrupt handling code a bit to make a few things cleaner
and increase flexibility to allow various different approaches to be tried
in the future.
- Split struct ithd up into two pie

Reorganize the interrupt handling code a bit to make a few things cleaner
and increase flexibility to allow various different approaches to be tried
in the future.
- Split struct ithd up into two pieces. struct intr_event holds the list
of interrupt handlers associated with interrupt sources.
struct intr_thread contains the data relative to an interrupt thread.
Currently we still provide a 1:1 relationship of events to threads
with the exception that events only have an associated thread if there
is at least one threaded interrupt handler attached to the event. This
means that on x86 we no longer have 4 bazillion interrupt threads with
no handlers. It also means that interrupt events with only INTR_FAST
handlers no longer have an associated thread either.
- Renamed struct intrhand to struct intr_handler to follow the struct
intr_foo naming convention. This did require renaming the powerpc
MD struct intr_handler to struct ppc_intr_handler.
- INTR_FAST no longer implies INTR_EXCL on all architectures except for
powerpc. This means that multiple INTR_FAST handlers can attach to the
same interrupt and that INTR_FAST and non-INTR_FAST handlers can attach
to the same interrupt. Sharing INTR_FAST handlers may not always be
desirable, but having sio(4) and uhci(4) fight over an IRQ isn't fun
either. Drivers can always still use INTR_EXCL to ask for an interrupt
exclusively. The way this sharing works is that when an interrupt
comes in, all the INTR_FAST handlers are executed first, and if any
threaded handlers exist, the interrupt thread is scheduled afterwards.
This type of layout also makes it possible to investigate using interrupt
filters ala OS X where the filter determines whether or not its companion
threaded handler should run.
- Aside from the INTR_FAST changes above, the impact on MD interrupt code
is mostly just 's/ithread/intr_event/'.
- A new MI ddb command 'show intrs' walks the list of interrupt events
dumping their state. It also has a '/v' verbose switch which dumps
info about all of the handlers attached to each event.
- We currently don't destroy an interrupt thread when the last threaded
handler is removed because it would suck for things like ppbus(8)'s
braindead behavior. The code is present, though, it is just under
#if 0 for now.
- Move the code to actually execute the threaded handlers for an interrrupt
event into a separate function so that ithread_loop() becomes more
readable. Previously this code was all in the middle of ithread_loop()
and indented halfway across the screen.
- Made struct intr_thread private to kern_intr.c and replaced td_ithd
with a thread private flag TDP_ITHREAD.
- In statclock, check curthread against idlethread directly rather than
curthread's proc against idlethread's proc. (Not really related to intr
changes)

Tested on: alpha, amd64, i386, sparc64
Tested on: arm, ia64 (older version of patch by cognet and marcel)

show more ...


# 73363473 16-Oct-2005 Poul-Henning Kamp <phk@FreeBSD.org>

Eliminate two unused arguments to ttycreate().


# 9f0974f9 08-May-2005 Marcel Moolenaar <marcel@FreeBSD.org>

In uart_cnprobe(), fill in the cn_name field of the consdev structure.
The core console code checks this field when a console is added and
emits a warning if it's empty. In practice the warning is ha

In uart_cnprobe(), fill in the cn_name field of the consdev structure.
The core console code checks this field when a console is added and
emits a warning if it's empty. In practice the warning is harmless for
uart(4), because the cn_name is filled in as soon as the device name is
known; which is when the device is enumerated.
To avoid the warning, to avoid possible complications caused by emitting
the warning without there (possibly) being a console selected yet and to
avoid complications when the UART isn't found during bus enumeration, we
just preset the cn_name field here to the name of the driver.

show more ...


Revision tags: release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0
# 098ca2bd 06-Jan-2005 Warner Losh <imp@FreeBSD.org>

Start each of the license/copyright comments with /*-, minor shuffle of lines


Revision tags: release/5.3.0_cvs, release/5.3.0
# fbbec42f 12-Oct-2004 Poul-Henning Kamp <phk@FreeBSD.org>

Remove asserts which are not correct if the port is a tty.


# 79a8d927 12-Oct-2004 Poul-Henning Kamp <phk@FreeBSD.org>

Use generic tty code instead of (comparatively little) local copies.


# 9e51d6f1 18-Sep-2004 Poul-Henning Kamp <phk@FreeBSD.org>

Use tty->t_sc to find out softc.


12345