[Skiboot] [PATCH] Skip OCCs for chip that has occ_functional set to false

[Stewart Smith]

Stewart Smith <stewart at linux.vnet.ibm.com> writes:

> Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com> writes:
>> On 09/03/2015 09:07 AM, Stewart Smith wrote:
>>> In some simulation environments, we simulate a system close to an
>>> ibm-fsp system but with a crucial difference: we don't simulate OCCs.
>>> This means that for a P8 (well, a simulated one) that looks like it's
>>> part of a ibm-fsp system, we'd wait around for about a minute to be
>>> asked to start OCCs and for the OCCs to start. Obviously, this would
>>> never happen and we'd hit the OCC initialization timeout (correctly)
>>> logging an error.
>>> 
>>> However, in this simulation environment, it isn't an error as the
>>> required information to work out it isn't an error is (at least now)
>>> provided in hdat under 'OCC Functional State'.
>>> 
>>> Previously, the ibm,occ-functional-state property was just passed
>>> through the device tree to the host through the XSCOM node and
>>> skiboot ignored it.
>>> 
>>> This patch takes note of occ-functional-state and skips waiting for
>>> OCCs on any chips that have been marked as having non functional
>>> OCC.
>>> 
>>
>> In non-simulation environment,
>>
>> 1)Can any of the chips be marked as having non-functional OCC?
>>
>> 2)Can the processor chips be marked with different occ-functional-state?
>
> I'd love to know, but getting documentation on what this "occ functional
> state" seems much harder than it should be.
>
> The (internal) bug for this is mostly me asking what that field means
> and if it does in fact mean this.
>
> So far, the complete documentation we have is:
> "OCC Functional State (4 bytes)"
> "if zero, OCC not functional"
>
> and that's it... :/

I managed to get documentation and confirmation on it. Well... if
"documentation" = email from FSP engineer :)

So, i'm merging this patch in to make one specific (seemingly rarely
run) test environment a bit happier.