[Skiboot] [PATCH v2 5/5] occ : Add OPAL API opal_get_dynamic_update() to support runtime update

[Shilpasri G Bhat]

Hi,

On 06/09/2016 12:52 PM, Stewart Smith wrote:
> Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com> writes:
>> This patch adds a generic opal call to retrieve runtime updated
>> information. One such data is pstate table. OCC can provide new
>> frequencies to the host which needs to be parsed and passed to
>> linux for cpufreq to consume it. This call can be extended to
>> support retrieval of frequency throttle stats later in the future.
> 
> Why can't we handle these updates as simple runtime device tree updates?

We can use the runtime device tree update if skiboot device tree is already
updated. Which is not the case here, so we will need some opal hook to re-parse
the OCC-OPAL shared memory region.

[We can re-parse the pstate table after an OCC reset, but there is no
clean/straight way to know if the pstate table has changed in OPAL. And mostly
this runtime update (atleast in P8+) will be triggered by HTMGT, followed by an
OCC reset in MFG/characterization]

> 
> We also need a way to notify the host that changes have occured, right?

Yes. So the idea is to embed this opal_call in opal-prd driver/tool which will
be triggered on need basis.

[OR do this every time after an OCC RESET.]

> 
> Could we use this same infrastructure to (for p9 timeframe) not wait for
> OCC to start during boot, instead allowing us to start booting linux
> while the OCCs finish starting up?
> 

Ideally yes. In P9 we will get an interrupt from OCC on a run-time pstate table
change. But I am not sure if we get an interrupt during a IPL. Even if we dont
get the interrupt we can piggy back on the opal-poller to check if the OCCs are
up and the pstate table is ready. However I am not sure how we can load(or
reload) the cpufreq module once the OCCs are up (i.e, the pstate table is added
to kernel DT)?

Thanks and Regards,
Shilpa