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

[Russell Currey]

On Tue, 2018-04-03 at 06:27 +0530, Vaibhav Jain wrote:
> 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>

Reviewed-by: Russell Currey <ruscur at russell.cc>