[PATCH next RFC 0/5] rockchip: panic() when DRAM init fails

[Quentin Schulz]

Hi Kever,

On 11/5/24 6:21 PM, Quentin Schulz wrote:
> I am the unfortunate owner of an RK3399 Puma that is failing DRAM init
> every now and then with the following cryptic error message:
> """
> pctl_start: Failed to init pctl channel 0
> """
> 
> When it fails, the current logic is implemented in such a way that the
> board enters an infinite while loop. This is not ideal for embedded
> systems that are not easily accessible and also an issue when having
> devices in a CI lab for example.
> 
> Therefore, let's simply panic if the DRAM fails to init. This was tested
> only on RK3399 Puma, similar changes may be required for other SoCs to
> properly propagate the errors.
> 
> While this is all but a work-around instead of fixing the DRAM init
> sequence, I believe it is important for resilience of devices in the
> field.
> 
> Marking this as RFC because:
> 1) panic()s for all Rockchip SoCs but only tested on RK3399
> 2) unsure about error return values (ENODEV and the likes), not sure
>     what would be better than that though :/
> 
> Note that one can still hang() if they want by setting PANIC_HANG
> symbol.
> 

What do you think about this series?

I believe we should be able to merge everything but the panic() and fail 
DRAM init on pctl patches without changing the current behavior?

I could keep the panic() and fail DRAM init on pctl patches in my 
downstream fork if there's no interest but I think it makes sense to 
have them merged.

Cheers,
Quentin