[U-Boot] [PATCH] tegra30: fix UART2 pinmux table entry
UART2_TXD and UART2_RXD mux 0 SFIO entries should be IRDA not UARTB.
Signed-off-by: Allen Martin amartin@nvidia.com --- arch/arm/cpu/tegra30-common/pinmux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/tegra30-common/pinmux.c b/arch/arm/cpu/tegra30-common/pinmux.c index 122665f..8045fa1 100644 --- a/arch/arm/cpu/tegra30-common/pinmux.c +++ b/arch/arm/cpu/tegra30-common/pinmux.c @@ -149,8 +149,8 @@ const struct tegra_pingroup_desc tegra_soc_pingroups[PINGRP_COUNT] = { PINI(VI_MCLK, VI, VI, VI, VI, VI), PINI(VI_VSYNC, VI, DDR, RSVD2, VI, RSVD4), PINI(VI_HSYNC, VI, DDR, RSVD2, VI, RSVD4), - PINI(UART2_RXD, UART, UARTB, SPDIF, UARTA, SPI4), - PINI(UART2_TXD, UART, UARTB, SPDIF, UARTA, SPI4), + PINI(UART2_RXD, UART, IRDA, SPDIF, UARTA, SPI4), + PINI(UART2_TXD, UART, IRDA, SPDIF, UARTA, SPI4), PINI(UART2_RTS_N, UART, UARTA, UARTB, GMI, SPI4), PINI(UART2_CTS_N, UART, UARTA, UARTB, GMI, SPI4), PINI(UART3_TXD, UART, UARTC, RSVD2, GMI, RSVD4),
On Tue, Jan 08, 2013 at 07:46:03PM -0800, Stephen Warren wrote:
On 01/08/2013 06:23 PM, Allen Martin wrote:
UART2_TXD and UART2_RXD mux 0 SFIO entries should be IRDA not UARTB.
IRDA is just a needlessly different synonym for UARTB; there shouldn't be any mention of IRDA in the pinmux code anywhere, or any users of the pinmux code.
Oh suck, I didn't realize we had synonyms in the pinmux tables, that seems like a really bad idea. Unfortunately it looks like this particular synonym is widespread. I see it used in the pinmux spreadsheets, the downstream Android kernel source, and gfshell code.
The bug I was trying to fix here is that IRDA is referenced in the u-boot cardhu pinmux table. I guess the fix is to change that to UARTB, but it sounds like maybe a larger synonym cleanup is needed everywhere, do you know of any others?
I'm thinking there needs to be some better run time error checking in the u-boot pinmux code too. There are some debug asserts in there now, but because I didn't have debug turned on this particular bug lead to silent corruption of the pinmux registers which was a PITA to track down. Thoughts on turning those asserts into always on error checking code? Not sure how much it will slow down pinmux programming.
-Allen
On 01/09/2013 10:58 AM, Allen Martin wrote:
On Tue, Jan 08, 2013 at 07:46:03PM -0800, Stephen Warren wrote:
On 01/08/2013 06:23 PM, Allen Martin wrote:
UART2_TXD and UART2_RXD mux 0 SFIO entries should be IRDA not UARTB.
IRDA is just a needlessly different synonym for UARTB; there shouldn't be any mention of IRDA in the pinmux code anywhere, or any users of the pinmux code.
Oh suck, I didn't realize we had synonyms in the pinmux tables, that seems like a really bad idea. Unfortunately it looks like this particular synonym is widespread. I see it used in the pinmux spreadsheets, the downstream Android kernel source, and gfshell code.
It will disappear from the downstream kernels once they've picked up the upstream pinctrl driver; I spent a fair bit of time correlating all the various documentation sources and eliminating duplicate names for the upstream kernel pinctrl driver.
The bug I was trying to fix here is that IRDA is referenced in the u-boot cardhu pinmux table.
Oh, I didn't notice that the second time round; I'm pretty sure I pointed it out in the very first review. Maybe that was just of the U-Boot pinmux driver and not the Cardhu file.
I guess the fix is to change that to UARTB, but it sounds like maybe a larger synonym cleanup is needed everywhere, do you know of any others?
I can't recall for sure; I think there were some. I'd suggest comparing upstream U-Boot's pinmux driver with the upstream kernel's pinctrl driver, treating the kernel as canonical now.
I'm thinking there needs to be some better run time error checking in the u-boot pinmux code too. There are some debug asserts in there now, but because I didn't have debug turned on this particular bug lead to silent corruption of the pinmux registers which was a PITA to track down. Thoughts on turning those asserts into always on error checking code? Not sure how much it will slow down pinmux programming.
I doubt the speed would be significantly affected, unless an error triggers and the printf/... actually happens, but you don't really care about speed then.
participants (2)
-
Allen Martin -
Stephen Warren