[PATCH 0/4] rockchip: Skip serial pinctrl at pre-reloc phase

[Quentin Schulz]

Hi Jonas,

On 8/5/24 10:43 AM, Jonas Karlman wrote:
> UART pinctrl for serial is typically applied multiple times:
> - in external TPL or in TPL for DEBUG_UART in board_debug_uart_init()
> - in SPL for DEBUG_UART in board_debug_uart_init()
> - in SPL using pinctrl from DT
> - in pre-reloc phase using pinctrl from DT
> - after relocation using pinctrl from DT
> 
> This series change bootph props for the UART pinctrl to not include them
> in pre-reloc phase to save some boot time:
> 

NACK. I feel like this is a hack for vendor trees only.

1) The Device Tree represents the hardware. We need the mux at all times.
2) This breaks users who want to have no serial in TPL/SPL but in proper 
(where you want it as soon as possible I assume, thus pre-reloc).
3) This likely also means if BL31 is configured to output on a different 
UART mux of the same controller for some reason (I've seen weird stuff), 
now U-Boot proper pre-reloc will not output anything as well.

Adding Lukasz in Cc who's trying to fix U-Boot so that this is possible 
on PX30 (therefore, not just a theoretical use case I'm bringing up ;) ).

> - Radxa ROCK Pi S (RK3308): ~80 ms
> - Radxa ZERO 3W (RK3566): ~120 ms
> - Radxa ROCK 5B (RK3588): ~150 ms
> 
> Similar change has already been applied for RK3328 and RK3399 boards.
> 

Then I believe this was a mistake.

> The change for PX30 has not been runtime tested, and only include change
> for uart2, not uart0 and uart5 used on two of the supported px30 boards.
> 

This means we have uart2 pinctrl at all stages even though we make no 
use of it?

I'm starting to wonder if this optimization isn't orthogonal to having 
as much support as possible via an <soc>-u-boot.dtsi which was done to 
make bring-up and maintenance easier. If you're really after 
optimization AND we keep the pinctrl for the debug uart (thus, not 
breaking 2) above), then what we want is cleaning up the default 
px30-u-boot.dtsi and move bootph properties to the board DTS instead?

I was a bit against this "turn-key" solution wrt u-boot DT for 
rk3568/rk3588 but we went ahead, are we changing our mind now? Just to 
know what exactly is the direction we are planning to take.

Cheers,
Quentin