[Skiboot] [PATCH v11 11/11] skiboot: Add documentation for IMC opal call

[Stewart Smith]

Madhavan Srinivasan <maddy at linux.vnet.ibm.com> writes:
>> What's the behaviour over kexec? Calling _INIT multiple times is
>> harmless as long as no counters of that class are started?
>
> Yes that is true. Also we did test kexec path multiple times
> for all this three cases
> 1 )IMC kernel -> distro kernel (without IMC patchset)
> 2) distro kernel (without IMC Patchset) -> IMC kernel
> 3) IMC kernel -> IMC kernel.

Please document the intended behaviour of the OPAL API though. This will
help us in the future if/when we extend IMC to support other things.

>> This would imply that in a kdump scenario, the kdump kernel should *not*
>> init IMC counters, but in a normal kexec/boot scenario, it's safe to.
>
> Yes. In the kernel patchset, we do have a check for the kdump
> kernel before create IMC devices (in device probe function).
> So that we dont _INIT in the kdump scenerio

Okay, please document what the kernel is meant to do in the OPAL docs.

>>> +OPAL_IMC_COUNTERS_STOP
>>> +===========================
>>> +OPAL call interface for stoping In-Memory
>>> +Collection counters for a specified domain (NEST/CORE).
>>> +
>>> +Parameters
>>> +----------
>>> +``uint32_t type``
>>> + This parameter specifies the imc counter domain.
>>> + The value can be either 'OPAL_IMC_COUNTERS_NEST'
>>> + or 'OPAL_IMC_COUNTERS_CORE'
>>> +
>>> +Returns
>>> +-------
>>> +OPAL_PARAMETER - In case of  Unsupported ``type``
>>> +OPAL_HARDWARE  - If xscom_write fails.
>>> +OPAL_SUCCESS   - On successful execution of the operation for the given ``type``.
>> Will stop succeed if there has not been a corresponding START?
>
> Currently we dont check whether the counters are started,
> so STOP will succeed event there has not been a
> corresponding START

Is that intended design though? Must any future counters support that?

-- 
Stewart Smith
OPAL Architect, IBM.