summaryrefslogtreecommitdiff
path: root/sys/dev/uart/uart_tty.c
Commit message (Collapse)AuthorAgeFilesLines
* Some devices take undesired actions when RTS and DTR areStephen Hurd2019-06-121-3/+6
| | | | | | | | | | | | | | | asserted. Some development boards for example will reset on DTR, and some radio interfaces will transmit on RTS. This patch allows "stty -f /dev/ttyu9.init -rtsdtr" to prevent RTS and DTR from being asserted on open(), allowing these devices to be used without problems. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D20031 Notes: svn path=/head/; revision=348999
* add support for console resuming, implement it for uart, use on x86Andriy Gapon2018-05-291-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a new optional console method cn_resume and a kernel console interface cnresume. Consoles that may need to re-initialize their hardware after suspend (e.g., because firmware does not care to do it) will implement cn_resume. Note that it is called in rather early environment not unlike early boot, so the same restrictions apply. Platform specific code, for platforms that support hardware suspend, should call cnresume early after resume, before any console output is expected. This change fixes a problem with a system of mine failing to resume when a serial console is used. I found that the serial port was in a strange configuration and an attempt to write to it likely resulted in an infinite loop. To avoid adding cn_resume method to every console driver, CONSOLE_DRIVER macro has been extended to support optional methods. Reviewed by: imp, mav MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D15552 Notes: svn path=/head/; revision=334340
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Notes: svn path=/head/; revision=326255
* - Make the code consistent with itself style-wise and bring it closerMarius Strobl2016-01-251-8/+18
| | | | | | | | | to style(9). - Mark unused arguments as such. - Make the ttystates table const. Notes: svn path=/head/; revision=294753
* Fix tty_drain() and, thus, TIOCDRAIN of the current tty(4) incarnationMarius Strobl2016-01-191-0/+13
| | | | | | | | | | | | | | | | to actually wait until the TX FIFOs of UARTs have be drained before returning. This is done by bringing the equivalent of the TS_BUSY flag found in the previous implementation back in an ABI-preserving way. Reported and tested by: Patrick Powell Most likely, drivers for USB-serial-adapters likewise incorporating TX FIFOs as well as other terminal devices that buffer output in some form should also provide implementations of tsw_busy. MFC after: 3 days Notes: svn path=/head/; revision=294362
* Provide the tty-layer mutex when initializing the pps api. This allowsIan Lepore2015-08-081-0/+10
| | | | | | | | | | | | | time_pps_fetch() to be used in blocking mode. Also, don't init the pps api for system devices (consoles) that provide a custom attach routine. The device may actually be a keyboard or other non- tty device. If it wants to do pps processing (unlikely) it must handle everything for itself. (In reality, only a sun keyboard uses a custom attach routine, and it doesn't make a good pps device.) Notes: svn path=/head/; revision=286469
* Do not prevent processes from making changes to the baudrate or theMarcel Moolenaar2014-04-051-6/+0
| | | | | | | | | | | | CLOCAL and HUPCL control flags. There are legit reasons for allowing those to be changed. When /etc/ttys has the "3wire" type (without a baudrate) for the serial port that is the low-level console, then this change has no effect. Obtained from: Juniper Networks, Inc. Notes: svn path=/head/; revision=264175
* Pass the actual baudrate to tty_init_console(). This defines the initialMarcel Moolenaar2014-03-111-1/+1
| | | | | | | | | baudrate of the device special file, and makes sure that on open(2) the UART is programmed with the correct baudrate. This then eliminates the need in uart_tty_param() to override the speed setting. Notes: svn path=/head/; revision=262996
* Plumb the cn_grab and cn_ungrab routines down into the uartWarner Losh2013-12-211-0/+4
| | | | | | | | | | | | | | | | | | | | clients. Mask RX interrupts while grabbed on the atmel serial driver. This UART interrupts every character. When interrupts are enabled at the mountroot> prompt, this means the ISR eats the characters. Rather than try to create a cooperative buffering system for the low level kernel console, instead just mask out the ISR. For NS8250 and decsendents this isn't needed, since interrupts only happen after 14 or more characters (depending on the fifo settings). Plumb such that these are optional so there's no change in behavior for all the other UART clients. ddb worked on this platform because all interrupts were disabled while it was running, so this problem wasn't noticed. The mountroot> issue has been around for a very very long time. MFC after: 3 days Notes: svn path=/head/; revision=259685
* kern cons: introduce infrastructure for console grabbing by kernelAndriy Gapon2011-12-171-0/+12
| | | | | | | | | | | | | | | At the moment grab and ungrab methods of all console drivers are no-ops. Current intended meaning of the calls is that the kernel takes control of console input. In the future the semantics may be extended to mean that the calling thread takes full ownership of the console (e.g. console output from other threads could be suspended). Inspired by: bde MFC after: 2 months Notes: svn path=/head/; revision=228631
* In uart_tty_outwakeup(), check CTS/RTS flow control settings andMarcel Moolenaar2011-01-241-5/+10
| | | | | | | | | | | | | | prevent sending data when CTS is de-asserted. In uart_tty_intr(), call uart_tty_outwakeup() when the CTS signal changed, knowing that uart_tty_outwakeup() will do the right thing for flow control. This avoids redundant conditionals. PR: kern/148644 Submitted by: John Wehle <john@feith.com> MFC after: 3 days Notes: svn path=/head/; revision=217800
* Remove unneeded includes of <sys/termios.h>.Ed Schouten2009-11-281-1/+0
| | | | Notes: svn path=/head/; revision=199872
* Fix RTS/CTS flow control, broken by the TTY overhaul. The new TTYMarcel Moolenaar2009-10-021-26/+29
| | | | | | | | | | | | 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 Notes: svn path=/head/; revision=197721
* Last minute TTY API change: remove mutex argument from tty_alloc().Ed Schouten2009-05-291-1/+1
| | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=193018
* Minor style(9) compliance change.Alexander Kabaev2008-12-271-1/+2
| | | | Notes: svn path=/head/; revision=186521
* Fix detaching of uart(4) devices.Ed Schouten2008-10-231-0/+13
| | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=184208
* Integrate the new MPSAFE TTY layer to the FreeBSD operating system.Ed Schouten2008-08-201-93/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=181905
* Properly propagate overrun conditions to the TTY layer.Marcel Moolenaar2006-07-271-0/+2
| | | | | | | MFC after: 3 days Notes: svn path=/head/; revision=160731
* Convert to new console apiPoul-Henning Kamp2006-05-261-11/+2
| | | | Notes: svn path=/head/; revision=158960
* Don't open if we're going away.Marcel Moolenaar2006-03-301-0/+4
| | | | Notes: svn path=/head/; revision=157277
* MFp4:Marcel Moolenaar2006-02-241-6/+6
| | | | | | | | Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>. Notes: svn path=/head/; revision=155971
* - Use swi_remove() to teardown swi handlers rather thanJohn Baldwin2005-10-261-1/+1
| | | | | | | | intr_event_remove_handler(). - Remove tty: prefix from a couple of swi handler names. Notes: svn path=/head/; revision=151700
* Reorganize the interrupt handling code a bit to make a few things cleanerJohn Baldwin2005-10-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) Notes: svn path=/head/; revision=151658
* Eliminate two unused arguments to ttycreate().Poul-Henning Kamp2005-10-161-1/+1
| | | | Notes: svn path=/head/; revision=151383
* In uart_cnprobe(), fill in the cn_name field of the consdev structure.Marcel Moolenaar2005-05-081-0/+1
| | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=146013
* Start each of the license/copyright comments with /*-, minor shuffle of linesWarner Losh2005-01-061-1/+1
| | | | Notes: svn path=/head/; revision=139749
* Remove asserts which are not correct if the port is a tty.Poul-Henning Kamp2004-10-121-7/+1
| | | | Notes: svn path=/head/; revision=136453
* Use generic tty code instead of (comparatively little) local copies.Poul-Henning Kamp2004-10-121-170/+52
| | | | Notes: svn path=/head/; revision=136421
* Use tty->t_sc to find out softc.Poul-Henning Kamp2004-09-181-8/+6
| | | | Notes: svn path=/head/; revision=135429
* Use ttyalloc() instead of ttymalloc(NULL)Poul-Henning Kamp2004-09-171-1/+1
| | | | Notes: svn path=/head/; revision=135367
* Preparation commit for the tty cleanups that will follow in the nearPoul-Henning Kamp2004-07-151-2/+2
| | | | | | | | | | | | future: rename ttyopen() -> tty_open() and ttyclose() -> tty_close(). We need the ttyopen() and ttyclose() for the new generic cdevsw functions for tty devices in order to have consistent naming. Notes: svn path=/head/; revision=132226
* Define the tty methods as typedefs.Poul-Henning Kamp2004-06-301-2/+1
| | | | | | | | | Change the return type for t_break to void. Add t_ioctl (more about this later). Notes: svn path=/head/; revision=131373
* Use generic support for BREAK and modem control ioctls.Poul-Henning Kamp2004-06-251-65/+27
| | | | Notes: svn path=/head/; revision=131095
* Use the new serial port definitions for modemsignals.Poul-Henning Kamp2004-06-241-29/+29
| | | | Notes: svn path=/head/; revision=131043
* save a few redundant lines by moving the retry loop further backwards.Poul-Henning Kamp2004-06-231-7/+1
| | | | Notes: svn path=/head/; revision=130969
* Do the dreaded s/dev_t/struct cdev */Poul-Henning Kamp2004-06-161-3/+3
| | | | | | | Bump __FreeBSD_version accordingly. Notes: svn path=/head/; revision=130585
* Machine generated patch which changes linedisc calls from accessingPoul-Henning Kamp2004-06-041-8/+8
| | | | | | | | | linesw[] directly to using the ttyld...() functions The ttyld...() functions ar inline so there is no performance hit. Notes: svn path=/head/; revision=130077
* Make the remaining serial drivers call ttyioctl() rather than callingPoul-Henning Kamp2004-06-041-5/+2
| | | | | | | the linedisc directly. Notes: svn path=/head/; revision=130057
* Device megapatch 4/6:Poul-Henning Kamp2004-02-211-1/+2
| | | | | | | | | | | Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags. Notes: svn path=/head/; revision=126080
* Device megapatch 3/6:Poul-Henning Kamp2004-02-211-4/+0
| | | | | | | | | | | | | | | Add missing D_TTY flags to various drivers. Complete asserts that dev_t's passed to ttyread(), ttywrite(), ttypoll() and ttykqwrite() have (d_flags & D_TTY) and a struct tty pointer. Make ttyread(), ttywrite(), ttypoll() and ttykqwrite() the default cdevsw methods for D_TTY drivers and remove the explicit initializations in various drivers cdevsw structures. Notes: svn path=/head/; revision=126078
* Use standard style for cdevsw initializtionPoul-Henning Kamp2004-02-141-9/+9
| | | | Notes: svn path=/head/; revision=125809
* Test the return value of UART_PARAM(). Invalid line parameters did notMarcel Moolenaar2004-02-141-1/+2
| | | | | | | | | | result in an error before. PR: kern/60284 Submitted by: Thomas Sandford <freebsduser@paradisegreen.co.uk> Notes: svn path=/head/; revision=125797
* Don't explicitly initialize d_maj in the cdevsw with MAJOR_AUTO, asMarcel Moolenaar2003-09-281-1/+0
| | | | | | | | per the intentions of conf.h, rev 1.176. This change is a no-op as MAJOR_AUTO equals to 0. Notes: svn path=/head/; revision=120558
* Catch up with the console interface change: the use of makedev() hasMarcel Moolenaar2003-09-261-3/+2
| | | | | | | | | | been abandoned in favor of a (device) name-based approach. Submitted by: phk Tested on: alpha Notes: svn path=/head/; revision=120487
* Add support for using uart(4) for pulse capturing for the Pulse PerMarcel Moolenaar2003-09-111-2/+9
| | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=119996
* The uart(4) driver is an universal driver for various UART hardware.Marcel Moolenaar2003-09-061-0/+569
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. Notes: svn path=/head/; revision=119815