1. 22 11月, 2012 3 次提交
  2. 16 11月, 2012 1 次提交
  3. 06 11月, 2012 1 次提交
  4. 13 10月, 2012 1 次提交
  5. 10 4月, 2012 1 次提交
    • S
      tty/serial: atmel_serial: fix RS485 half-duplex problem · 57c36868
      Siftar, Gabe 提交于
      On our custom board, we are using RS485 in half-duplex mode on an AT91SAM9G45.
      SER_RS485_RX_DURING_TX is not set as we do not want to receive the data we
      transmit (our transceiver will receive transmitted data).
      Although the current driver attempts to disable and enable the receiver at the
      appropriate points, incoming data is still loaded into the receive register
      causing our code to receive the very last byte that was sent once the receiver
      is enabled.
      
      I ran this by Atmel support and they wrote: "The issue comes from the fact
      that you disable the PDC/DMA Reception and not the USART Reception channel. In
      your case, the[n] you will still receive data into the USART_RHR register, and
      maybe you [h]ave the overrun flag set. So please disable the USART reception
      channel."
      
      The following patch should force the driver to enable/disable the receiver via
      RXEN/RXDIS fields of the USART control register. It fixed the issue I was
      having.
      Signed-off-by: NGabe Siftar <gabe.siftar@getingeusa.com>
      [nicolas.ferre@atmel.com: slightly modify commit message]
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57c36868
  6. 23 2月, 2012 1 次提交
  7. 05 1月, 2012 1 次提交
  8. 16 11月, 2011 2 次提交
  9. 19 10月, 2011 5 次提交
  10. 25 8月, 2011 1 次提交
  11. 23 8月, 2011 1 次提交
  12. 08 8月, 2011 1 次提交
  13. 25 6月, 2011 1 次提交
    • J
      atmel_serial: fix internal port num · deba1a0d
      Jean-Christophe PLAGNIOL-VILLARD 提交于
      the atmel_ports is link to the console number and not the device id
      
      this was not detected on at91 as we always register the dbgu on the console
      as ttyS0
      
      tested on at91sam9263 by setting the dbgu as ttyS1 and use as console
      
      diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
      index 70e5646..9b8a14f 100644
      - a/arch/arm/mach-at91/board-sam9263ek.c
      + b/arch/arm/mach-at91/board-sam9263ek.c
      @@ -58,14 +58,14 @@ static void __init ek_init_early(void)
              /* Initialize processor: 16.367 MHz crystal */
              at91_initialize(16367660);
      
      -       /* DBGU on ttyS0. (Rx & Tx only) */
      -       at91_register_uart(0, 0, 0);
      +       /* DBGU on ttyS1. (Rx & Tx only) */
      +       at91_register_uart(0, 1, 0);
      
      -       /* USART0 on ttyS1. (Rx, Tx, RTS, CTS) */
      -       at91_register_uart(AT91SAM9263_ID_US0, 1, ATMEL_UART_CTS | ATMEL_UART_RTS);
      +       /* USART0 on ttyS0. (Rx, Tx, RTS, CTS) */
      +       at91_register_uart(AT91SAM9263_ID_US0, 0, ATMEL_UART_CTS | ATMEL_UART_RTS);
      
      -       /* set serial console to ttyS0 (ie, DBGU) */
      -       at91_set_serial_console(0);
      +       /* set serial console to ttyS1 (ie, DBGU) */
      +       at91_set_serial_console(1);
       }
      
       /*
      Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
      deba1a0d
  14. 25 5月, 2011 1 次提交
  15. 20 4月, 2011 1 次提交
  16. 18 2月, 2011 1 次提交
  17. 14 1月, 2011 1 次提交
    • G
      tty: move drivers/serial/ to drivers/tty/serial/ · ab4382d2
      Greg Kroah-Hartman 提交于
      The serial drivers are really just tty drivers, so move them to
      drivers/tty/ to make things a bit neater overall.
      
      This is part of the tty/serial driver movement proceedure as proposed by
      Arnd Bergmann and approved by everyone involved a number of months ago.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Rogier Wolff <R.E.Wolff@bitwizard.nl>
      Cc: Michael H. Warfield <mhw@wittsend.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ab4382d2
  18. 11 8月, 2010 1 次提交
  19. 27 7月, 2010 1 次提交
  20. 04 5月, 2010 1 次提交
  21. 03 3月, 2010 1 次提交
  22. 29 10月, 2009 1 次提交
  23. 20 9月, 2009 2 次提交
  24. 30 7月, 2009 1 次提交
  25. 17 6月, 2009 1 次提交
  26. 01 4月, 2009 1 次提交
  27. 19 2月, 2009 1 次提交
    • A
      atmel_serial might lose modem status change · 27c0c8e5
      Atsushi Nemoto 提交于
      I found a problem of handling of modem status of atmel_serial driver.
      
      With the commit 1ecc26 ("atmel_serial: split the interrupt handler"),
      handling of modem status signal was splitted into two parts.  The
      atmel_tasklet_func() compares new status with irq_status_prev, but
      irq_status_prev is not correct if signal status was changed while the port
      is closed.
      
      Here is a sequence to cause problem:
      
      1. Remote side sets CTS (and DSR).
      2. Local side close the port.
      3. Local side clears RTS and DTR.
      4. Remote side clears CTS and DSR.
      5. Local side reopen the port.  hw_stopped becomes 1.
      6. Local side sets RTS and DTR.
      7. Remote side sets CTS and DSR.
      
      Then CTS change interrupt can be received, but since CTS bit in
      irq_status_prev and new status is same, uart_handle_cts_change() will not
      be called (so hw_stopped will not be cleared, i.e.  cannot send any data).
      
      I suppose irq_status_prev should be initialized at somewhere in open
      sequence.
      
      Itai Levi pointed out that we need to initialize atmel_port->irq_status
      as well here. His analysis is as follows:
      
      > Regarding the second part of the patch (which resets irq_status_prev),
      > it turns out that both versions of the patch (mine and Atsushi's)
      > still leave enough room for faulty behavior when opening the port.
      >
      > This is because we are not resetting both irq_status_prev and
      > irq_status in atmel_startup() to CSR, which leads faulty behavior in
      > the following sequences:
      >
      > First case:
      > 1. closing the port while CTS line = 1 (TX not allowed)
      > 2. setting CTS line = 0 (TX allowed)
      > 3. opening the port
      > 4. transmitting one char
      > 5. Cannot transmit more chars, although CTS line is 0
      >
      > Second case:
      > 1. closing the port while CTS line = 0 (TX allowed)
      > 2. setting CTS line = 1 (TX not allowed)
      > 3. opening the port
      > 4. receiving some chars
      > 5. Now we can transmit, although CTS line is 1
      >
      > This reason for this is that the tasklet is scheduled as a result of
      > TX or RX interrupts (not a status change!), in steps 4 above. Inside
      > the tasklet, the atmel_port->irq_status (which holds the value from
      > the previous session) is compared to atmel_port->irq_status_prev.
      > Hence, a status-change of the CTS line is faultily detected.
      >
      > Both cases were verified on 9260 hardware.
      
      [haavard.skinnemoen@atmel.com: folded with patch from Itai Levi]
      Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Cc: Remy Bohmer <linux@bohmer.net>
      Cc: Marc Pignat <marc.pignat@hevs.ch>
      Cc: Itai Levi <itai.levi.devel@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27c0c8e5
  28. 16 1月, 2009 1 次提交
  29. 07 11月, 2008 1 次提交
  30. 23 9月, 2008 1 次提交
  31. 07 8月, 2008 1 次提交
  32. 21 7月, 2008 1 次提交
    • H
      atmel_serial: Fix tty_port breakage · b1d1619b
      Haavard Skinnemoen 提交于
      The tty pointer has been moved into a tty_port field, so we need to use
      ->info->port.tty instead of just ->info->tty. Fixes these build errors:
      
      David Brownell <david-b@pacbell.net> wrote:
      > drivers/serial/atmel_serial.c: In function 'atmel_rx_from_ring':
      > drivers/serial/atmel_serial.c:665: error: 'struct uart_info' has no member named 'tty'
      > drivers/serial/atmel_serial.c: In function 'atmel_rx_from_dma':
      > drivers/serial/atmel_serial.c:672: error: 'struct uart_info' has no member named 'tty'
      > drivers/serial/atmel_serial.c: In function 'atmel_startup':
      > drivers/serial/atmel_serial.c:797: error: 'struct uart_info' has no member named 'tty'
      > make[2]: *** [drivers/serial/atmel_serial.o] Error 1
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b1d1619b