1. 30 Oct, 2009 1 commit
  2. 08 Apr, 2009 1 commit
  3. 19 Oct, 2008 1 commit
  4. 30 May, 2008 1 commit
    • Benno Rice's avatar
      The XScale PXA255 has three generally ns16x50 compatible UARTs. One of the · 0aefb0a6
      Benno Rice authored
      variations from normal 16x50 behaviour however is the the use of a normally
      unused bit of IER to control RX timeout interrupts independently of the
      generally used RXRDY bit.  If this bit is not enabled, we only ever get
      interrupts when the FIFO is full, never before.  This is not very useful when
      the UART is being used as a console.
      In order to support this without causing potential problems on more "normal"
      16x50 variants, this change introduces two hints for the uart device, ier_mask
      and ier_rxbits.  These can be used to override which bits get set and cleared
      when we're enabling and disabling RX interrupts.
      Reviewed by:	marcel
  5. 12 Mar, 2008 1 commit
  6. 03 Apr, 2007 1 commit
    • Marcel Moolenaar's avatar
      Don't use a time-limiting loop that's defined in terms of the baudrate · 35777a2a
      Marcel Moolenaar authored
      in the putc() method.  Likewise, in the getc() method, don't check for
      received characters with an interval defined in terms of the baudrate.
      In both cases it works equally well to implement a fixed delay.  More
      importantly, it avoids calculating a delay that's roughly 1/10th the
      time it takes to send/receive a character. The calculation is costly
      and happens for every character sent or received, affecting low-level
      console or debug port performance significantly. Secondly, when the
      RCLK is not available or unreliable, the delays could disrupt normal
      The fixed delay is 1/10th the time it takes to send a character at
      230400 bps.
  7. 02 Apr, 2007 1 commit
    • Marcel Moolenaar's avatar
      Don't expose the uart_ops structure directly, but instead have · f8100ce2
      Marcel Moolenaar authored
      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.
  8. 28 Mar, 2007 1 commit
    • Marcel Moolenaar's avatar
      For embedded UARTs compatible with the ns8250 family it is possible · ebecffe9
      Marcel Moolenaar authored
      that the driver clock is identical to the processor or bus clock.
      This is the case for the PowerQUICC processor. When the clock is
      high enough, overflows happen in the calculation of the time it
      takes to send 1/10 of a character, used in delay loops. Fix the
      overflows so as to fix bugs in the delay loops that can cause either
      insufficient delays or excessive delays.
  9. 18 Jan, 2007 1 commit
    • Marius Strobl's avatar
      - Add a uart_rxready() and corresponding device-specific implementations · 97202af2
      Marius Strobl authored
        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
  10. 23 May, 2006 2 commits
  11. 27 Apr, 2006 1 commit
  12. 23 Apr, 2006 1 commit
  13. 02 Apr, 2006 1 commit
  14. 01 Apr, 2006 1 commit
  15. 30 Mar, 2006 1 commit
  16. 24 Feb, 2006 2 commits
  17. 06 Jan, 2005 1 commit
  18. 20 Nov, 2004 1 commit
  19. 15 Nov, 2004 1 commit
  20. 14 Nov, 2004 1 commit
  21. 06 Aug, 2004 1 commit
  22. 26 Jul, 2004 1 commit
  23. 24 Jun, 2004 1 commit
  24. 26 May, 2004 1 commit
    • Thomas Moestl's avatar
      It seems that clearing the MCR_IE bit in the modem control register · 89eef2de
      Thomas Moestl authored
      does not reliably prevent the triggering of interrupts for all supported
      configurations. Thus, the FIFO size probe could cause an interrupt,
      which could lead to an interrupt storm in the shared interrupt case.
      To prevent this, change ns8250_bus_probe() to use the overflow bit in
      the line status register instead of the RX ready bit in the interrupt
      identification register to detect whether the FIFO has filled up.
      This allows us to clear all bits in the interrupt enable register during
      the probe, which should prevent interrupts reliably.
      Additionally, the detected FIFO size may be a bit more accurate, because
      the overflow bit is only set when the FIFO did actually fill up, while
      interrupts would trigger a bit early.
      Reviewed and tested on a lot of hardware by:	marcel
  25. 02 Apr, 2004 1 commit
  26. 17 Sep, 2003 2 commits
    • Marcel Moolenaar's avatar
      In uart_intr() loop until all interrupts have been handled. Previously · 44ed791b
      Marcel Moolenaar authored
      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
    • Marcel Moolenaar's avatar
      Add locking to the hardware drivers. I intended to figure out more · 06287620
      Marcel Moolenaar authored
      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.
  27. 13 Sep, 2003 1 commit
  28. 10 Sep, 2003 1 commit
    • Marcel Moolenaar's avatar
      If we failed to size the Rx FIFO, assume the worst. This however · c21e0da2
      Marcel Moolenaar authored
      is not a size of 1. Since we already know there is a FIFO, we can
      safely assume that it is at least 16 bytes. Note that all this is
      mostly academic anyway. We don't use the size of the Rx FIFO
      currently. If we add support for hardware flow control, we only
      care about Rx FIFO sizes larger than 16.
  29. 06 Sep, 2003 1 commit
    • Marcel Moolenaar's avatar
      The uart(4) driver is an universal driver for various UART hardware. · 27d5dc18
      Marcel Moolenaar authored
      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
      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.