Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
phb4: Reset FIR/NFIR registers before PHB4 probe
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@linux.vnet.ibm.com> Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Russell Currey <ruscur@russell.cc> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
- Loading branch information