[Skiboot] [RFC] occ: Add support for OCC inband sensors

[Cédric Le Goater]

On 03/10/2017 08:20 AM, Shilpasri G Bhat wrote:
> Hi,
> 
> On 03/10/2017 05:54 AM, Stewart Smith wrote:
>> Andrew Jeffery <andrew at aj.id.au> writes:
>>> On Thu, 2017-03-09 at 13:44 +0100, Cédric Le Goater wrote:
>>>> Hello Shilpasri,
>>>>
>>>> Thanks for the write up on the OCC sensors. Nice and detailed.
>>>>
>>>> On the overall design, I think this is exposing too much HW details 
>>>> to Linux. I am not sure Linux should even know about OCC or where
>>>> the sensors are coming from. Even if this is doable, I would not 
>>>> let the kernel loop on the OCC data to collect which sensors are
>>>> available. What is being done under :
>>>>
>>>> 	arch/powerpc/platforms/powernv/opal-occ-sensors.c
>>>>
>>>> in the Linux driver should be in the firmware IHMO. 
>>>>
>>>> skiboot should hide the gory details and expose in the device 
>>>> tree sensor nodes collected from the different available sources: 
>>>> FSP, BMC, OCC, DTS, etc. 
>>>>
>>>> There is a framework in place in skiboot for that, which may be, 
>>>> needs some tuning to add OCC support. But the good thing about it, 
>>>> is that the Linux driver comes for free in *all* Linux distros now.
>>>
>>> I spoke with Stewart a while back about how we should expose sensors to
>>> Linux and we reached the same conclusions as Cedric. Lets keep the OCC
>>> details contained in the firmware.
>>
>> Yep. OCC is merely an implementation detail.
>>
>> I'd argue that all sensors should be readable through the OPAL calls. As
>> an optimisation, we could add the ability for some opal sensors to be
>> read directly from an address by the kernel.
>>
>> But yeah, for these sensors, existing kernels should "just work" by
>> using the existing OPAL calls.
>>
> 
> Yes. I completely agree that the sensors should be exported in device tree. I
> will send out a patch for the same in the next iteration.
> 
> But there are couple of concerns which this patch is trying to address:
> 
> 1) If we end up exporting all sensors as device tree nodes then we will bloat
> the device tree with 450 sensors per OCC. And it will also increase the OPAL
> boot time.

Let's see how time it takes first and may be we can filter some of them.

> 
> 2) Apart from the min/max for each sensor OCC provides three different min/max
> which can be reset at runtime. I am not sure if it is a right way to create new
> nodes for each min/max per sensor.

I would say that the 'Latest sample' should be enough.

Thanks,

C.