1. 04 2月, 2011 12 次提交
    • S
      hvc_dcc: Fix bad code generation by marking assembly volatile · a9963201
      Stephen Boyd 提交于
      Without marking the asm __dcc_getstatus() volatile my compiler
      decides it can cache the value of __ret in a register and then
      check the value of it continually in hvc_dcc_put_chars() (I had
      to replace get_wait/put_wait with 1 and fixup the branch
      otherwise my disassembler barfed on __dcc_(get|put)char).
      
      00000000 <hvc_dcc_put_chars>:
         0:   ee103e11        mrc     14, 0, r3, cr0, cr1, {0}
         4:   e3a0c000        mov     ip, #0  ; 0x0
         8:   e2033202        and     r3, r3, #536870912      ; 0x20000000
         c:   ea000006        b       2c <hvc_dcc_put_chars+0x2c>
        10:   e3530000        cmp     r3, #0  ; 0x0
        14:   1afffffd        bne     10 <hvc_dcc_put_chars+0x10>
        18:   e7d1000c        ldrb    r0, [r1, ip]
        1c:   ee10fe11        mrc     14, 0, pc, cr0, cr1, {0}
        20:   2afffffd        bcs     1c <hvc_dcc_put_chars+0x1c>
        24:   ee000e15        mcr     14, 0, r0, cr0, cr5, {0}
        28:   e28cc001        add     ip, ip, #1      ; 0x1
        2c:   e15c0002        cmp     ip, r2
        30:   bafffff6        blt     10 <hvc_dcc_put_chars+0x10>
        34:   e1a00002        mov     r0, r2
        38:   e12fff1e        bx      lr
      
      As you can see, the value of the mrc is checked against
      DCC_STATUS_TX (bit 29) and then stored in r3 for later use.
      Marking the asm volatile produces the following:
      
      00000000 <hvc_dcc_put_chars>:
         0:   e3a03000        mov     r3, #0  ; 0x0
         4:   ea000007        b       28 <hvc_dcc_put_chars+0x28>
         8:   ee100e11        mrc     14, 0, r0, cr0, cr1, {0}
         c:   e3100202        tst     r0, #536870912  ; 0x20000000
        10:   1afffffc        bne     8 <hvc_dcc_put_chars+0x8>
        14:   e7d10003        ldrb    r0, [r1, r3]
        18:   ee10fe11        mrc     14, 0, pc, cr0, cr1, {0}
        1c:   2afffffd        bcs     18 <hvc_dcc_put_chars+0x18>
        20:   ee000e15        mcr     14, 0, r0, cr0, cr5, {0}
        24:   e2833001        add     r3, r3, #1      ; 0x1
        28:   e1530002        cmp     r3, r2
        2c:   bafffff5        blt     8 <hvc_dcc_put_chars+0x8>
        30:   e1a00002        mov     r0, r2
        34:   e12fff1e        bx      lr
      
      which looks better and actually works. Mark all the inline
      assembly in this file as volatile since we don't want the
      compiler to optimize away these statements or move them around
      in any way.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Daniel Walker <dwalker@codeaurora.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a9963201
    • T
      serial: pch_uart: revert Kconfig for non-DMA mode · 380042f2
      Tomoya MORINAGA 提交于
      PCH_DMA is not always enabled when a user uses PCH_UART.
      Since overhead of DMA is not small, in case of low frequent
      communication, without DMA is better.
      Thus, "select PCH_DMA" and DMADEVICES are unnecessary
      Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      380042f2
    • T
      serial: pch_uart: support new device ML7213 · 4564e1ef
      Tomoya MORINAGA 提交于
      Support ML7213 device of OKI SEMICONDUCTOR.
      ML7213 is companion chip of Intel Atom E6xx series for IVI(In-Vehicle Infotainment).
      ML7213 is completely compatible for Intel EG20T PCH.
      Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4564e1ef
    • T
      68328serial: remove unsed m68k_serial->tqueue_hangup · f094298b
      Tejun Heo 提交于
      m68k_serial->tqueue_hangup is unused.  Remove it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f094298b
    • Y
      serial-core: reset the console speed on resume · 5933a161
      Yin Kangkai 提交于
      On some platforms, we need to restore the console speed on resume even
      it was not suspended (no_console_suspend), and on others we don't have
      to do that.
      
      So don't care about the "console_suspend_enabled" and unconditionally
      reset the console speed if it is a console.
      
      This is actually a redo of ba15ab0e (Set proper console speed on resume
      if console suspend is disabled) from Deepak Saxena.  I also tried to
      investigate more to find out if this change will break others, here is
      what I've found out:
      
      commit 891b9dd1
      Author: Jason Wang <jason77.wang@gmail.com>
          serial-core: restore termios settings when resume console ports
      
      commit ca2e71aa
      Author: Jason Wang <jason77.wang@gmail.com>
          serial-core: skip call set_termios/console_start when no_console_suspend
      
      commit 4547be78
      Author: Stanislav Brabec <sbrabec@suse.cz>
          serial-core: resume serial hardware with no_console_suspend
      
      commit ba15ab0e
      Author: Deepak Saxena <dsaxena@laptop.org>
          Set proper console speed on resume if console suspend is disabled
      
      from ba15ab0e, we learned that, even if the console suspend is disabled
      (when no_console_suspend is set), we may still need to "reset the port
      to the state it was in before we suspended."
      
      Then with 4547be78, this piece of code is removed.
      
      And then Jason Wang added that back in ca2e71aa and 891b9dd1, to fix
      some breakage on OMAP3EVM platform. From ca2e71aa we learned that the
      "set_termios" things is actually needed by both console is suspended
      and not suspended.
      
      That's why I removed the console_suspended_enabled condition, and only
      call console_start() when we actually suspeneded it.
      
      I also noticed in this thread:
      http://marc.info/?t=129079257100004&r=1&w=2, which talked about on
      some platforms, UART HW will be cut power whether or not we set
      no_console_suspend, and then on resume it does not work quite well. I
      have a similar HW, and this patch fixed this issue, don't know if this
      patch also works on their platforms.
      
      [Update: Stanislav tested this patch on Zaurus and reported it improves the
      situation. Thanks.]
      
      CC: Greg KH <greg@kroah.com>
      CC: Deepak Saxena <dsaxena@laptop.org>
      CC: Jason Wang <jason77.wang@gmail.com>
      CC: Stanislav Brabec <sbrabec@suse.cz>
      CC: Daniel Drake <dsd@laptop.org>
      Signed-off-by: NYin Kangkai <kangkai.yin@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5933a161
    • D
      serial: mrst_max3110: make buffer larger · d8653d30
      Dan Carpenter 提交于
      This is used to store the spi_device ->modalias so they have to be the same
      size.  SPI_NAME_SIZE is 32.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d8653d30
    • T
      tty_ldisc: don't use flush_scheduled_work() · 0a1f1a0b
      Tejun Heo 提交于
      flush_scheduled_work() is scheduled to be deprecated.  Explicitly sync
      flush the used work items instead.  Note that before this change,
      flush_scheduled_work() wouldn't have properly flushed tty->buf.work if
      it were on timer.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0a1f1a0b
    • J
      serial: omap-serial: Enable the UART wake-up bits always · 78841462
      Jarkko Nikula 提交于
      OMAP can do also dynamic idling so wake-up enable register should be set
      also while system is running. If UART_OMAP_WER is not set, then for instance
      the RX activity cannot wake up the UART port that is sleeping.
      
      This RX wake-up feature was working when the 8250 driver was used instead
      of omap-serial. Reason for this is that the 8250 doesn't set the
      UART_OMAP_WER and then arch/arm/mach-omap2/pm34xx.c ends up saving and
      restoring the reset default which is the same than value
      OMAP_UART_WER_MOD_WKUP here.
      
      Fix this by moving the conditional UART_OMAP_WER write from serial_omap_pm
      into serial_omap_startup where wake-up bits are set unconditionally.
      Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
      Cc: Govindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      78841462
    • T
      OMAP: Enable Magic SysRq on serial console ttyOx · 364a6ece
      Thomas Weber 提交于
      Magic SysRq key is not working for OMAP on new serial
      console ttyOx because SUPPORT_SYSRQ is not defined
      for omap-serial.
      
      This patch defines SUPPORT_SYSRQ in omap-serial and
      enables handling of Magic SysRq character.
      
      Further there is an issue of losing first break character.
      Removing the reset of the lsr_break_flag fixes this issue.
      Signed-off-by: NThomas Weber <weber@corscience.de>
      Acked-by: NGovindraj.R <govindraj.raja@ti.com>
      Tested-by: NManjunath G Kondaiah <manjugk@ti.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      364a6ece
    • R
      serial: ifx6x60: expanded info available from platform data · 2f1522ec
      Russ Gorby 提交于
      Some platform attributes (e.g. max_hz, use_dma) were being intuited
      from the modem type. These things should be specified by the platform
      data.
      
      Added max_hz, use_dma to ifx_modem_platform_data definition,
      replaced is_6160 w/ modem_type, and changed clients accordingly
      Signed-off-by: NRuss Gorby <russ.gorby@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2f1522ec
    • F
      serial: mfd: remove the timeout workaround for A0 · a5f4dbf0
      Feng Tang 提交于
      This is kind of a revert for commit 669b7a09 "hsu: add a periodic
      timer to check dma rx channel", which is a workaround for a bug in A0
      stepping silicon, where a dma rx data timeout is missing for some case.
      Since new silicon has fixed it and the old version is phasing out, no
      need to carry on it any more.
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a5f4dbf0
    • V
      tty: serial: bfin_sport_uart: fix signedness error · 940f3be4
      Vasiliy Kulikov 提交于
      sport->port.irq is unsigned, check for <0 doesn't make sense.
      Explicitly cast it to int to check for error.
      Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      940f3be4
  2. 01 2月, 2011 11 次提交
  3. 31 1月, 2011 17 次提交