From: Tom Rini <trini@konsulko.com>
To: Felix Brack <fb@ltec.ch>
Cc: u-boot@lists.denx.de, "Igor Grinberg" <grinberg@compulab.co.il>,
"Enric Balletbo i Serra" <enric.balletbo@collabora.com>,
"Marcin Niestroj" <m.niestroj@grinn-global.com>,
"Sjoerd Simons" <sjoerd.simons@collabora.co.uk>,
"Yegor Yefremov" <yegorslists@googlemail.com>,
"Hannes Schmelzer" <hannes.schmelzer@br-automation.com>,
"Parthiban Nallathambi" <parthiban@linumiz.com>,
"Hiremath Gireesh" <Gireesh.Hiremath@in.bosch.com>,
Govindaraji.Sivanantham@in.bosch.com,
"Javier Martínez Canillas" <javier@dowhile0.org>,
"Andrew F . Davis" <afd@ti.com>,
"Samuel Egli" <samuel.egli@siemens.com>,
"Niel Fourie" <lusus@denx.de>,
sjg@chromium.org, "Heiko Schocher" <hs@denx.de>,
"Dzmitry Sankouski" <dsankouski@gmail.com>,
"Igor Opaniuk" <igor.opaniuk@foundries.io>,
"Marek Behún" <marek.behun@nic.cz>,
"Mark Kettenis" <kettenis@openbsd.org>,
"Michal Simek" <michal.simek@xilinx.com>,
"Moses Christopher" <BollavarapuMoses.Christopher@in.bosch.com>,
"Samuel Holland" <samuel@sholland.org>,
"Stefan Roese" <sr@denx.de>, "Stefano Babic" <sbabic@denx.de>
Subject: Re: [PATCH] arm: am33xx: Fix early debug UART initialization
Date: Tue, 15 Feb 2022 07:37:13 -0500 [thread overview]
Message-ID: <20220215123713.GO3521085@bill-the-cat> (raw)
In-Reply-To: <0b0e5aeb-8a48-3b63-1222-e3c98ade3eb8@ltec.ch>
[-- Attachment #1: Type: text/plain, Size: 5399 bytes --]
On Tue, Feb 15, 2022 at 11:53:41AM +0100, Felix Brack wrote:
> Hello Tom,
>
> On 14.02.22 23:45, Tom Rini wrote:
> > On Mon, Feb 14, 2022 at 05:56:52PM +0100, Felix Brack wrote:
> >> The changes from commit 0dba45864b2a ("arm: Init the debug UART")
> >> prevent the early debug UART from being initialized correctly.
> >> By adding a new SoC specific early UART initialization function this
> >> patch provides a generic location to add the required code. This code
> >> has to be SoC and not board specific.
> >> For the am33xx SoCs the fix consist of configuring early clocks.
> >>
> >> Signed-off-by: Felix Brack <fb@ltec.ch>
> >> ---
> >>
> >> arch/arm/mach-omap2/am33xx/board.c | 7 +++++++
> >> drivers/serial/Kconfig | 13 +++++++++++++
> >> include/debug_uart.h | 15 +++++++++++++++
> >> 3 files changed, 35 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-omap2/am33xx/board.c b/arch/arm/mach-omap2/am33xx/board.c
> >> index c44667668e..a7f0445b93 100644
> >> --- a/arch/arm/mach-omap2/am33xx/board.c
> >> +++ b/arch/arm/mach-omap2/am33xx/board.c
> >> @@ -604,3 +604,10 @@ int arch_cpu_init_dm(void)
> >> #endif
> >> return 0;
> >> }
> >> +
> >> +#if IS_ENABLED(CONFIG_DEBUG_UART_SOC_INIT)
> >> +void soc_debug_uart_init(void)
> >> +{
> >> + setup_early_clocks();
> >> +}
> >> +#endif
> >> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> >> index 345d1881f5..3da4064d35 100644
> >> --- a/drivers/serial/Kconfig
> >> +++ b/drivers/serial/Kconfig
> >> @@ -490,6 +490,19 @@ config DEBUG_UART_SHIFT
> >> value. Use this value to specify the shift to use, where 0=byte
> >> registers, 2=32-bit word registers, etc.
> >>
> >> +config DEBUG_UART_SOC_INIT
> >> + bool "Enable SoC-specific debug UART init"
> >> + depends on DEBUG_UART
> >> + help
> >> + Boards using the same SoC might require some common settings before
> >> + the debug UART can be used. The board specific board_debug_uart_init()
> >> + is not the right place for such common settings as they would apply
> >> + to a specific board only instead of all boards using the same SoC.
> >> + When this option is enabled, the SoC specific function
> >> + soc_debug_uart_init() will be called when debug_uart_init() is called.
> >> + You can put any code here that is needed to set up the UART ready for
> >> + use.
> >> +
> >> config DEBUG_UART_BOARD_INIT
> >> bool "Enable board-specific debug UART init"
> >> depends on DEBUG_UART
> >> diff --git a/include/debug_uart.h b/include/debug_uart.h
> >> index 714b369e6f..ebc84c44cd 100644
> >> --- a/include/debug_uart.h
> >> +++ b/include/debug_uart.h
> >> @@ -42,6 +42,12 @@
> >> * - Immediately afterwards, add DEBUG_UART_FUNCS to define the rest of the
> >> * functionality (printch(), etc.)
> >> *
> >> + * If your SoC needs additional init for the UART to work, enable
> >> + * CONFIG_DEBUG_UART_SOC_INIT and write a function called
> >> + * soc_debug_uart_init() to perform that init. When debug_uart_init() is
> >> + * called, the init will happen automatically. Board specific code does not
> >> + * go here, see board_debug_uart_init() below.
> >> + *
> >> * If your board needs additional init for the UART to work, enable
> >> * CONFIG_DEBUG_UART_BOARD_INIT and write a function called
> >> * board_debug_uart_init() to perform that init. When debug_uart_init() is
> >> @@ -61,6 +67,14 @@
> >> */
> >> void debug_uart_init(void);
> >>
> >> +#ifdef CONFIG_DEBUG_UART_SOC_INIT
> >> +void soc_debug_uart_init(void);
> >> +#else
> >> +static inline void soc_debug_uart_init(void)
> >> +{
> >> +}
> >> +#endif
> >> +
> >> #ifdef CONFIG_DEBUG_UART_BOARD_INIT
> >> void board_debug_uart_init(void);
> >> #else
> >> @@ -192,6 +206,7 @@ void printdec(unsigned int value);
> >> \
> >> void debug_uart_init(void) \
> >> { \
> >> + soc_debug_uart_init(); \
> >> board_debug_uart_init(); \
> >> _debug_uart_init(); \
> >> _DEBUG_UART_ANNOUNCE \
> >
> > I'd be inclined to just re-use board_debug_uart_init on am33xx like
> > other "board" function we have in the SoC level board.c file. That's
> > likely what other platforms are doing as well where this is more SoC
> > than board dependent? Thanks for digging in here BTW, I think I never
> > saw this myself when I needed the UART because I have mine set for UART
> > boot first (and then it does SD boot).
> >
> On the PDU001 board the board specific board_debug_uart_init() is (for
> now) responsible for the pin configuration of UART3 (the debug UART).
> From a discussion with Simon I concluded that other boards based on the
> AM33XX SoCs are also affected from the problem introduced with commit
> 0dba45864b2a.
> The function board_debug_uart_init() can not be moved to the SoC level
> since some boards (like the PDU001) require it. Hence the idea of a SoC
> specific soc_debug_uart_init() function.
> However I now realize that such a "one fits it all" solution is probably
> not the right way to fix things. It might be better to fix this on board
> level especially since there are some boards that are not affected at all.
> Hence I think it is best to drop my patch. I will send a new patch
> fixing the problem for the PDU001 board specifically.
Ah, OK, thanks.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2022-02-15 12:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 16:56 [PATCH] arm: am33xx: Fix early debug UART initialization Felix Brack
2022-02-14 22:45 ` Tom Rini
2022-02-15 10:53 ` Felix Brack
2022-02-15 12:37 ` Tom Rini [this message]
2022-02-23 22:58 ` Simon Glass
2022-02-24 10:00 ` Felix Brack
2022-02-24 23:53 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220215123713.GO3521085@bill-the-cat \
--to=trini@konsulko.com \
--cc=BollavarapuMoses.Christopher@in.bosch.com \
--cc=Gireesh.Hiremath@in.bosch.com \
--cc=Govindaraji.Sivanantham@in.bosch.com \
--cc=afd@ti.com \
--cc=dsankouski@gmail.com \
--cc=enric.balletbo@collabora.com \
--cc=fb@ltec.ch \
--cc=grinberg@compulab.co.il \
--cc=hannes.schmelzer@br-automation.com \
--cc=hs@denx.de \
--cc=igor.opaniuk@foundries.io \
--cc=javier@dowhile0.org \
--cc=kettenis@openbsd.org \
--cc=lusus@denx.de \
--cc=m.niestroj@grinn-global.com \
--cc=marek.behun@nic.cz \
--cc=michal.simek@xilinx.com \
--cc=parthiban@linumiz.com \
--cc=samuel.egli@siemens.com \
--cc=samuel@sholland.org \
--cc=sbabic@denx.de \
--cc=sjg@chromium.org \
--cc=sjoerd.simons@collabora.co.uk \
--cc=sr@denx.de \
--cc=u-boot@lists.denx.de \
--cc=yegorslists@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox