PECI API?

[Tanous, Ed]

From: Rick Altherr [mailto:raltherr at google.com]
Sent: Monday, October 23, 2017 12:48 PM
To: Tanous, Ed <ed.tanous at intel.com>
Cc: David Müller (ELSOFT AG) <d.mueller at elsoft.ch>; OpenBMC <openbmc at lists.ozlabs.org>
Subject: Re: PECI API?



On Mon, Oct 23, 2017 at 12:39 PM, Tanous, Ed <ed.tanous at intel.com<mailto:ed.tanous at intel.com>> wrote:

“Rather than a PECI API, would it make any sense to define a an abstract concept API, where one implementation of it has a PECI backend?”

I don’t think so, but that’s partially why I asked about use cases.  PECI can be thought of a lot like SMBus, with some fancy protocol level features that make it easier to implement.  It’s a generic interface that can be used for any number of things, including temperature readings from processors and memory.  Our intention was to implement it as a device driver (/dev/peci), with (one or several) dbus daemons reading and pushing information to dbus using the existing openbmc interfaces (sensor, threshold, logging ect).  There was also talk of implementing it as a hwmon driver, but I think that discussion was deferred, given that the number of “sensors” needs to be determined at runtime, and that didn’t seem to fit in the hwmon model.  This work is ongoing, so I don’t have a timeframe on completion or its level of robustness, but if there’s interest, I can probably push the WIP to a branch or a repo somewhere.


hwmon has APIs for dynamically adding sensors at runtime.  For temps, volts, etc, I prefer an hwmon driver built atop a PECI subsystem.

[Ed]  I was personally unaware that hwmon itself had that capability.  We had previously implemented a dynamically generated device tree overlay that accomplished some of that for LM75 sensors.  I will point my developers at it.
“Is there a kernel subsystem for PECI defined upstream?  I'm not aware of a PECI device driver for Aspeed upstream.”
I don’t believe there is one defined upstream, but I believe the first revision of the driver code we are using was derived from the Aspeed SDK.

What happens when Nuvoton sends their driver?

[Ed] ….. we work to build a common interface that meets everyone’s needs, while abstracting the hardware interfaces into the kernel.  Part of the issue with PECI is there are some userspace constructs (retries, framing, timing, ect) that are a part of the PECI specification, but could be pushed to either hardware abstractions, or userspace code.  Where they get implemented (for platforms I’ve been a part of) has thusfar been a matter of preference on the part of the developer.  We likely should get together a group of interested parties and see if we can come up with an interface that works for everyone.  I have not yet worked with a Nuvoton platform, so I’m sure I have quite a bit to learn in that space.

-Ed



-----Original Message-----
From: openbmc [mailto:openbmc-bounces+ed.tanous<mailto:openbmc-bounces%2Bed.tanous>=intel.com at lists.ozlabs.org<mailto:intel.com at lists.ozlabs.org>] On Behalf Of Brad Bishop
Sent: Monday, October 23, 2017 12:17 PM
To: "David Müller (ELSOFT AG)" <d.mueller at elsoft.ch<mailto:d.mueller at elsoft.ch>>
Cc: OpenBMC <openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>>
Subject: Re: PECI API?





> On Oct 21, 2017, at 4:57 AM, David Müller (ELSOFT AG) <d.mueller at elsoft.ch<mailto:d.mueller at elsoft.ch>> wrote:

>

> Hello

>

> Is anyone working on an API definition for PECI?

>

>

> Dave



Full disclosure - the Wikipedia article is the extent of my background on PECI.



Rather than a PECI API, would it make any sense to define a an abstract concept API, where one implementation of it has a PECI backend?



My cursory glance at the Wikipedia article suggests PECI provides temperature readings (I’m sure it does much more) but the basic thought process I’ve outlined would allow control applications or metric gathering applications, etc to be re-used irrespective of where the data is coming from.



-brad


From: Rick Altherr [mailto:raltherr at google.com<mailto:raltherr at google.com>]
Sent: Monday, October 23, 2017 12:02 PM
To: Tanous, Ed <ed.tanous at intel.com<mailto:ed.tanous at intel.com>>
Cc: David Müller (ELSOFT AG) <d.mueller at elsoft.ch<mailto:d.mueller at elsoft.ch>>; OpenBMC <openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>>
Subject: Re: PECI API?

Is there a kernel subsystem for PECI defined upstream?  I'm not aware of a PECI device driver for Aspeed upstream.

On Mon, Oct 23, 2017 at 9:44 AM, Tanous, Ed <ed.tanous at intel.com<mailto:ed.tanous at intel.com>> wrote:
We had looked at building one, and had one prototyped for a simple read/write interface, but we were on the fence about whether such a low level control (PECI read/write) should be put on dbus at all for security reasons, especially when the drivers read/write API isn't that difficult to use.

What are you looking at doing with it?

-Ed

-----Original Message-----
From: openbmc [mailto:openbmc-bounces+ed.tanous<mailto:openbmc-bounces%2Bed.tanous>=intel.com at lists.ozlabs.org<mailto:intel.com at lists.ozlabs.org>] On Behalf Of David Müller (ELSOFT AG)
Sent: Saturday, October 21, 2017 1:57 AM
To: OpenBMC <openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>>
Subject: PECI API?

Hello

Is anyone working on an API definition for PECI?


Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171023/7c5495a0/attachment.html>