summaryrefslogtreecommitdiffstats
path: root/sys/dev/uart/uart_tty.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC: r294362, r294414, r294753marius2016-01-271-7/+30
| | | | | | | | | | | | - Fix tty_drain() and, thus, TIOCDRAIN of the current tty(4) incarnation 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 - Make the code consistent with itself style-wise and bring it closer to style(9). - Mark unused arguments as such. - Make the ttystates table const.
* MFC r286469, r286591, r286595, r286596, r286613:ian2015-08-231-0/+10
| | | | | | | | | | | | | | | | | Provide the tty-layer mutex when initializing the pps api. This allows time_pps_fetch() to be used in blocking mode. Allow the choice of PPS signal captured by uart(4) to be runtime-configured, eliminating the need to build a custom kernel to use the CTS signal. Correct the polarity of the PPS assert and clear events with respect to the electrical signals on the serial port. Document the change in polarity of the uart(4) PPS capture. Style fix -- do the braces for switches correctly. Relnotes: yes
* MFC r259685:imp2013-12-231-0/+4
| | | | | | | | | | | | | | | | | | Plumb the cn_grab and cn_ungrab routines down into the uart 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. Approved by: re@ (gjb@)
* kern cons: introduce infrastructure for console grabbing by kernelavg2011-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
* In uart_tty_outwakeup(), check CTS/RTS flow control settings andmarcel2011-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
* Remove unneeded includes of <sys/termios.h>.ed2009-11-281-1/+0
|
* Fix RTS/CTS flow control, broken by the TTY overhaul. The new TTYmarcel2009-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
* Last minute TTY API change: remove mutex argument from tty_alloc().ed2009-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.
* Minor style(9) compliance change.kan2008-12-271-1/+2
|
* Fix detaching of uart(4) devices.ed2008-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
* Integrate the new MPSAFE TTY layer to the FreeBSD operating system.ed2008-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
* Properly propagate overrun conditions to the TTY layer.marcel2006-07-271-0/+2
| | | | MFC after: 3 days
* Convert to new console apiphk2006-05-261-11/+2
|
* Don't open if we're going away.marcel2006-03-301-0/+4
|
* MFp4:marcel2006-02-241-6/+6
| | | | | Stop using our local UART_IPEND_* and instead use the global SER_INT_* as defined in <sys/serial.h>.
* - Use swi_remove() to teardown swi handlers rather thanjhb2005-10-261-1/+1
| | | | | intr_event_remove_handler(). - Remove tty: prefix from a couple of swi handler names.
* Reorganize the interrupt handling code a bit to make a few things cleanerjhb2005-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)
* Eliminate two unused arguments to ttycreate().phk2005-10-161-1/+1
|
* In uart_cnprobe(), fill in the cn_name field of the consdev structure.marcel2005-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.
* Start each of the license/copyright comments with /*-, minor shuffle of linesimp2005-01-061-1/+1
|
* Remove asserts which are not correct if the port is a tty.phk2004-10-121-7/+1
|
* Use generic tty code instead of (comparatively little) local copies.phk2004-10-121-170/+52
|
* Use tty->t_sc to find out softc.phk2004-09-181-8/+6
|
* Use ttyalloc() instead of ttymalloc(NULL)phk2004-09-171-1/+1
|
* Preparation commit for the tty cleanups that will follow in the nearphk2004-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.
* Define the tty methods as typedefs.phk2004-06-301-2/+1
| | | | | | Change the return type for t_break to void. Add t_ioctl (more about this later).
* Use generic support for BREAK and modem control ioctls.phk2004-06-251-65/+27
|
* Use the new serial port definitions for modemsignals.phk2004-06-241-29/+29
|
* save a few redundant lines by moving the retry loop further backwards.phk2004-06-231-7/+1
|
* Do the dreaded s/dev_t/struct cdev */phk2004-06-161-3/+3
| | | | Bump __FreeBSD_version accordingly.
* Machine generated patch which changes linedisc calls from accessingphk2004-06-041-8/+8
| | | | | | linesw[] directly to using the ttyld...() functions The ttyld...() functions ar inline so there is no performance hit.
* Make the remaining serial drivers call ttyioctl() rather than callingphk2004-06-041-5/+2
| | | | the linedisc directly.
* Device megapatch 4/6:phk2004-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.
* Device megapatch 3/6:phk2004-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.
* Use standard style for cdevsw initializtionphk2004-02-141-9/+9
|
* Test the return value of UART_PARAM(). Invalid line parameters did notmarcel2004-02-141-1/+2
| | | | | | | result in an error before. PR: kern/60284 Submitted by: Thomas Sandford <freebsduser@paradisegreen.co.uk>
* Don't explicitly initialize d_maj in the cdevsw with MAJOR_AUTO, asmarcel2003-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.
* Catch up with the console interface change: the use of makedev() hasmarcel2003-09-261-3/+2
| | | | | | | been abandoned in favor of a (device) name-based approach. Submitted by: phk Tested on: alpha
* Add support for using uart(4) for pulse capturing for the Pulse Permarcel2003-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
* The uart(4) driver is an universal driver for various UART hardware.marcel2003-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.
OpenPOWER on IntegriCloud