PMBus support in Linux

PMBus support in Linux

[Guenter Roeck]

Hi,

does anyone know if there is an effort to add infrastructure for PMBus
support (or support for specific PMBus devices) to Linux ?

I'll have to write a driver for a couple of PMBus chips (LTC2978 and
BMR453), and it would help to know if there is a starting point.

Thanks,
Guenter

Re: PMBus support in Linux

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]


CCing lm-sensors and David...

On Fri, May 28, 2010 at 09:16:31AM -0700, Guenter Roeck wrote:

> does anyone know if there is an effort to add infrastructure for PMBus
> support (or support for specific PMBus devices) to Linux ?

I found this:

http://lists.lm-sensors.org/pipermail/lm-sensors/2008-April/022969.html

Hmm, sitting ontop of SMBus, it makes perfect sense to use i2c-dev (David knows
what he is doing, of course ;)). But having no repo and all, it is hard to
maintain this utility. Is there any chance to pick it up in the kernel-tree?
tools/i2c/ or such? Hmm, it's GPL v3...

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PMBus support in Linux

[Guenter Roeck]

On Fri, May 28, 2010 at 10:34:01PM -0400, Wolfram Sang wrote:
> 
> CCing lm-sensors and David...
> 
> On Fri, May 28, 2010 at 09:16:31AM -0700, Guenter Roeck wrote:
> 
> > does anyone know if there is an effort to add infrastructure for PMBus
> > support (or support for specific PMBus devices) to Linux ?
> 
> I found this:
> 
> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-April/022969.html
> 
I found that as well, but that was about it. Not sure if I want to use it
as a starting point or even for reference since it is gplv3.
Probably useful for debugging, though.

> Hmm, sitting ontop of SMBus, it makes perfect sense to use i2c-dev (David knows
> what he is doing, of course ;)). But having no repo and all, it is hard to
> maintain this utility. Is there any chance to pick it up in the kernel-tree?
> tools/i2c/ or such? Hmm, it's GPL v3...
> 
Maybe there is now more interest in kernel driver support - looks like there
are several PMBus chips available today.

If there is no activity yet, question is if I should write individual drivers or 
if I should define a PMBus infrastructure on top of i2c/smbus first.
Any thoughts on which approach would be more likely to be accepted into the kernel ?

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: PMBus support in Linux

[Jean Delvare]

On Sat, 29 May 2010 04:34:01 +0200, Wolfram Sang wrote:
> 
> CCing lm-sensors and David...
> 
> On Fri, May 28, 2010 at 09:16:31AM -0700, Guenter Roeck wrote:
> 
> > does anyone know if there is an effort to add infrastructure for PMBus
> > support (or support for specific PMBus devices) to Linux ?
> 
> I found this:
> 
> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-April/022969.html
> 
> Hmm, sitting ontop of SMBus, it makes perfect sense to use i2c-dev (David knows
> what he is doing, of course ;)). But having no repo and all, it is hard to
> maintain this utility. Is there any chance to pick it up in the kernel-tree?
> tools/i2c/ or such? Hmm, it's GPL v3...

There is an i2c-tools package for user-space utilities, I see no point
to add such code to the kernel tree.

-- 
Jean Delvare

Re: PMBus support in Linux

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]


> There is an i2c-tools package for user-space utilities, I see no point
> to add such code to the kernel tree.

Obviously correct. Are there any problems picking up GPL3 code?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PMBus support in Linux

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

> If there is no activity yet, question is if I should write individual drivers or 
> if I should define a PMBus infrastructure on top of i2c/smbus first.
> Any thoughts on which approach would be more likely to be accepted into the kernel ?

Did I get this correct: The plan is to support PMBus-devices and let them
report their data in a hwmon-compatible-way?

(If so, did you already check how well PMBus data maps to the
hwmon-sysfs-interface?)

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PMBus support in Linux

[Jean Delvare]

On Sat, 29 May 2010 10:16:33 +0200, Wolfram Sang wrote:
> 
> > There is an i2c-tools package for user-space utilities, I see no point
> > to add such code to the kernel tree.
> 
> Obviously correct. Are there any problems picking up GPL3 code?

No problem, we already have a mix of licenses in this package, and I
don't mind adding one more.

-- 
Jean Delvare

Re: PMBus support in Linux

[Guenter Roeck]

On Sat, May 29, 2010 at 04:53:01AM -0400, Wolfram Sang wrote:
> > If there is no activity yet, question is if I should write individual drivers or 
> > if I should define a PMBus infrastructure on top of i2c/smbus first.
> > Any thoughts on which approach would be more likely to be accepted into the kernel ?
> 
> Did I get this correct: The plan is to support PMBus-devices and let them
> report their data in a hwmon-compatible-way?
> 
Yes.

> (If so, did you already check how well PMBus data maps to the
> hwmon-sysfs-interface?)
> 
Yes. PMBus uses i2c as transport, so it can use the existing i2c/smbus infrastructure. 
Data reported is voltage, temperature, current, power, and fan data as available
from the individual chip. Chips support a chip dependent number of channels.
Values reported are typically in the form of X = Y * 2^N, ie there is a mantissa
and an exponent.

