Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 31 3月, 2017 2 次提交
  3. 15 2月, 2017 1 次提交
    • R
      atmel_serial: Use the fractional divider when possible · 2867af2d
      由 Romain Izard 提交于 
      The fractional baud rate generator is available when using the
asynchronous mode of Atmel USART controllers. It makes it possible to
use higher baudrates, in exchange for a less precise clock with a
variable duty cycle.

The existing code restricts its use to the normal mode of the USART
controller, following the recommendation from the datasheet for the
first chip embedding this type of controller. This recommendation has
been removed from the documentation for the newer chips. After
verification, all revisions of this controller should be able to use the
fractional baud rate generator with the different asynchronous modes.

Removing the condition on ATMEL_US_USMODE makes it possible to get
correct baudrates at high speed in more cases.

This was tested with a board using an Atmel SAMA5D2 chip and a TI
WL1831 WiFi/Bluetooth combo chip at 3 Mbauds, with hardware flow control
enabled.
Signed-off-by: NRomain Izard <romain.izard.pro@gmail.com>
Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2867af2d
  5. 10 2月, 2017 1 次提交
  7. 11 1月, 2017 2 次提交
  9. 28 10月, 2016 1 次提交
    • R
      tty/serial: at91: fix hardware handshake on Atmel platforms · 9bcffe75
      由 Richard Genoud 提交于 
      After commit 1cf6e8fc ("tty/serial: at91: fix RTS line management
when hardware handshake is enabled"), the hardware handshake wasn't
functional anymore on Atmel platforms (beside SAMA5D2).

To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS
first:
Before commit 1cf6e8fc ("tty/serial: at91: fix RTS line management
when hardware handshake is enabled"), this flag was never set.
Thus, the CTS/RTS where only handled by serial_core (and everything
worked just fine).

This commit introduced the use of the ATMEL_US_USMODE_HWHS flag,
enabling it for all boards when the user space enables flow control.

When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller
handles a part of the flow control job:
- disable the transmitter when the CTS pin gets high.
- drive the RTS pin high when the DMA buffer transfer is completed or
  PDC RX buffer full or RX FIFO is beyond threshold. (depending on the
  controller version).

NB: This feature is *not* mandatory for the flow control to work.
(Nevertheless, it's very useful if low latencies are needed.)

Now, the specifics of the ATMEL_US_USMODE_HWHS flag:

- For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3,
sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work.
( source: https://lkml.org/lkml/2016/9/7/598 )
Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1
or a new DMA transfer descriptor is set.
=> ATMEL_US_USMODE_HWHS must not be used for those platforms

- For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45,
sam9g46)*, there's another kind of problem. Once the flag
ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via
RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven
by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC
(Receive (Next) Counter Register).
=> Doing this is beyond the scope of this patch and could add other
bugs, so the original (and working) behaviour should be set for those
platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset).

- For platforms with a FIFO (sama5d2)*, the RTS pin is driven according
to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in
USART Control Register. No problem here.
(This was the use case of commit 1cf6e8fc ("tty/serial: at91: fix
RTS line management when hardware handshake is enabled"))
NB: If the CTS pin declared as a GPIO in the DTS, (for instance
cts-gpios = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), the transmitter will be
disabled.
=> ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the
CTS pin is not a GPIO.

So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when
(atmel_use_fifo(port) &&
 !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS))

Tested on all Atmel USART controller flavours:
AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour),
SAMA5D2xplained (FIFO flavour).

* the list may not be exhaustive

Cc: <stable@vger.kernel.org> #4.4+ (beware, missing atmel_port variable)
Fixes: 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9bcffe75
  11. 27 9月, 2016 1 次提交
  13. 15 9月, 2016 1 次提交
    • R
      BUG: atmel_serial: Interrupts not disabled on close · 0ae9fdef
      由 Richard Genoud 提交于 
      Since commit 18dfef9c ("serial: atmel: convert to irq handling
provided mctrl-gpio"), interrupts from GPIOs are not disabled any more
when the serial port is closed, leading to an oops when the one of the
input pin is toggled (CTS/DSR/DCD/RNG).

This is only the case if those pins are used as GPIOs, i.e. declared
like that:
usart1: serial@f8020000 {
        /* CTS and DTS will be handled by GPIO */
        status = "okay";
        rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>;
        cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>;
        dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>;
        dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
        rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>;
        dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>;
};

That's because modem interrupts used to be freed in atmel_shutdown().
After commit 18dfef9c ("serial: atmel: convert to irq handling
provided mctrl-gpio"), this code was just removed.
Calling atmel_disable_ms() disables the interrupts and everything works
fine again.

Tested on at91sam9g35-cm

(This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will
be sent after this one is applied.)
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Fixes: 18dfef9c ("serial: atmel: convert to irq handling provided mctrl-gpio")
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ae9fdef
  15. 02 9月, 2016 1 次提交
  17. 31 8月, 2016 2 次提交
  19. 27 6月, 2016 1 次提交
  21. 26 6月, 2016 4 次提交
  23. 29 4月, 2016 1 次提交
  25. 08 3月, 2016 2 次提交
  27. 07 2月, 2016 3 次提交
  29. 09 1月, 2016 1 次提交
  31. 14 12月, 2015 2 次提交
  33. 18 10月, 2015 2 次提交
  35. 05 10月, 2015 4 次提交
  37. 05 8月, 2015 1 次提交
  39. 24 7月, 2015 3 次提交
    • C
      tty/serial: at91: use 32bit writes into TX FIFO when DMA is enabled · 5f258b3e
      由 Cyrille Pitchen 提交于 
      For now this improvement is only used with TX DMA transfers. The data
width must be set properly when configuring the DMA controller. Also
the FIFO configuration must be set to match the DMA transfer data
width:
TXRDYM (Transmitter Ready Mode) and RXRDYM (Receiver Ready Mode) must
be set into the FIFO Mode Register. These values are used by the
USART to trigger the DMA controller. In single data mode they are not
used and should be reset to 0.
So the TXRDYM bits are changed to FOUR_DATA; then USART triggers the
DMA controller when at least 4 data can be written into the TX FIFO
througth the THR. On the other hand the RXRDYM bits are left unchanged
to ONE_DATA.

Atmel eXtended DMA controller allows us to set a different data width
for each part of a scatter-gather transfer. So when calling
dmaengine_slave_config() to configure the TX path, we just need to set
dst_addr_width to the maximum data width. Then DMA writes into THR are
split into up to two parts. The first part carries the first data to
be sent and has a length equal to the greatest multiple of 4 (bytes)
lower than or equal to the total length of the TX DMA transfer. The
second part carries the trailing data (up to 3 bytes). The first part
is written by the DMA into THR using 32 bit accesses, whereas 8bit
accesses are used for the second part.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f258b3e
    • C
      tty/serial: at91: add support to FIFOs · b5199d46
      由 Cyrille Pitchen 提交于 
      Depending on the hardware, TX and RX FIFOs may be available. The RX
FIFO can avoid receive overruns, especially when DMA transfers are
not used to read data from the Receive Holding Register. For heavy
system load, The CPU is likely not be able to fetch data fast enough
from the RHR.

In addition, the RX FIFO can supersede the DMA/PDC to control the RTS
line when the Hardware Handshaking mode is enabled. Two thresholds
are to be set for that purpose:
- When the number of data in the RX FIFO crosses and becomes lower
  than or equal to the low threshold, the RTS line is set to low
  level: the remote peer is requested to send data.
- When the number of data in the RX FIFO crosses and becomes greater
  than or equal to the high threshold, the RTS line is set to high
  level: the remote peer should stop sending new data.
- low threshold <= high threshold
Once these two thresholds are set properly, this new feature is
enabled by setting the FIFO RTS Control bit of the FIFO Mode Register.

FIFOs also introduce a new multiple data mode: the USART works either
in multiple data mode or in single data (legacy) mode.

If MODE9 bit is set into the Mode Register or if USMODE is set to
either LIN_MASTER, LIN_SLAVE or LON_MODE, FIFOs operate in single
data mode. Otherwise, they operate in multiple data mode.

In this new multiple data mode, accesses to the Receive Holding
Register or Transmit Holding Register slightly change.

Since this driver implements neither the 9bit data feature (MODE9 bit
set into the Mode Register) nor LIN modes, the USART works in
multiple data mode whenever FIFOs are available and enabled. We also
assume that data are 8bit wide.

In single data mode, 32bit access CAN be used to read a single data
from RHR or write a single data into THR.
However in multiple data mode, a 32bit access to RHR now allows us to
read four consecutive data from RX FIFO. Also a 32bit access to THR
now allows to write four consecutive data into TX FIFO. So we MUST
use 8bit access whenever only one data have to be read/written at a
time.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5199d46
    • C
      tty/serial: at91: remove bunch of macros to access UART registers · 4e7decda
      由 Cyrille Pitchen 提交于 
      This patch replaces the UART_PUT_*, resp. UART_GET_*, macros by
atmel_uart_writel(), resp. atmel_uart_readl(), inline function calls.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e7decda
  41. 25 5月, 2015 1 次提交
  43. 07 5月, 2015 1 次提交
  45. 28 4月, 2015 1 次提交
  47. 07 3月, 2015 1 次提交