[PATCH] ARM: stm32: Add IWDG handling into PSCI suspend code

Patrick DELAUNAY patrick.delaunay at foss.st.com
Fri May 12 15:43:25 CEST 2023


Hi,

On 5/11/23 13:54, Marek Vasut wrote:
> On 5/11/23 08:39, Patrice CHOTARD wrote:
>
> Hi,
>
>> On 5/11/23 02:22, Marek Vasut wrote:
>>> In case the IWDG is enabled by either U-Boot or Linux, the IWDG can 
>>> never
>>> be disabled again. That includes low power states, which means that 
>>> if the
>>> IWDG is enabled, the SoC would reset itself after a while in suspend 
>>> via
>>> the IWDG. This is not desired behavior.
>>>
>>> It is possible to enable IWDG pre-timeout IRQ which is routed into 
>>> the EXTI,
>>> and use that IRQ to wake the CPU up before the IWDG timeout is 
>>> reached and
>>> reset is triggered. This pre-timeout IRQ can be used to reload the 
>>> WDT and
>>> then suspend the CPU again every once in a while.
>>>
>>> Implement this functionality for both IWDG1 and IWDG2 by reading out 
>>> all
>>> the unmasked IRQs, comparing the list with currently pending IRQs in 
>>> GICv3:
>>> - If any IRQ is pending and it is NOT IWDG1 or IWDG2 pre-timeout IRQ,
>>>    wake up and let OS handle the IRQs
>>> - If IWDG1 or IWDG2 IRQ is pending and no other IRQ is pending,
>>>    ping the respective IWDG and suspend again
>>>
>>> This does not seem to have any adverse impact on power consumption 
>>> in suspend.
>
> [...]
>
>>> +        /* Ping IWDG2 and ACK pretimer IRQ */
>>> +        if (iwdg2_wake) {
>>> +            writel(IWDG_KR_RELOAD_KEY, STM32_IWDG2_BASE + IWDG_KR);
>>> +            writel(IWDG_EWCR_EWIC, STM32_IWDG2_BASE + IWDG_EWCR);
>>> +        }
>>> +    }
>>>         writel(0x3, STM32_RCC_BASE + RCC_MP_SREQCLRR);
>>>       ddr_sw_self_refresh_exit();
>>
>>
>> Reviewed-by: Patrice Chotard <patrice.chotard at foss.st.com>
>
> I feel like maybe I need to whack the IWDG also BEFORE entering 
> suspend, expect a V2 shortly.
>
> Do you think this IWDG approach is fine to keep the system from 
> rebooting in suspend ? Or do you see any better option for the MP1 ?


I think it is fine if you want to have watchdog running in STANDBY even 
this patch force a wakeup.

but if IWDG 1 or 2 should be not running in STANDBY (but also for STOP) 
for your product,

it can be managed directly by the hardware with OTP, to freeze watchdog.

=> it is a decision for each product of the desired behavior of the IWDG 
in low power mode.


See Ref Manual: 48.3 IWDG implementation

Table 332. STM32MP157x IWDG features

Option bytes to control the activity in Standby mode (6)

6. Controlled via option bytes OTP_IWDG1_FZ_STANDBY and 
OTP_IWDG2_FZ_STANDBY, respectively, for IWDG1 and IWDG2.

and in Table17 => OTP 18 = HW2 bit 5 to 8


Regards

Patrick




More information about the U-Boot mailing list