linux-toradex.git/drivers/tty/serial/atmel_serial.c, branch v6.4-rc6

serial: atmel: fix incorrect baudrate setup

2023-01-19T15:24:39+00:00

Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
setup") changed uart_set_options to select the correct baudrate
configuration based on the absolute error between requested baudrate and
available standard baudrate settings.
Prior to that commit the baudrate was selected based on which predefined
standard baudrate did not exceed the requested baudrate.
This change of selection logic was never reflected in the atmel serial
driver. Thus the comment left in the atmel serial driver is no longer
accurate.
Additionally the manual rounding up described in that comment and applied
via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
tty_termios_encode_baud_rate to determine the appropriate baudrate flags
this can cause baudrate selection to fail entirely because
tty_termios_encode_baud_rate will only select a baudrate if relative error
between requested and selected baudrate does not exceed +/-2%.
Fix that by requesting actual, exact baudrate used by the serial.

Fixes: ba47f97a18f2 ("serial: core: remove baud_rates when serial console setup")
Cc: stable 
Signed-off-by: Tobias Schramm 
Acked-by: Richard Genoud 
Link: https://lore.kernel.org/r/20230109072940.202936-1-t.schramm@manjaro.org
Signed-off-by: Greg Kroah-Hartman

serial: atmel: don't stop the transmitter when doing PIO

2022-11-23T08:39:24+00:00

Writing ATMEL_US_TXDIS to ATMEL_US_CR makes the transmitter NOT to send
the just queued character. This means when the character is last and
uart calls ops->stop_tx(), the character is not sent at all.

The usart datasheet is not much specific on this, it just says the
transmitter is stopped. But apparently, the character is dropped. So
we should stop the transmitter only for DMA and PDC transfers to not
send any more characters. For PIO, this is unexpected and deviates from
other drivers. In particular, the below referenced commit broke TX as it
added a call to ->stop_tx() after the very last character written to the
transmitter.

So fix this by limiting the write of ATMEL_US_TXDIS to DMA transfers
only.

Even there, I don't know if it is correctly implemented. Are all the
queued characters sent once ->start_tx() is called? Anyone tested flow
control -- be it hard (RTSCTS) or the soft (XOFF/XON) one?

Fixes: 2d141e683e9a ("tty: serial: use uart_port_tx() helper")
Cc: Richard Genoud 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Claudiu Beznea 
Cc: linux-arm-kernel@lists.infradead.org
Reported-by: Michael Walle 
Signed-off-by: Jiri Slaby (SUSE) 
Link: https://lore.kernel.org/r/20221123082736.24566-2-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: atmel: cleanup atmel_start+stop_tx()

2022-11-23T08:39:24+00:00

Define local variables holding information about whether pdc or dma is
used in the HW. These are retested several times by calls to
atmel_use_pdc_tx() and atmel_use_dma_tx(). So to make the code more
readable, simply cache the values.

This is also a preparatory patch for the next one (where is_pdc is used
once more in atmel_stop_tx()).

Cc: Richard Genoud 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Claudiu Beznea 
Cc: linux-arm-kernel@lists.infradead.org
Reported-by: Michael Walle 
Signed-off-by: Jiri Slaby (SUSE) 
Link: https://lore.kernel.org/r/20221123082736.24566-1-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: atmel: Use uart_xmit_advance()

2022-11-03T02:35:41+00:00

Take advantage of the new uart_xmit_advance() helper.

Reviewed-by: Claudiu Beznea 
Acked-By: Richard GENOUD 
Signed-off-by: Ilpo Järvinen 
Link: https://lore.kernel.org/r/20221019091151.6692-12-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

tty: serial: use uart_port_tx() helper

2022-11-03T02:32:40+00:00

uart_port_tx() is a new helper to send characters to the device. Use it
in these drivers.

Cc: Tobias Klauser 
Cc: Richard Genoud 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Claudiu Beznea 
Cc: Vladimir Zapolskiy 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: "Andreas Färber" 
Cc: Manivannan Sadhasivam 
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Jiri Slaby (SUSE) 
Link: https://lore.kernel.org/r/20221004104927.14361-3-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman

