linux/arch/arm/include/debug/at91.S

37 lines
1.0 KiB
ArmAsm
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-only */
/*
* Copyright (C) 2003-2005 SAN People
*
* Debugging macro include header
*/
#define AT91_DBGU_SR (0x14) /* Status Register */
#define AT91_DBGU_THR (0x1c) /* Transmitter Holding Register */
#define AT91_DBGU_TXRDY (1 << 1) /* Transmitter Ready */
#define AT91_DBGU_TXEMPTY (1 << 9) /* Transmitter Empty */
.macro addruart, rp, rv, tmp
ldr \rp, =CONFIG_DEBUG_UART_PHYS @ System peripherals (phys address)
ldr \rv, =CONFIG_DEBUG_UART_VIRT @ System peripherals (virt address)
.endm
.macro senduart,rd,rx
strb \rd, [\rx, #(AT91_DBGU_THR)] @ Write to Transmitter Holding Register
.endm
ARM: 9004/1: debug: Split waituart to CTS and TXRDY This patch was triggered by a remark from Russell that introducing a call to the waituart (needed to fix debug prints on the Qualcomm platforms) was dangerous because in some cases this will involve waiting for a modem CTS (clear to send) signal, and debug messages would maybe not work on platforms with no modem connected to the UART port: they will just hang waiting for the modem to assert CTS and this might never happen. Looking through all UART debug drivers implementing the waituart macro I discovered that all users except two actually use this macro to check if the UART is ready for TX, let's call this TXRDY. Only two debug UART drivers actually check for CTS: - arch/arm/include/debug/8250.S - arch/arm/include/debug/tegra.S The former is very significant since the 8250 is possibly the most common UART on the planet. We have the following problem: the semantics of waituart are ambiguous making it dangerous to introduce the macro to debug code fixing debug prints for Qualcomm. To start to pry this problem apart, this patch does the following: - Convert all debug UART drivers to define two macros: - waituartcts with the clear semantic to wait for CTS to be asserted - waituarttxrdy with the clear semantic to wait for the TX capability of the UART to be ready - When doing this take care to assign the right function to each drivers macro, so they now do exactly the above. - Update the three sites in the kernel invoking the waituart macro to call waituartcts/waituarttxrdy in sequence, so that the functional impact on the kernel should be zero. After this we can start to change the code sites using this code to do the right thing. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-08-28 01:25:37 +03:00
.macro waituarttxrdy,rd,rx
1001: ldr \rd, [\rx, #(AT91_DBGU_SR)] @ Read Status Register
tst \rd, #AT91_DBGU_TXRDY @ DBGU_TXRDY = 1 when ready to transmit
beq 1001b
.endm
ARM: 9004/1: debug: Split waituart to CTS and TXRDY This patch was triggered by a remark from Russell that introducing a call to the waituart (needed to fix debug prints on the Qualcomm platforms) was dangerous because in some cases this will involve waiting for a modem CTS (clear to send) signal, and debug messages would maybe not work on platforms with no modem connected to the UART port: they will just hang waiting for the modem to assert CTS and this might never happen. Looking through all UART debug drivers implementing the waituart macro I discovered that all users except two actually use this macro to check if the UART is ready for TX, let's call this TXRDY. Only two debug UART drivers actually check for CTS: - arch/arm/include/debug/8250.S - arch/arm/include/debug/tegra.S The former is very significant since the 8250 is possibly the most common UART on the planet. We have the following problem: the semantics of waituart are ambiguous making it dangerous to introduce the macro to debug code fixing debug prints for Qualcomm. To start to pry this problem apart, this patch does the following: - Convert all debug UART drivers to define two macros: - waituartcts with the clear semantic to wait for CTS to be asserted - waituarttxrdy with the clear semantic to wait for the TX capability of the UART to be ready - When doing this take care to assign the right function to each drivers macro, so they now do exactly the above. - Update the three sites in the kernel invoking the waituart macro to call waituartcts/waituarttxrdy in sequence, so that the functional impact on the kernel should be zero. After this we can start to change the code sites using this code to do the right thing. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-08-28 01:25:37 +03:00
.macro waituartcts,rd,rx
.endm
.macro busyuart,rd,rx
1001: ldr \rd, [\rx, #(AT91_DBGU_SR)] @ Read Status Register
tst \rd, #AT91_DBGU_TXEMPTY @ DBGU_TXEMPTY = 1 when transmission complete
beq 1001b
.endm