1. 22 Feb, 2011 6 commits
  2. 17 Feb, 2011 27 commits
  3. 04 Feb, 2011 3 commits
    • Stephen Boyd's avatar
      hvc_dcc: Simplify assembly for v6 and v7 ARM · 8e6d3fe1
      Stephen Boyd authored
      The inline assembly differences for v6 vs. v7 in the hvc_dcc
      driver are purely optimizations. On a v7 processor, an mrc with
      the pc sets the condition codes to the 28-31 bits of the register
      being read. It just so happens that the TX/RX full bits the DCC
      driver is testing for are high enough in the register to be put
      into the condition codes. On a v6 processor, this "feature" isn't
      implemented and thus we have to do the usual read, mask, test
      operations to check for TX/RX full.
      
      Since we already test the RX/TX full bits before calling
      __dcc_getchar() and __dcc_putchar() we don't actually need to do
      anything special for v7 over v6. The only difference is in
      hvc_dcc_get_chars(). We would test RX full, poll RX full, and
      then read a character from the buffer, whereas now we will test
      RX full, read a character from the buffer, and then test RX full
      again for the second iteration of the loop. It doesn't seem
      possible for the buffer to go from full to empty between testing
      the RX full and reading a character. Therefore, replace the v7
      versions with the v6 versions and everything works the same.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Daniel Walker <dwalker@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8e6d3fe1
    • Stephen Boyd's avatar
      hvc_dcc: Simplify put_chars()/get_chars() loops · bf73bd35
      Stephen Boyd authored
      Casting and anding with 0xff is unnecessary in
      hvc_dcc_put_chars() since buf is already a char[].
      __dcc_get_char() can't return an int less than 0 since it only
      returns a char. Simplify the if statement in hvc_dcc_get_chars()
      to take this into account.
      
      Cc: Daniel Walker <dwalker@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bf73bd35
    • Stephen Boyd's avatar
      hvc_dcc: Fix bad code generation by marking assembly volatile · a9963201
      Stephen Boyd authored
      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: default avatarTony Lindgren <tony@atomide.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Daniel Walker <dwalker@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a9963201
  4. 03 Feb, 2011 4 commits
    • Tomoya MORINAGA's avatar
      serial: pch_uart: revert Kconfig for non-DMA mode · 380042f2
      Tomoya MORINAGA authored
      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: default avatarTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      380042f2
    • Tomoya MORINAGA's avatar
      serial: pch_uart: support new device ML7213 · 4564e1ef
      Tomoya MORINAGA authored
      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: default avatarTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4564e1ef
    • Tejun Heo's avatar
      68328serial: remove unsed m68k_serial->tqueue_hangup · f094298b
      Tejun Heo authored
      m68k_serial->tqueue_hangup is unused.  Remove it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f094298b
    • Yin Kangkai's avatar
      serial-core: reset the console speed on resume · 5933a161
      Yin Kangkai authored
      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: default avatarYin Kangkai <kangkai.yin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5933a161