[Skiboot] [RFC] occ: Add support for OCC inband sensors
Cédric Le Goater
clg at kaod.org
Sat Mar 11 02:39:42 AEDT 2017
On 03/10/2017 08:20 AM, Shilpasri G Bhat wrote:
> 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 :
>>>> 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.
More information about the Skiboot