[PATCH next 2/5] rockchip: rk3399: merge CRU check within rk3399_force_power_on_reset

[Paul Kocialkowski]

Hi,

Le Tue 05 Nov 24, 16:36, Quentin Schulz a écrit :
> From: Quentin Schulz <quentin.schulz at cherry.de>
> 
> To prepare to support forcing power on reset from TPL which would have
> the exact same logic, just in an earlier stage, let's merge the CRU
> check that triggers the power on reset with the rest of the logic.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>

Reviewed-by: Paul Kocialkowski <paulk at sys-base.io>

Cheers,

Paul

> ---
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 43 +++++++++++++++++-----------------
>  1 file changed, 21 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index edccb2a3980d0e3921aa4073b67aea6a00f18b8d..7b6a822ed04b8151a5da147056dbf73ffdafd149 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -172,9 +172,29 @@ void board_debug_uart_init(void)
>  #if defined(CONFIG_XPL_BUILD) && !defined(CONFIG_TPL_BUILD)
>  static void rk3399_force_power_on_reset(void)
>  {
> +	const struct rockchip_cru *cru = rockchip_get_cru();
>  	ofnode node;
>  	struct gpio_desc sysreset_gpio;
>  
> +	/*
> +	 * The RK3399 resets only 'almost all logic' (see also in the
> +	 * TRM "3.9.4 Global software reset"), when issuing a software
> +	 * reset. This may cause issues during boot-up for some
> +	 * configurations of the application software stack.
> +	 *
> +	 * To work around this, we test whether the last reset reason
> +	 * was a power-on reset and (if not) issue an overtemp-reset to
> +	 * reset the entire module.
> +	 *
> +	 * While this was previously fixed by modifying the various
> +	 * places that could generate a software reset (e.g. U-Boot's
> +	 * sysreset driver, the ATF or Linux), we now have it here to
> +	 * ensure that we no longer have to track this through the
> +	 * various components.
> +	 */
> +	if (cru->glb_rst_st == 0)
> +		return;
> +
>  	if (!IS_ENABLED(CONFIG_SPL_GPIO)) {
>  		debug("%s: trying to force a power-on reset but no GPIO "
>  		      "support in SPL!\n", __func__);
> @@ -206,27 +226,6 @@ void spl_board_init(void)
>  {
>  	led_setup();
>  
> -	if (IS_ENABLED(CONFIG_SPL_GPIO)) {
> -		struct rockchip_cru *cru = rockchip_get_cru();
> -
> -		/*
> -		 * The RK3399 resets only 'almost all logic' (see also in the
> -		 * TRM "3.9.4 Global software reset"), when issuing a software
> -		 * reset. This may cause issues during boot-up for some
> -		 * configurations of the application software stack.
> -		 *
> -		 * To work around this, we test whether the last reset reason
> -		 * was a power-on reset and (if not) issue an overtemp-reset to
> -		 * reset the entire module.
> -		 *
> -		 * While this was previously fixed by modifying the various
> -		 * places that could generate a software reset (e.g. U-Boot's
> -		 * sysreset driver, the ATF or Linux), we now have it here to
> -		 * ensure that we no longer have to track this through the
> -		 * various components.
> -		 */
> -		if (cru->glb_rst_st != 0)
> -			rk3399_force_power_on_reset();
> -	}
> +	rk3399_force_power_on_reset();
>  }
>  #endif
> 
> -- 
> 2.47.0
> 

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Specialist in multimedia, graphics and embedded hardware support with Linux.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241105/a2fbfc10/attachment.sig>