1. 27 9月, 2014 1 次提交
  2. 10 9月, 2014 1 次提交
  3. 09 9月, 2014 5 次提交
  4. 18 7月, 2014 2 次提交
    • Y
      serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers · aef9a7bd
      Yoshihiro YUNOMAE 提交于
      Add tunable RX interrupt trigger I/F of FIFO buffers.
      
      Serial devices are used as not only message communication devices but control
      or sending communication devices. For the latter uses, normally small data
      will be exchanged, so user applications want to receive data unit as soon as
      possible for real-time tendency. If we have a sensor which sends a 1 byte data
      each time and must control a device based on the sensor feedback, the RX
      interrupt should be triggered for each data.
      
      According to HW specification of serial UART devices, RX interrupt trigger
      can be changed, but the trigger is hard-coded. For example, RX interrupt trigger
      in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
      the trigger to only 8bytes.
      
      This patch makes some devices change RX interrupt trigger from userland.
      
      <How to use>
      - Read current setting
       # cat /sys/class/tty/ttyS0/rx_trig_bytes
       8
      
      - Write user setting
       # echo 1 > /sys/class/tty/ttyS0/rx_trig_bytes
       # cat /sys/class/tty/ttyS0/rx_trig_bytes
       1
      
      <Support uart devices>
      - 16550A and Tegra (1, 4, 8, or 14 bytes)
      - 16650V2 (8, 16, 24, or 28 bytes)
      - 16654 (8, 16, 56, or 60 bytes)
      - 16750 (1, 16, 32, or 56 bytes)
      
      <Change log>
      Changes in V9:
       - Use attr_group instead of dev_spec_attr_group of uart_port structure
      
      Changes in V8:
       - Divide this patch from V7's patch based on Greg's comment
      
      Changes in V7:
       - Add Documentation
       - Change I/F name from rx_int_trig to rx_trig_bytes because the name
         rx_int_trig is hard to understand how users specify the value
      
      Changes in V6:
       - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h,
         rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to
         UART_FCR_R_TRIG_BITS()
       - Change following function names:
          convert_fcr2val() => fcr_get_rxtrig_bytes()
          convert_val2rxtrig() => bytes_to_fcr_rxtrig()
       - Fix typo in serial8250_do_set_termios()
       - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig()
       - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables
         (but UI remains rx_int_trig)
       - Change the meaningless variable name 'val' to 'bytes' following functions:
          fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(),
          do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig()
       - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in
         fcr_get_rxtrig_bytes()
       - Use conf_type->rxtrig_bytes[0] instead of switch statement for support check
         in register_dev_spec_attr_grp()
       - Delete the checking whether a user changed FCR or not when minimum buffer
         is needed in serial8250_do_set_termios()
      
      Changes in V5.1:
       - Fix FCR_RX_TRIG_MAX_STATE definition
      
      Changes in V5:
       - Support Tegra, 16650V2, 16654, and 16750
       - Store default FCR value to up->fcr when the port is first created
       - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[]
         in convert_fcr2val() and convert_val2rxtrig()
      
      Changes in V4:
       - Introduce fifo_bug flag in uart_8250_port structure
         This is enabled only when parity is enabled and UART_BUG_PARITY is enabled
         for up->bugs. If this flag is enabled, user cannot set RX trigger.
       - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and
         at convert_val2rxtrig()
       - Set the nearest lower RX trigger when users input a meaningless value at
         convert_val2rxtrig()
       - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos()
       - Set fcr = up->fcr in the begging of serial8250_do_set_termios()
      
      Changes in V3:
       - Change I/F from ioctl(2) to sysfs(rx_int_trig)
      
      Changed in V2:
       - Use _IOW for TIOCSFIFORTRIG definition
       - Pass the interrupt trigger value itself
      Signed-off-by: NYoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aef9a7bd
    • A
      serial: 8250: introduce up_to_u8250p() helper · b1261c86
      Andy Shevchenko 提交于
      It helps to cast struct uart_port to struct uart_8250_port at runtime.
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1261c86
  5. 20 6月, 2014 1 次提交
    • P
      serial: Fix IGNBRK handling · ef8b9ddc
      Peter Hurley 提交于
      If IGNBRK is set without either BRKINT or PARMRK set, some uart
      drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the
      line discipline, when it should send either nothing or the TTYBREAK flag
      set. This happens because the read_status_mask masks out the BI
      condition, which uart_insert_char() then interprets as a normal 0x00 byte.
      
      SUS v3 is clear regarding the meaning of IGNBRK; Section 11.2.2, General
      Terminal Interface - Input Modes, states:
        "If IGNBRK is set, a break condition detected on input shall be ignored;
         that is, not put on the input queue and therefore not read by any
         process."
      
      Fix read_status_mask to include the BI bit if IGNBRK is set; the
      lsr status retains the BI bit if a BREAK is recv'd, which is
      subsequently ignored in uart_insert_char() when masked with the
      ignore_status_mask.
      
      Affected drivers:
      8250 - all
      serial_txx9
      mfd
      amba-pl010
      amba-pl011
      atmel_serial
      bfin_uart
      dz
      ip22zilog
      max310x
      mxs-auart
      netx-serial
      pnx8xxx_uart
      pxa
      sb1250-duart
      sccnxp
      serial_ks8695
      sirfsoc_uart
      st-asc
      vr41xx_siu
      zs
      sunzilog
      fsl_lpuart
      sunsab
      ucc_uart
      bcm63xx_uart
      sunsu
      efm32-uart
      pmac_zilog
      mpsc
      msm_serial
      m32r_sio
      
      Unaffected drivers:
      omap-serial
      rp2
      sa1100
      imx
      icom
      
      Annotated for fixes:
      altera_uart
      mcf
      
      Drivers without break detection:
      21285
      xilinx-uartps
      altera_jtaguart
      apbuart
      arc-uart
      clps711x
      max3100
      uartlite
      msm_serial_hs
      nwpserial
      lantiq
      vt8500_serial
      
      Unknown:
      samsung
      mpc52xx_uart
      bfin_sport_uart
      cpm_uart/core
      
      Fixes: Bugzilla #71651, '8250_core.c incorrectly handles IGNBRK flag'
      Reported-by: NIvan <athlon_@mail.ru>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef8b9ddc
  6. 29 5月, 2014 1 次提交
    • M
      serial: uart: add hw flow control support configuration · 06aa82e4
      Murali Karicheri 提交于
      8250 uart driver currently supports only software assisted hw flow
      control. The software assisted hw flow control maintains a hw_stopped
      flag in the tty structure to stop and start transmission and use modem
      status interrupt for the event to drive the handshake signals. This is
      not needed if hw has flow control capabilities. This patch adds a
      DT attribute for enabling hw flow control for a uart port. Also skip
      stop and start if this flag is present in flag field of the port
      structure.
      Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
      CC: Rob Herring <robh+dt@kernel.org>
      CC: Pawel Moll <pawel.moll@arm.com>
      CC: Mark Rutland <mark.rutland@arm.com>
      CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
      CC: Kumar Gala <galak@codeaurora.org>
      CC: Randy Dunlap <rdunlap@infradead.org>
      CC: Jiri Slaby <jslaby@suse.cz>
      CC: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06aa82e4
  7. 04 5月, 2014 1 次提交
  8. 25 4月, 2014 2 次提交
  9. 18 4月, 2014 1 次提交
  10. 17 4月, 2014 1 次提交
  11. 09 3月, 2014 1 次提交
  12. 01 3月, 2014 1 次提交
  13. 14 2月, 2014 1 次提交
  14. 08 1月, 2014 1 次提交
    • S
      serial: 8250: enable UART_BUG_NOMSR for Tegra · 3685f19e
      Stephen Warren 提交于
      Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
      their MODEM-control signals tied off to a static state. However UARTs A
      and B can optionally route those signals to/from package pins, depending
      on the exact pinmux configuration.
      
      When these signals are not routed to package pins, false interrupts may
      trigger either temporarily, or permanently, all while not showing up in
      the IIR; it will read as NO_INT. This will eventually lead to the UART
      IRQ being disabled due to unhandled interrupts. When this happens, the
      kernel may print e.g.:
      
          irq 68: nobody cared (try booting with the "irqpoll" option)
      
      In order to prevent this, enable UART_BUG_NOMSR. This prevents
      UART_IER_MSI from being enabled, which prevents the false interrupts
      from triggering.
      
      In practice, this is not needed under any of the following conditions:
      
      * On Tegra chips after Tegra30, since the HW bug has apparently been
        fixed.
      
      * On UARTs C..E since their MODEM control signals are tied to the correct
        static state which doesn't trigger the issue.
      
      * On UARTs A..B if the MODEM control signals are routed out to package
        pins, since they will then carry valid signals.
      
      However, we ignore these exceptions for now, since they are only relevant
      if a board actually hooks up more than a 4-wire UART, and no currently
      supported board does this. If we ever support a board that does, we can
      refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
      into account, and/or read a flag from DT/... that indicates that the
      board has hooked up and pinmux'd more than a 4-wire UART.
      
      Reported-by: Olof Johansson <olof@lixom.net> # autotester
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3685f19e
  15. 27 9月, 2013 1 次提交
  16. 01 8月, 2013 1 次提交
  17. 04 6月, 2013 1 次提交
  18. 26 3月, 2013 3 次提交
  19. 12 3月, 2013 2 次提交
  20. 30 1月, 2013 1 次提交
  21. 18 1月, 2013 1 次提交
  22. 16 1月, 2013 4 次提交
  23. 22 11月, 2012 6 次提交