tty: serial: atmel: Make the driver aware of the existence of GCLK

2022-09-22T14:31:56+00:00

Previously, the atmel serial driver did not take into account the
possibility of using the more customizable generic clock as its
baudrate generator. Unless there is a Fractional Part available to
increase accuracy, there is a high chance that we may be able to
generate a baudrate closer to the desired one by using the GCLK as the
clock source. Now, depending on the error rate between
the desired baudrate and the actual baudrate, the serial driver will
fallback on the generic clock. The generic clock must be provided
in the DT node of the serial that may need a more flexible clock source.

Furthermore, define the bit that represents the choice of having GCLK
as a baudrate source clock inside the USCLKS bitmask of the Mode Register
of USART IP's.

Signed-off-by: Sergiu Moga 
Link: https://lore.kernel.org/r/20220922113347.144383-9-sergiu.moga@microchip.com
Signed-off-by: Greg Kroah-Hartman

tty: serial: atmel: Only divide Clock Divisor if the IP is USART

2022-09-22T14:31:49+00:00

Make sure that the driver only divides the clock divisor if the
IP handled at that point is USART, since UART IP's do not support
implicit peripheral clock division. Instead, in the case of UART,
go with the highest possible clock divisor.

Signed-off-by: Sergiu Moga 
Reviewed-by: Ilpo Järvinen 
Link: https://lore.kernel.org/r/20220922113347.144383-8-sergiu.moga@microchip.com
Signed-off-by: Greg Kroah-Hartman

tty: serial: atmel: Separate mode clearing between UART and USART

2022-09-22T14:31:42+00:00

When clearing the mode of the serial IP inside the atmel_set_termios()
method, make sure that the difference between the bitfields placement
of the UART IP's and USART IP's is taken into account, as some of
them overlap with each other. For example, ATMEL_UA_BRSRCCK overlaps
with ATMEL_US_NBSTOP and ATMEL_US_USCLKS overlaps with ATMEL_UA_FILTER.

Furthermore, add definitions for the Baud Rate Source Clock and the
Filter bitfields of the Mode Register of UART IP's, since they were
missing.

Signed-off-by: Sergiu Moga 
Link: https://lore.kernel.org/r/20220922113347.144383-7-sergiu.moga@microchip.com
Signed-off-by: Greg Kroah-Hartman

Merge 6.0-rc4 into tty-next

2022-09-05T05:59:28+00:00

We need the tty/serial fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

tty: serial: atmel: Preserve previous USART mode if RS485 disabled

2022-08-30T12:33:08+00:00

Whenever the atmel_rs485_config() driver method would be called,
the USART mode is reset to normal mode before even checking if
RS485 flag is set, thus resulting in losing the previous USART
mode in the case where the checking fails.

Some tools, such as `linux-serial-test`, lead to the driver calling
this method when doing the setup of the serial port: after setting the
port mode (Hardware Flow Control, Normal Mode, RS485 Mode, etc.),
`linux-serial-test` tries to enable/disable RS485 depending on
the commandline arguments that were passed.

Example of how this issue could reveal itself:
When doing a serial communication with Hardware Flow Control through
`linux-serial-test`, the tool would lead to the driver roughly doing
the following:
- set the corresponding bit to 1 (ATMEL_US_USMODE_HWHS bit in the
ATMEL_US_MR register) through the atmel_set_termios() to enable
Hardware Flow Control
- disable RS485 through the atmel_config_rs485() method
Thus, when the latter is called, the mode will be reset and the
previously set bit is unset, leaving USART in normal mode instead of
the expected Hardware Flow Control mode.

This fix ensures that this reset is only done if the checking for
RS485 succeeds and that the previous mode is preserved otherwise.

Fixes: e8faff7330a35 ("ARM: 6092/1: atmel_serial: support for RS485 communications")
Cc: stable 
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Sergiu Moga 
Link: https://lore.kernel.org/r/20220824142902.502596-1-sergiu.moga@microchip.com
Signed-off-by: Greg Kroah-Hartman