So I would say it maps pretty well; I don't really see a substantial difference
to other HW monitoring chips in that respect. Key difference may be that PMBus devices 
typically also have a control component, but I don't have plans to implement that,
at least not for now.

Guenter

Re: PMBus support in Linux

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]


> Yes. PMBus uses i2c as transport, so it can use the existing i2c/smbus infrastructure. 
> Data reported is voltage, temperature, current, power, and fan data as available
> from the individual chip. Chips support a chip dependent number of channels.
> Values reported are typically in the form of X = Y * 2^N, ie there is a mantissa
> and an exponent.
> 
> So I would say it maps pretty well; I don't really see a substantial difference
> to other HW monitoring chips in that respect. Key difference may be that PMBus devices 
> typically also have a control component, but I don't have plans to implement that,
> at least not for now.

I just had a glimpse, but I came to a similar conclusion. As I further
understood, PMBus devices support a standard range of commands with the
possibility of manufacturer extenstions.

So, the approach I see (unless I miss something) would be writing an
hwmon-I2C-driver named pmbus-devices.c or so which covers the generic
functionality and provides some hooks for manufacturer extensions, if those are
necessary? (Altough I'd hope a number of devices would be covered by the
generic driver) Makes sense?

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PMBus support in Linux

[Guenter Roeck]

On Sat, May 29, 2010 at 11:47:41AM -0400, Wolfram Sang wrote:
> 
> > Yes. PMBus uses i2c as transport, so it can use the existing i2c/smbus infrastructure. 
> > Data reported is voltage, temperature, current, power, and fan data as available
> > from the individual chip. Chips support a chip dependent number of channels.
> > Values reported are typically in the form of X = Y * 2^N, ie there is a mantissa
> > and an exponent.
> > 
> > So I would say it maps pretty well; I don't really see a substantial difference
> > to other HW monitoring chips in that respect. Key difference may be that PMBus devices 
> > typically also have a control component, but I don't have plans to implement that,
> > at least not for now.
> 
> I just had a glimpse, but I came to a similar conclusion. As I further
> understood, PMBus devices support a standard range of commands with the
> possibility of manufacturer extenstions.
> 
> So, the approach I see (unless I miss something) would be writing an
> hwmon-I2C-driver named pmbus-devices.c or so which covers the generic
> functionality and provides some hooks for manufacturer extensions, if those are
> necessary? (Altough I'd hope a number of devices would be covered by the
> generic driver) Makes sense?
> 
That would be one option. It would require either a register() API call, or a table
of supported chips, or a combination of both, to identify how many channels
(or pages, in PMBus terminology) per chip are supported and to identify supported
objects/registers.

The other option would be to write separate drivers (one for each chip) and not provide
a common infrastructure. Not sure if that is a good idea, though; I personally prefer
the first option.

Thanks,
Guenter

Re: PMBus support in Linux

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

> > So, the approach I see (unless I miss something) would be writing an
> > hwmon-I2C-driver named pmbus-devices.c or so which covers the generic
> > functionality and provides some hooks for manufacturer extensions, if those are
> > necessary? (Altough I'd hope a number of devices would be covered by the
> > generic driver) Makes sense?
> > 
> That would be one option. It would require either a register() API call, or a table
> of supported chips, or a combination of both, to identify how many channels
> (or pages, in PMBus terminology) per chip are supported and to identify supported
> objects/registers.

I am missing the details here, i.e. what data is needed to describe a device
and is the data static or can it be retrieved/updated at runtime. A decision
between tables[] or register() or both depends probably on that.

> The other option would be to write separate drivers (one for each chip) and not provide
> a common infrastructure. Not sure if that is a good idea, though; I personally prefer
> the first option.

Same here. It will be a lot easier to maintain the code dealing with generic
PMBus commands if it is centralized.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: PMBus support in Linux

[Guenter Roeck]

On Sun, May 30, 2010 at 12:15:07AM -0400, Wolfram Sang wrote:
> > > So, the approach I see (unless I miss something) would be writing an
> > > hwmon-I2C-driver named pmbus-devices.c or so which covers the generic
> > > functionality and provides some hooks for manufacturer extensions, if those are
> > > necessary? (Altough I'd hope a number of devices would be covered by the
> > > generic driver) Makes sense?
> > > 
> > That would be one option. It would require either a register() API call, or a table
> > of supported chips, or a combination of both, to identify how many channels
> > (or pages, in PMBus terminology) per chip are supported and to identify supported
> > objects/registers.
> 
> I am missing the details here, i.e. what data is needed to describe a device
> and is the data static or can it be retrieved/updated at runtime. A decision
> between tables[] or register() or both depends probably on that.
> 
It _may_ be possible to detect the supported commands (ie sensors per page/phase)
reliably using the QUERY command, but I do not feel comfortable doing the same
to determine the number of pages and phases supported.

I'll have to see once I get my hands on actual HW what can be detected reliably 
and what has to be configured.

Guenter