[Skiboot] [PATCH v2] phb4: Reset FIR/NFIR registers before PHB4 probe

[Stewart Smith]

Vaibhav Jain <vaibhav at linux.vnet.ibm.com> writes:
> The function phb4_probe_stack() resets "ETU Reset Register" to
> unfreeze the PHB before it performs mmio access on the PHB. However in
> case the FIR/NFIR registers are set while entering this function,
> the reset of "ETU Reset Register" wont unfreeze the PHB and it will
> remain fenced. This leads to failure during initial CRESET of the PHB
> as mmio access is still not enabled and an error message of the form
> below is logged:
>
>  PHB#0000[0:0]: Initializing PHB4...
>  PHB#0000[0:0]: Default system config: 0xffffffffffffffff
>  PHB#0000[0:0]: New system config    : 0xffffffffffffffff
>  PHB#0000[0:0]: Initial PHB CRESET is 0xffffffffffffffff
>  PHB#0000[0:0]: Waiting for DLP PG reset to complete...
>  <snip>
>  PHB#0000[0:0]: Timeout waiting for DLP PG reset !
>  PHB#0000[0:0]: Initialization failed
>
> This is especially seen happening during the MPIPL flow where SBE
> would quiesces and fence the PHB so that it doesn't stomp on the main
> memory. However when skiboot enters phb4_probe_stack() after MPIPL,
> the FIR/NFIR registers are set forcing PHB to re-enter fence after ETU
> reset is done.
>
> So to fix this issue the patch introduces new xscom writes to
> phb4_probe_stack() to reset the FIR/NFIR registers before performing
> ETU reset to enable mmio access to the PHB.
>
> Signed-off-by: Vaibhav Jain <vaibhav at linux.vnet.ibm.com>
> Tested-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
> ---
> Change-log:
>
> v2	-> Removed the dump of FIR/NFIR register before they are
> 	   reset.
>
> Resend 	-> Replaced xscom_read to FIR/NFIR registers with xscom_write.
> ---
>  hw/phb4.c | 4 ++++
>  1 file changed, 4 insertions(+)

Merged to master as of 1d7067e7a3f5fa7823236616caaf94e4809cc5fb
-- 
Stewart Smith
OPAL Architect, IBM.