[Skiboot] [PATCH] occ: hbrt: Change the OCC reset order

[Shilpasri G Bhat]

Hi Stewart,

On 10/14/2015 11:47 AM, Stewart Smith wrote:
> Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com> writes:
>> Modify the OCC reset order such that master OCC is reset after the
>> slave OCCs are reset. In Tuleta/Alpine systems 'proc0' will always be
>> the master OCC, which has to be stopped last when FSP sends OCC_RESET
>> command to Opal.
> 
> Is this also true for all OpenPower machines?

In OpenPower machines, HTMGT manages OCC start/stop operations. So OCC reset in
OpenPower machines is not handled in opal.

> 
> What about for Venice and Naples (and other future chips)?

I am not completely sure about this. But OCC team has mentioned only Brazos can
have proc0 and proc1 as master. The patch does not handle this currently, only
proc0 will be marked as master for Venice chips. But I don't see any harm in
checking for proc1 as we already do it for DCM case.

> 
> (and why would we be asked to stop OCCs anyway I wonder... in what
> circumstances does this happen?)

There two places which I am aware of when OCC is asked to stop by FSP:
1) during IPL(observed in FW830)
2) during OCC recovery when OCC crashes

> 
> I'd *much* prefer us to have a way programatically to work this out
> rather than just assuming - it smells like a way to get this subtley
> incorrect on random future machines.

Yes agree. It would be better if FSP could send the chipID to reset. Then we
don't have to hardcode and can reset OCCs in the order FSP requests.
What do you suggest?

> 
> also, isn't for_each_chip() in chip-id order anyway? next_chip() (used
> by for_each_chip) does go in-order through the chips[] array which is
> referenced by chip id, so I wonder why the sort is needed.

I have sorted to avoid hard-coding chip-id check 'if(chip-id == 0 || chip-id ==1)'
Okay. If for_each_chip() is already sorted, then I can remove the sorting and
assign the master and slave chip arrays directly.

Thanks and Regards,
Shilpa