1. 06 11月, 2014 7 次提交
    • S
      tty: serial: 8250_dma: keep own book keeping about RX transfers · 0fcb7901
      Sebastian Andrzej Siewior 提交于
      After dmaengine_terminate_all() has been invoked then both DMA drivers
      (edma and omap-dma) do not invoke dma_cookie_complete() to mark the
      transfer as complete. This dma_cookie_complete() is performed by the
      Synopsys DesignWare driver which is probably the only one that is used
      by omap8250-dma and hence don't see following problem…
      …which is that once a RX transfer has been terminated then following
      query of channel status reports DMA_IN_PROGRESS (again: the actual
      transfer has been canceled, there is nothing going on anymore).
      
      This means that serial8250_rx_dma() never enqueues another DMA transfer
      because it (wrongly) assumes that there is a transer already pending.
      
      Vinod Koul refuses to accept a patch which adds this
      dma_cookie_complete() to both drivers and so dmaengine_tx_status() would
      report DMA_COMPLETE instead (and behave like the Synopsys DesignWare
      driver already does). He argues that I am not allowed to use the cookie
      to query the status and that the driver already cleaned everything up after
      the invokation of dmaengine_terminate_all().
      
      To end this I add a bookkeeping whether or not a RX-transfer has been
      started to the 8250-dma code. It has already been done for the TX side.
      *Now* we learn about the RX status based on our bookkeeping and don't
      need dmaengine_tx_status() for this anymore.
      
      Cc: vinod.koul@intel.com
      Reviewed-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0fcb7901
    • S
      tty: serial: 8250_dma: handle error on TX submit · b2202821
      Sebastian Andrzej Siewior 提交于
      Right now it is possible that serial8250_tx_dma() fails and returns
      -EBUSY. The caller (serial8250_start_tx()) will then enable
      UART_IER_THRI which will generate an interrupt once the TX FIFO is
      empty.
      In serial8250_handle_irq() nothing will happen because up->dma is set
      and so serial8250_tx_chars() won't be invoked. We end up with plenty of
      interrupts and some "too much work for irq" output.
      
      This patch introduces dma_tx_err in struct uart_8250_port to signal that
      the last invocation of serial8250_tx_dma() failed so we can fill the TX
      FIFO manually. Should the next invocation of serial8250_start_tx()
      succeed then the dma_tx_err flag along with the THRI bit is removed and
      DMA only usage may continue.
      Reviewed-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2202821
    • S
      tty: serial: Add 8250-core based omap driver · 61929cf0
      Sebastian Andrzej Siewior 提交于
      This patch provides a 8250-core based UART driver for the internal OMAP
      UART. The long term goal is to provide the same functionality as the
      current OMAP uart driver and DMA support.
      I tried to merge omap-serial code together with the 8250-core code.
      There should should be hardly a noticable difference. The trigger levels
      are different compared to omap-serial:
      - omap serial
        TX: Interrupt comes after TX FIFO has room for 16 bytes.
            TX of 4096 bytes in one go results in 256 interrupts
      
        RX: Interrupt comes after there is on byte in the FIFO.
            RX of 4096 bytes results in 4096 interrupts.
      
      - this driver
        TX: Interrupt comes once the TX FIFO is empty.
            TX of 4096 bytes results in 65 interrupts. That means there will
            be gaps on the line while the driver reloads the FIFO.
      
        RX: Interrupt comes once there are 48 bytes in the FIFO or less over
            "longer" time frame. We have
                1 / 11520 * 10^3 * 16 => 1.38… ms
            1.38ms to react and purge the FIFO on 115200,8N1. Since the other
            driver fired after each byte it had ~5.47ms time to react. This
            _may_ cause problems if one relies on no missing bytes and has no
            flow control. On the other hand we get only 85 interrupts for the
            same amount of data.
      
      It has been only tested as console UART on am335x-evm, dra7-evm and
      beagle bone. I also did some longer raw-transfers to meassure the load.
      
      The device name is ttyS based instead of ttyO. If a ttyO based node name
      is required please ask udev for it. If both driver are activated (this
      and omap-serial) then this serial driver will take control over the
      device due to the link order
      
      v9…v10:
      	- Tony noticed that omap3 won't show anything after waking up
      	  from core off. In v9 I reworked the register restore and set
      	  IER to 0 by accident. This went unnoticed because start_tx
      	  usually sets ier (either due to DMA bug or due to TX-complete
      	  IRQ).
      	- dropped EFR and SLEEP from capabilities. We do have both but
      	  nobody should touch it. We already handle SLEEP ourself.
      	- make the private copy of the registers (like EFR) u8 instead
      	  u32
      	- drop MDR1 & DL[ML] reset in restore registers. Does not look
      	  required it is set to the required value later.
      	- update MDR1 & SCR only if changed.
      	- set MDR1 as the last thing. The errata says that we should
      	  setup everything before MDR1 set.
      	- avoid div by 0 in omap_8250_get_divisor() if baud rate gets
      	  very large (Frans Klaver fixed the same thing omap-serial)
      	- drop "is in early stage" from Kconfig.
      v8…v9:
      	- less on a file seems to hang the am335x after a while. I
      	  believe I introduce this bug a while ago since I can reproduce
      	  this prior to v8. Fixed by redoing the omap8250_restore_regs()
      v7…v8:
      	- redo the register write. There is now one function for that
      	  which is used from set_termios() and runtime-resume.
      	- drop PORT_OMAP_16750 and move the setup to the omap file. We
      	  have our own set termios function anyway (Heikki Krogerus)
      	- use MEM instead of MEM32. TRM of AM/DM37x says that 32bit
      	  access on THR might result in data abort. We only need 32bit
      	  access in the errata function which is before we use 8250's
      	  read function so it doesn't matter.
      v4…v7:
      	- change trigger levels after some tests with raw transfers.
      v3…v4:
      	- drop RS485 support
      	- wire up ->throttle / ->unthrottle
      v2…v3:
      	- wire up startup & shutdown for wakeup-irq handling.
      	- RS485 handling (well the core does).
      
      v1…v2:
      	- added runtime PM. Could somebody could please double check
      	  this?
      	- added omap_8250_set_termios()
      Reviewed-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Tested-by: NFrans Klaver <frans.klaver@xsens.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61929cf0
    • S
      tty: serial: 8250: make serial8250_console_setup() non _init · f31b5d27
      Sebastian Andrzej Siewior 提交于
      if I boot with console=ttyS0 and the omap driver is module I end up with
      
      | console [ttyS0] disabled
      | omap8250 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 88, base_baud = 3000000) is a 8250
      | Unable to handle kernel paging request at virtual address c07a9de0
      | Modules linked in: 8250_omap(+)
      | CPU: 0 PID: 908 Comm: modprobe Not tainted 3.17.0-rc5+ #1593
      | PC is at serial8250_console_setup+0x0/0xc8
      | LR is at register_console+0x13c/0x3a4
      | [<c0078788>] (register_console) from [<c02d0340>] (uart_add_one_port+0x3cc/0x420)
      | [<c02d0340>] (uart_add_one_port) from [<c02d38a4>] (serial8250_register_8250_port+0x298/0x39c)
      | [<c02d38a4>] (serial8250_register_8250_port) from [<bf006274>] (omap8250_probe+0x218/0x3dc [8250_omap])
      | [<bf006274>] (omap8250_probe [8250_omap]) from [<c02e3424>] (platform_drv_probe+0x2c/0x5c)
      | [<c02e3424>] (platform_drv_probe) from [<c02e1eac>] (driver_probe_device+0x104/0x228)
      …
      | [<c009fa48>] (SyS_init_module) from [<c000e6e0>] (ret_fast_syscall+0x0/0x30)
      | Code: 7823603b f8314620 051b3013 491ed416 (44792204)
      
      because serial8250_console_setup() is already gone.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f31b5d27
    • S
      tty: serial: 8250: Fix wording in runtime-PM comments · 6a529aba
      Sebastian Andrzej Siewior 提交于
      Frans reworded the two comments with better English for better
      understanding. His review hit the mailing list after the patch got
      applied so here is an incremental update.
      Reported-by: NFrans Klaver <frans.klaver@xsens.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a529aba
    • M
      8250_pci: Added driver for Endrun Technologies PTP PCIe card. · 1bc8cde4
      Mike Skoog 提交于
      Added recognition of EndRun Technologies PCIe PTP slave card
      and setup two ttySx ports for communication with the card for
      retrieval of PTP based time and to communicate with the card's
      Linux OS.
      Signed-off-by: NMike Skoog <mskoog@endruntechnologies.com>
      Signed-off-by: NMike Korreng <mkorreng@endruntechnologies.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1bc8cde4
    • S
      tty: serial: 8250_core: restore the LCR register in set_sleep · edf4edac
      Sudhir Sreedharan 提交于
      In ST16650V2 based serial uarts, while initalizing the PM state,
      LCR registers are being initialized to 0 in serial8250_set_sleep().
      If console port is already initialized and being used, this will
      throws garbage in the console.
      Signed-off-by: NSudhir Sreedharan <ssreedharan@mvista.com>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edf4edac
  2. 29 9月, 2014 2 次提交
  3. 27 9月, 2014 5 次提交
  4. 11 9月, 2014 2 次提交
  5. 10 9月, 2014 2 次提交
  6. 09 9月, 2014 8 次提交
  7. 27 8月, 2014 1 次提交
  8. 28 7月, 2014 2 次提交
    • C
      serial: 8250_dw: Add support for deferred probing · c8ed99d4
      Chen-Yu Tsai 提交于
      The 8250_dw driver fails to probe if the specified clock isn't
      registered at probe time. Even if a clock frequency is given,
      the required clock might be gated because it wasn't properly
      enabled.
      
      This happened to me when the device is registered through DT,
      and the clock was part of an MFD, the PRCM found on A31 and A23
      SoCs. Unlike core clocks that are registered with OF_CLK_DECLARE,
      which happen almost immediately after the kernel starts, the
      clocks are registered as sub-devices of the PRCM MFD platform
      device. Even though devices are registered in the order they are
      found in the DT, the drivers are registered in a different,
      arbitrary order. It is possible that the 8250_dw driver is
      registered, and thus associated with the device and probed, before
      the clock driver is registered and probed.
      
      8250_dw then reports unable to get the clock, and fails. Without
      a working console, the kernel panics.
      
      This patch adds support for deferred probe handling for the clock
      and reset controller. It also fixes the cleanup path if
      serial8250_register_8250_port fails.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8ed99d4
    • C
      serial: 8250_dw: Add optional reset control support · 7fe090bf
      Chen-Yu Tsai 提交于
      The Allwinner A31 and A23 SoCs have a reset controller
      maintaining the UART in reset by default.
      
      This patch adds optional reset support to the driver.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fe090bf
  9. 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
  10. 11 7月, 2014 3 次提交
  11. 20 6月, 2014 2 次提交
    • R
      tty/serial: fix 8250 early console option passing to regular console · 60efcf04
      Rob Herring 提交于
      In the conversion to generic early console, the passing of options from
      the early 8250 console to the regular ttyS console was broken. This
      resulted in the baud rate changing when switching consoles during boot.
      
      This feature allows specifying a single console option on the kernel
      command line rather than both an early console and regular serial tty
      console. It would be nice to generalize this feature. However, it only
      works if the correct baud rate can be probed early which is not the
      case on many platforms which have non-standard UART clock rates. So for
      now, this is left as an 8250 specific feature.
      Reported-and-tested-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60efcf04
    • 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
  12. 29 5月, 2014 4 次提交