* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
@ 2011-05-10 16:07 ` Guenter Roeck
2011-05-10 17:03 ` Jean Delvare
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Guenter Roeck @ 2011-05-10 16:07 UTC (permalink / raw)
To: lm-sensors
On Tue, 2011-05-10 at 10:46 -0400, Martin Hicks wrote:
> This is a new driver for the INA219 current and power monitor. This
> device does require manual configuration via sysfs files in order to
> provide the current and power information. By default it does provide
> voltage information for the monitored bus.
>
> Signed-off-by: Martin Hicks <mort@bork.org>
Please have a look into Documentation/hwmon/submitting-patches
(available in the latest kernel from kernel.org) and follow the
guidelines listed there.
One item to add to that list: Don't configure a chip using sysfs
entries. Use platform data.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
2011-05-10 16:07 ` Guenter Roeck
@ 2011-05-10 17:03 ` Jean Delvare
2011-05-10 20:38 ` Ira W. Snyder
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2011-05-10 17:03 UTC (permalink / raw)
To: lm-sensors
Hi Martin,
On Tue, 10 May 2011 10:46:07 -0400, Martin Hicks wrote:
> This is a new driver for the INA219 current and power monitor. This
> device does require manual configuration via sysfs files in order to
> provide the current and power information. By default it does provide
> voltage information for the monitored bus.
>
> Signed-off-by: Martin Hicks <mort@bork.org>
Ira Snyder (Cc'd) once submitted a driver for the INA209. It never got
reviewed due to lack of time and difficulties to make the driver fit in
the standard hwmon interface, but maybe you two can work together if
the parts are compatible enough.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
2011-05-10 16:07 ` Guenter Roeck
2011-05-10 17:03 ` Jean Delvare
@ 2011-05-10 20:38 ` Ira W. Snyder
2011-05-11 2:26 ` Guenter Roeck
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Ira W. Snyder @ 2011-05-10 20:38 UTC (permalink / raw)
To: lm-sensors
On Tue, May 10, 2011 at 07:03:08PM +0200, Jean Delvare wrote:
> Hi Martin,
>
> On Tue, 10 May 2011 10:46:07 -0400, Martin Hicks wrote:
> > This is a new driver for the INA219 current and power monitor. This
> > device does require manual configuration via sysfs files in order to
> > provide the current and power information. By default it does provide
> > voltage information for the monitored bus.
> >
> > Signed-off-by: Martin Hicks <mort@bork.org>
>
> Ira Snyder (Cc'd) once submitted a driver for the INA209. It never got
> reviewed due to lack of time and difficulties to make the driver fit in
> the standard hwmon interface, but maybe you two can work together if
> the parts are compatible enough.
>
Hi Jean, Martin,
I took a quick look at the driver, and they seem fairly compatible. I
did not look at the datasheet.
I've been maintaining my own port of the ina209 driver. Now that the
"in*_lcrit" interfaces are added to the sysfs-interface, we only have
two disagreements:
1) shunt voltage is reported in uV instead of mV
This avoids losing half of the precision supported by the chip. This
makes a big difference for my application: I need it. IMHO, the
sysfs-interface was short sighted. We'll see more chips in the future
that are sensitive enough to report in uV.
I'm sure this is why the power* sysfs-interface is exported in uW
(microwatt). Eventually, devices will be sensitive enough to provide
data with this very fine sensitivity.
2) current calculation is not handled on-chip, it is handled by
libsensors
This was done to sidestep the "configuration register" setup which is
needed for the chip. The value of this register must be computed using
the datasheet and your specific sense resistor value in your specific
circuit. By computing current in userspace using the sense voltage, we
sidestep the issue completely.
Thanks,
Ira
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (2 preceding siblings ...)
2011-05-10 20:38 ` Ira W. Snyder
@ 2011-05-11 2:26 ` Guenter Roeck
2011-05-11 12:39 ` Jean Delvare
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Guenter Roeck @ 2011-05-11 2:26 UTC (permalink / raw)
To: lm-sensors
On Tue, May 10, 2011 at 04:38:44PM -0400, Ira W. Snyder wrote:
> On Tue, May 10, 2011 at 07:03:08PM +0200, Jean Delvare wrote:
> > Hi Martin,
> >
> > On Tue, 10 May 2011 10:46:07 -0400, Martin Hicks wrote:
> > > This is a new driver for the INA219 current and power monitor. This
> > > device does require manual configuration via sysfs files in order to
> > > provide the current and power information. By default it does provide
> > > voltage information for the monitored bus.
> > >
> > > Signed-off-by: Martin Hicks <mort@bork.org>
> >
> > Ira Snyder (Cc'd) once submitted a driver for the INA209. It never got
> > reviewed due to lack of time and difficulties to make the driver fit in
> > the standard hwmon interface, but maybe you two can work together if
> > the parts are compatible enough.
> >
>
> Hi Jean, Martin,
>
Hi all,
turns out Paul submitted a driver for INA209 as well, which pretty much
just exported register values via sysfs:
http://www.mail-archive.com/i2c@lm-sensors.org/msg00342.html
> I took a quick look at the driver, and they seem fairly compatible. I
> did not look at the datasheet.
>
Looking through the datasheets, the INA209 has some 22 registers,
while the INA219 only has 6 registers. Register numbers are different too.
That doesn't look very compatible to me. Am I missing something ?
> I've been maintaining my own port of the ina209 driver. Now that the
> "in*_lcrit" interfaces are added to the sysfs-interface, we only have
> two disagreements:
>
> 1) shunt voltage is reported in uV instead of mV
>
> This avoids losing half of the precision supported by the chip. This
> makes a big difference for my application: I need it. IMHO, the
> sysfs-interface was short sighted. We'll see more chips in the future
> that are sensitive enough to report in uV.
>
mV seems to be pretty accurate for voltage measurements.
The shunt voltage is really just a reflection of the voltage across
the current shunt resistor and reflects a current, not a voltage.
Sure, chips can sense voltages in the uV range, but that is typically
not used for voltage but for current measurements. With a 0.001 Ohm
shunt resistor, 1uV translates to 1mA. Reporting that "voltage" in mA
makes, in my opinion, more sense than reporting it in uV and expecting
a common library to perform a translation of a reported voltage into mA.
Having said that, Jean has a support ticket open to implement such a conversion:
http://www.lm-sensors.org/ticket/2258
If he ever gets to it, I suspect we will have to address the uV issue,
since mV are definitely insufficient for reporting shunt resistor voltages.
> I'm sure this is why the power* sysfs-interface is exported in uW
> (microwatt). Eventually, devices will be sensitive enough to provide
> data with this very fine sensitivity.
>
I don't know for sure, but I suspect it is simply because mV * mA = uW.
> 2) current calculation is not handled on-chip, it is handled by
> libsensors
>
> This was done to sidestep the "configuration register" setup which is
> needed for the chip. The value of this register must be computed using
> the datasheet and your specific sense resistor value in your specific
> circuit. By computing current in userspace using the sense voltage, we
> sidestep the issue completely.
>
The chips provide current as
Current Register = Shunt Register * Calibration Register / 4096
so the question for me would be why it would be necessary report the raw value
of the shunt resistor voltage in the first place and not just stick with in0
(in mV) and curr1 (in mA). If you want to report the "raw" value, you could
report it in mA as suggested above (ie assume a 0.001 Ohm shunt resistor).
Part of the problem here is how to provide configuration data.
The overall expectation for chip configuration is that it should be handled
in the BIOS, ie before Linux starts. For applications where this is
not the case, would be to define platform data to provide the necessary
information. Another alternative would be to use OF (see the ads1015 driver
for an example). Using sysfs attributes for this purpose is not a good idea.
Jean had some reservations about assuming a 0.001 Ohm shunt resistor. See
http://article.gmane.org/gmane.linux.documentation/2744/
Providing platform data to configure the chips would definitely be
a better option.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (3 preceding siblings ...)
2011-05-11 2:26 ` Guenter Roeck
@ 2011-05-11 12:39 ` Jean Delvare
2011-05-11 14:14 ` Guenter Roeck
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2011-05-11 12:39 UTC (permalink / raw)
To: lm-sensors
Hi Guenter, Ira,
On Tue, 10 May 2011 19:26:47 -0700, Guenter Roeck wrote:
> On Tue, May 10, 2011 at 04:38:44PM -0400, Ira W. Snyder wrote:
> > I've been maintaining my own port of the ina209 driver. Now that the
> > "in*_lcrit" interfaces are added to the sysfs-interface, we only have
> > two disagreements:
> >
> > 1) shunt voltage is reported in uV instead of mV
> >
> > This avoids losing half of the precision supported by the chip. This
> > makes a big difference for my application: I need it. IMHO, the
> > sysfs-interface was short sighted.
I'm fairly certain I already explained months ago, but...
The sysfs interface was originally designed in 2005. Back then, the
lowest monitored system voltage was 3.3V, with memory voltage at 1.8V
(DDR2) and CPU core voltage in the 1.0-1.5V. Most monitoring chips were
using ADCs with a resolution of 16 mV. Using 1 mV as the base unit
seemed totally reasonable. As a matter of fact, we now see ADCs with
resolution 12 mV or 8 mV, and our 1 mV unit is still totally fine.
Your problem is that you are not monitoring a voltage. You are
monitoring a current, so requirements are totally different. And it's
not always possible to anticipate future requirements. Current
measurement was totally out of the scope of hardware monitoring
initially... And I would claim it still is, BTW. Probably the IIO
subsystem would be better suited at the need.
> > We'll see more chips in the future
> > that are sensitive enough to report in uV.
>
> mV seems to be pretty accurate for voltage measurements.
> The shunt voltage is really just a reflection of the voltage across
> the current shunt resistor and reflects a current, not a voltage.
>
> Sure, chips can sense voltages in the uV range, but that is typically
> not used for voltage but for current measurements. With a 0.001 Ohm
> shunt resistor, 1uV translates to 1mA. Reporting that "voltage" in mA
> makes, in my opinion, more sense than reporting it in uV and expecting
> a common library to perform a translation of a reported voltage into mA.
>
> Having said that, Jean has a support ticket open to implement such a conversion:
> http://www.lm-sensors.org/ticket/2258
> If he ever gets to it, I suspect we will have to address the uV issue,
> since mV are definitely insufficient for reporting shunt resistor voltages.
Yes, I remember we discussed this lately, and I didn't have the time to
work on this so far, sorry.
I have nothing against extending the sysfs interface to support uV
voltages. But this must be done in a way which doesn't break current
installations. Arbitrarily reporting in uV instead of the standard mV
isn't an option, neither for the ina209 driver alone, nor for all
drivers.
One way to do it would be to invent a brand new set of attributes for
uV voltages. For example volt[0-*]_input, etc. This is straightforward
and won't break anything, and would be transparent for applications,
however this would incur a lot of redundancy in the sysfs interface
definition document and in libsensors. If done smartly, this may be
bearable. The user constraints would be: you need the latest version of
libsensors for ina219 support, otherwise the attributes in question
aren't visible at all.
Another way would be to create a dedicated attribute for hwmon drivers
to advertise whether they are reporting voltages in uV or mV. For
example, file "unit_in" would contain -6 when the chip reports voltages
in uV, -3 if the chip reports voltages in mV (which would be the
default for backwards compatibility.) This would require very little
work in the sysfs-interface document and in libsensors, and would be
transparent to applications. The user constraints would be: you need
the latest version of libsensors for ina219 support, otherwise the
attributes in question are improperly scaled. Whether this is better or
worse than the constraints of the first option can be discussed... It
has the problem that the incorrectness is silent, but the advantage
that it can be corrected in sensors.conf if known (with, again, the
problem that a future update of libsensors will require a fix of
sensors.conf.)
I don't have a strong opinion. I don't think the INA219 chip is popular
enough that the second option is problematic. But if we go that route,
we should implement the libsensors side immediately so that it starts
propagating to the user base.
Note, the second option would also have the benefit that we can switch
to nV or V or kV at any time if we need to support strange hardware
monitoring devices. I don't expect it, but I didn't expect that we'd
need uV either, so...
If we go for the second option, I presume we would do the same for
current and power. Just in case...
> > I'm sure this is why the power* sysfs-interface is exported in uW
> > (microwatt). Eventually, devices will be sensitive enough to provide
> > data with this very fine sensitivity.
>
> I don't know for sure, but I suspect it is simply because mV * mA = uW.
Yes, I think that was the reasoning behind it. And also a simple "play
it safe" decision, because the feature was new and we didn't really
know what to expect from devices (contrary to voltages in 2005 as we
had 7 years of experience behind us.)
But you know, maybe someday someone will need nW and yell at us because
we didn't anticipate it ;)
> > 2) current calculation is not handled on-chip, it is handled by
> > libsensors
> >
> > This was done to sidestep the "configuration register" setup which is
> > needed for the chip. The value of this register must be computed using
> > the datasheet and your specific sense resistor value in your specific
> > circuit. By computing current in userspace using the sense voltage, we
> > sidestep the issue completely.
>
> The chips provide current as
> Current Register = Shunt Register * Calibration Register / 4096
>
> so the question for me would be why it would be necessary report the raw value
> of the shunt resistor voltage in the first place and not just stick with in0
> (in mV) and curr1 (in mA). If you want to report the "raw" value, you could
> report it in mA as suggested above (ie assume a 0.001 Ohm shunt resistor).
>
> Part of the problem here is how to provide configuration data.
> The overall expectation for chip configuration is that it should be handled
> in the BIOS, ie before Linux starts. For applications where this is
> not the case, would be to define platform data to provide the necessary
> information. Another alternative would be to use OF (see the ads1015 driver
> for an example). Using sysfs attributes for this purpose is not a good idea.
+1
> Jean had some reservations about assuming a 0.001 Ohm shunt resistor. See
> http://article.gmane.org/gmane.linux.documentation/2744/
> Providing platform data to configure the chips would definitely be
> a better option.
Well well... If it makes everyone's life easier, I would be happy to
(let you) document the 0.001 Ohm rule in D/h/sysfs-interface and
possibly sensors.conf.5.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (4 preceding siblings ...)
2011-05-11 12:39 ` Jean Delvare
@ 2011-05-11 14:14 ` Guenter Roeck
2011-05-11 14:47 ` Martin Hicks
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Guenter Roeck @ 2011-05-11 14:14 UTC (permalink / raw)
To: lm-sensors
On Wed, May 11, 2011 at 08:39:12AM -0400, Jean Delvare wrote:
> Hi Guenter, Ira,
>
> On Tue, 10 May 2011 19:26:47 -0700, Guenter Roeck wrote:
> > On Tue, May 10, 2011 at 04:38:44PM -0400, Ira W. Snyder wrote:
> > > I've been maintaining my own port of the ina209 driver. Now that the
> > > "in*_lcrit" interfaces are added to the sysfs-interface, we only have
> > > two disagreements:
> > >
> > > 1) shunt voltage is reported in uV instead of mV
> > >
> > > This avoids losing half of the precision supported by the chip. This
> > > makes a big difference for my application: I need it. IMHO, the
> > > sysfs-interface was short sighted.
>
> I'm fairly certain I already explained months ago, but...
>
> The sysfs interface was originally designed in 2005. Back then, the
> lowest monitored system voltage was 3.3V, with memory voltage at 1.8V
> (DDR2) and CPU core voltage in the 1.0-1.5V. Most monitoring chips were
> using ADCs with a resolution of 16 mV. Using 1 mV as the base unit
> seemed totally reasonable. As a matter of fact, we now see ADCs with
> resolution 12 mV or 8 mV, and our 1 mV unit is still totally fine.
>
> Your problem is that you are not monitoring a voltage. You are
> monitoring a current, so requirements are totally different. And it's
> not always possible to anticipate future requirements. Current
> measurement was totally out of the scope of hardware monitoring
> initially... And I would claim it still is, BTW. Probably the IIO
> subsystem would be better suited at the need.
>
I disagree here. Current measurement is critical to detect over-current
conditions. This may indicate a short or some other problem, and require
an immediate system shutdown to prevent (further) damage to the HW - especially
to the voltage converters.
> > > We'll see more chips in the future
> > > that are sensitive enough to report in uV.
> >
> > mV seems to be pretty accurate for voltage measurements.
> > The shunt voltage is really just a reflection of the voltage across
> > the current shunt resistor and reflects a current, not a voltage.
> >
> > Sure, chips can sense voltages in the uV range, but that is typically
> > not used for voltage but for current measurements. With a 0.001 Ohm
> > shunt resistor, 1uV translates to 1mA. Reporting that "voltage" in mA
> > makes, in my opinion, more sense than reporting it in uV and expecting
> > a common library to perform a translation of a reported voltage into mA.
> >
> > Having said that, Jean has a support ticket open to implement such a conversion:
> > http://www.lm-sensors.org/ticket/2258
> > If he ever gets to it, I suspect we will have to address the uV issue,
> > since mV are definitely insufficient for reporting shunt resistor voltages.
>
> Yes, I remember we discussed this lately, and I didn't have the time to
> work on this so far, sorry.
>
No need to be sorry. I don't even know if it is a good idea - definitely
not for cases like here, where it is well known that the measured object
reflects a current.
> I have nothing against extending the sysfs interface to support uV
> voltages. But this must be done in a way which doesn't break current
> installations. Arbitrarily reporting in uV instead of the standard mV
> isn't an option, neither for the ina209 driver alone, nor for all
> drivers.
>
> One way to do it would be to invent a brand new set of attributes for
> uV voltages. For example volt[0-*]_input, etc. This is straightforward
> and won't break anything, and would be transparent for applications,
> however this would incur a lot of redundancy in the sysfs interface
> definition document and in libsensors. If done smartly, this may be
> bearable. The user constraints would be: you need the latest version of
> libsensors for ina219 support, otherwise the attributes in question
> aren't visible at all.
>
> Another way would be to create a dedicated attribute for hwmon drivers
> to advertise whether they are reporting voltages in uV or mV. For
> example, file "unit_in" would contain -6 when the chip reports voltages
> in uV, -3 if the chip reports voltages in mV (which would be the
> default for backwards compatibility.) This would require very little
> work in the sysfs-interface document and in libsensors, and would be
> transparent to applications. The user constraints would be: you need
> the latest version of libsensors for ina219 support, otherwise the
> attributes in question are improperly scaled. Whether this is better or
> worse than the constraints of the first option can be discussed... It
> has the problem that the incorrectness is silent, but the advantage
> that it can be corrected in sensors.conf if known (with, again, the
> problem that a future update of libsensors will require a fix of
> sensors.conf.)
>
I would prefer something like inX_unit, ie per-sensor attributes.
But I don't have a strong opinion about it either.
> I don't have a strong opinion. I don't think the INA219 chip is popular
> enough that the second option is problematic. But if we go that route,
> we should implement the libsensors side immediately so that it starts
> propagating to the user base.
>
> Note, the second option would also have the benefit that we can switch
> to nV or V or kV at any time if we need to support strange hardware
> monitoring devices. I don't expect it, but I didn't expect that we'd
> need uV either, so...
>
I am still not sure if we need it now. As we both noticed, what is
really measured here is current, not voltage.
> If we go for the second option, I presume we would do the same for
> current and power. Just in case...
>
> > > I'm sure this is why the power* sysfs-interface is exported in uW
> > > (microwatt). Eventually, devices will be sensitive enough to provide
> > > data with this very fine sensitivity.
> >
> > I don't know for sure, but I suspect it is simply because mV * mA = uW.
>
> Yes, I think that was the reasoning behind it. And also a simple "play
> it safe" decision, because the feature was new and we didn't really
> know what to expect from devices (contrary to voltages in 2005 as we
> had 7 years of experience behind us.)
>
> But you know, maybe someday someone will need nW and yell at us because
> we didn't anticipate it ;)
>
... or because measuring uW is really ridiculous and we should have picked
mW instead for consistency ;).
> > > 2) current calculation is not handled on-chip, it is handled by
> > > libsensors
> > >
> > > This was done to sidestep the "configuration register" setup which is
> > > needed for the chip. The value of this register must be computed using
> > > the datasheet and your specific sense resistor value in your specific
> > > circuit. By computing current in userspace using the sense voltage, we
> > > sidestep the issue completely.
> >
> > The chips provide current as
> > Current Register = Shunt Register * Calibration Register / 4096
> >
> > so the question for me would be why it would be necessary report the raw value
> > of the shunt resistor voltage in the first place and not just stick with in0
> > (in mV) and curr1 (in mA). If you want to report the "raw" value, you could
> > report it in mA as suggested above (ie assume a 0.001 Ohm shunt resistor).
> >
> > Part of the problem here is how to provide configuration data.
> > The overall expectation for chip configuration is that it should be handled
> > in the BIOS, ie before Linux starts. For applications where this is
> > not the case, would be to define platform data to provide the necessary
> > information. Another alternative would be to use OF (see the ads1015 driver
> > for an example). Using sysfs attributes for this purpose is not a good idea.
>
> +1
>
> > Jean had some reservations about assuming a 0.001 Ohm shunt resistor. See
> > http://article.gmane.org/gmane.linux.documentation/2744/
> > Providing platform data to configure the chips would definitely be
> > a better option.
>
> Well well... If it makes everyone's life easier, I would be happy to
> (let you) document the 0.001 Ohm rule in D/h/sysfs-interface and
> possibly sensors.conf.5.
>
I would not call it a rule ... maybe a guideline. If there is something better
than "assume a 0.001 Ohm shunt resistor", I'd be all for it. It is just the best
idea I was able to up with ...
I still think that is better than reporting known current measurements as voltages
and expecting user space to convert it to currents - especially if it is as obvious
as it is here.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (5 preceding siblings ...)
2011-05-11 14:14 ` Guenter Roeck
@ 2011-05-11 14:47 ` Martin Hicks
2011-05-11 15:41 ` Ira W. Snyder
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Martin Hicks @ 2011-05-11 14:47 UTC (permalink / raw)
To: lm-sensors
On Tue, May 10, 2011 at 10:26 PM, Guenter Roeck
<guenter.roeck@ericsson.com> wrote:
>> I took a quick look at the driver, and they seem fairly compatible. I
>> did not look at the datasheet.
>>
> Looking through the datasheets, the INA209 has some 22 registers,
> while the INA219 only has 6 registers. Register numbers are different too.
> That doesn't look very compatible to me. Am I missing something ?
I took a quick look at the 209 datasheet and it looked to me like the
219 contains a subset of the 209 features. The calibration, shunt and
current LSB value would be the same, I think.
>
>> I've been maintaining my own port of the ina209 driver. Now that the
>> "in*_lcrit" interfaces are added to the sysfs-interface, we only have
>> two disagreements:
>>
>> 1) shunt voltage is reported in uV instead of mV
>>
>> This avoids losing half of the precision supported by the chip. This
>> makes a big difference for my application: I need it. IMHO, the
>> sysfs-interface was short sighted. We'll see more chips in the future
>> that are sensitive enough to report in uV.
>>
> mV seems to be pretty accurate for voltage measurements.
> The shunt voltage is really just a reflection of the voltage across
> the current shunt resistor and reflects a current, not a voltage.
>
> Sure, chips can sense voltages in the uV range, but that is typically
> not used for voltage but for current measurements. With a 0.001 Ohm
> shunt resistor, 1uV translates to 1mA. Reporting that "voltage" in mA
> makes, in my opinion, more sense than reporting it in uV and expecting
> a common library to perform a translation of a reported voltage into mA.
My driver uses the current LSB in uA, since values well below 1mA
would be common. This value is based on the resistor used and the
full-scale bus power range that can be found on the bus.
E.g., in our particular embedded board we have a 0.01Ohm on a 5V bus
with fairly small current. We use 250uA for the current LSB.
mh
--
Martin Hicks P.Eng. | mort@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (6 preceding siblings ...)
2011-05-11 14:47 ` Martin Hicks
@ 2011-05-11 15:41 ` Ira W. Snyder
2011-05-11 16:57 ` Jean Delvare
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Ira W. Snyder @ 2011-05-11 15:41 UTC (permalink / raw)
To: lm-sensors
On Tue, May 10, 2011 at 07:26:47PM -0700, Guenter Roeck wrote:
> On Tue, May 10, 2011 at 04:38:44PM -0400, Ira W. Snyder wrote:
> > On Tue, May 10, 2011 at 07:03:08PM +0200, Jean Delvare wrote:
> > > Hi Martin,
> > >
> > > On Tue, 10 May 2011 10:46:07 -0400, Martin Hicks wrote:
> > > > This is a new driver for the INA219 current and power monitor. This
> > > > device does require manual configuration via sysfs files in order to
> > > > provide the current and power information. By default it does provide
> > > > voltage information for the monitored bus.
> > > >
> > > > Signed-off-by: Martin Hicks <mort@bork.org>
> > >
> > > Ira Snyder (Cc'd) once submitted a driver for the INA209. It never got
> > > reviewed due to lack of time and difficulties to make the driver fit in
> > > the standard hwmon interface, but maybe you two can work together if
> > > the parts are compatible enough.
> > >
> >
> > Hi Jean, Martin,
> >
> Hi all,
>
> turns out Paul submitted a driver for INA209 as well, which pretty much
> just exported register values via sysfs:
>
> http://www.mail-archive.com/i2c@lm-sensors.org/msg00342.html
>
Yep. Hopefully you've seen my INA209 driver as well, which at least
tries to be compatible with the sysfs-interface where possible. If you
need another copy, I'll be happy to post it again.
> > I took a quick look at the driver, and they seem fairly compatible. I
> > did not look at the datasheet.
> >
> Looking through the datasheets, the INA209 has some 22 registers,
> while the INA219 only has 6 registers. Register numbers are different too.
> That doesn't look very compatible to me. Am I missing something ?
>
> > I've been maintaining my own port of the ina209 driver. Now that the
> > "in*_lcrit" interfaces are added to the sysfs-interface, we only have
> > two disagreements:
> >
> > 1) shunt voltage is reported in uV instead of mV
> >
> > This avoids losing half of the precision supported by the chip. This
> > makes a big difference for my application: I need it. IMHO, the
> > sysfs-interface was short sighted. We'll see more chips in the future
> > that are sensitive enough to report in uV.
> >
> mV seems to be pretty accurate for voltage measurements.
> The shunt voltage is really just a reflection of the voltage across
> the current shunt resistor and reflects a current, not a voltage.
>
> Sure, chips can sense voltages in the uV range, but that is typically
> not used for voltage but for current measurements. With a 0.001 Ohm
> shunt resistor, 1uV translates to 1mA. Reporting that "voltage" in mA
> makes, in my opinion, more sense than reporting it in uV and expecting
> a common library to perform a translation of a reported voltage into mA.
>
Yes, you are correct. I am returning the shunt resistor voltage (in uV)
in place of mA in the current value. I think you are probably right, I
don't need more resolution than mV in the true voltage monitor sysfs
files.
Also, (in reply to some email further down the thread), I understand
that the interface was designed in 2005, and that with the benefit of 7
years of experience, things might have been done differently. Perhaps I
shouldn't have said "short sighted", maybe "suboptimal interface choice
due to lack of experience" would have been better. I don't want to start
a fight. :)
> Having said that, Jean has a support ticket open to implement such a conversion:
> http://www.lm-sensors.org/ticket/2258
> If he ever gets to it, I suspect we will have to address the uV issue,
> since mV are definitely insufficient for reporting shunt resistor voltages.
>
> > I'm sure this is why the power* sysfs-interface is exported in uW
> > (microwatt). Eventually, devices will be sensitive enough to provide
> > data with this very fine sensitivity.
> >
> I don't know for sure, but I suspect it is simply because mV * mA = uW.
>
> > 2) current calculation is not handled on-chip, it is handled by
> > libsensors
> >
> > This was done to sidestep the "configuration register" setup which is
> > needed for the chip. The value of this register must be computed using
> > the datasheet and your specific sense resistor value in your specific
> > circuit. By computing current in userspace using the sense voltage, we
> > sidestep the issue completely.
> >
> The chips provide current as
> Current Register = Shunt Register * Calibration Register / 4096
>
There is a problem here. When you change the value of the Calibration
Register, you change the mA per bit (LSB) of the Current Register value.
I couldn't figure out how to determine the LSB of the Current Register
using the value in the Calibration Register.
Does that explanation make sense? How would you handle this situation?
FYI, here is a snippet from my sensors3.conf:
chip "ina209-i2c-0-45"
label in0 "FPGA 2.5V SENSE"
label in1 "FPGA 2.5V VOLTAGE"
label power1 "FPGA 2.5V POWER"
label curr1 "FPGA 2.5V CURRENT"
# shunt voltage reported in uV
compute in0 (@ / 1000), (@ * 1000)
# 32 mOhm sense resistor
compute power1 in1_input * curr1_input, in1_input * curr1_input
compute curr1 (@ / 32), (@ * 32)
chip "ina209-i2c-0-4a"
label in0 "FPGA 3.3V SENSE"
label in1 "FPGA 3.3V VOLTAGE"
label power1 "FPGA 3.3V POWER"
label curr1 "FPGA 3.3V CURRENT"
# shunt voltage reported in uV
compute in0 (@ / 1000), (@ * 1000)
# 220 mOhm sense resistor
compute power1 in1_input * curr1_input, in1_input * curr1_input
compute curr1 (@ / 220), (@ * 220)
> so the question for me would be why it would be necessary report the raw value
> of the shunt resistor voltage in the first place and not just stick with in0
> (in mV) and curr1 (in mA). If you want to report the "raw" value, you could
> report it in mA as suggested above (ie assume a 0.001 Ohm shunt resistor).
>
> Part of the problem here is how to provide configuration data.
> The overall expectation for chip configuration is that it should be handled
> in the BIOS, ie before Linux starts. For applications where this is
> not the case, would be to define platform data to provide the necessary
> information. Another alternative would be to use OF (see the ads1015 driver
> for an example). Using sysfs attributes for this purpose is not a good idea.
>
I am happy to configure the chip in my bootloader, before Linux starts.
Or to use OF, that is fine too.
The trouble is in the scaling of the "Current Register". As noted above,
the LSB changes depending on the value of the "Configuration Register".
I am not smart enough to figure out how to convert from "Configuration
Register value" to "LSB of Current Register".
Ira
> Jean had some reservations about assuming a 0.001 Ohm shunt resistor. See
> http://article.gmane.org/gmane.linux.documentation/2744/
> Providing platform data to configure the chips would definitely be
> a better option.
>
> Thanks,
> Guenter
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (7 preceding siblings ...)
2011-05-11 15:41 ` Ira W. Snyder
@ 2011-05-11 16:57 ` Jean Delvare
2011-05-11 18:40 ` Guenter Roeck
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2011-05-11 16:57 UTC (permalink / raw)
To: lm-sensors
Hi Guenter,
On Wed, 11 May 2011 07:14:20 -0700, Guenter Roeck wrote:
> On Wed, May 11, 2011 at 08:39:12AM -0400, Jean Delvare wrote:
> > I have nothing against extending the sysfs interface to support uV
> > voltages. But this must be done in a way which doesn't break current
> > installations. Arbitrarily reporting in uV instead of the standard mV
> > isn't an option, neither for the ina209 driver alone, nor for all
> > drivers.
> >
> > One way to do it would be to invent a brand new set of attributes for
> > uV voltages. For example volt[0-*]_input, etc. This is straightforward
> > and won't break anything, and would be transparent for applications,
> > however this would incur a lot of redundancy in the sysfs interface
> > definition document and in libsensors. If done smartly, this may be
> > bearable. The user constraints would be: you need the latest version of
> > libsensors for ina219 support, otherwise the attributes in question
> > aren't visible at all.
> >
> > Another way would be to create a dedicated attribute for hwmon drivers
> > to advertise whether they are reporting voltages in uV or mV. For
> > example, file "unit_in" would contain -6 when the chip reports voltages
> > in uV, -3 if the chip reports voltages in mV (which would be the
> > default for backwards compatibility.) This would require very little
> > work in the sysfs-interface document and in libsensors, and would be
> > transparent to applications. The user constraints would be: you need
> > the latest version of libsensors for ina219 support, otherwise the
> > attributes in question are improperly scaled. Whether this is better or
> > worse than the constraints of the first option can be discussed... It
> > has the problem that the incorrectness is silent, but the advantage
> > that it can be corrected in sensors.conf if known (with, again, the
> > problem that a future update of libsensors will require a fix of
> > sensors.conf.)
> >
> I would prefer something like inX_unit, ie per-sensor attributes.
> But I don't have a strong opinion about it either.
This was my initial idea as well, but then I thought of the cost both in
the kernel drivers and in libsensors if a device needs many such
attributes. As I don't expect the same device to be used to monitor
values in the kV range and values in the uV range at the same time,
per-channel scaling doesn't seem to be a required feature.
But well maybe I shouldn't worry about the cost and only look at the
cleanliness of the solution. In which case you are certainly right.
> > I don't have a strong opinion. I don't think the INA219 chip is popular
> > enough that the second option is problematic. But if we go that route,
> > we should implement the libsensors side immediately so that it starts
> > propagating to the user base.
> >
> > Note, the second option would also have the benefit that we can switch
> > to nV or V or kV at any time if we need to support strange hardware
> > monitoring devices. I don't expect it, but I didn't expect that we'd
> > need uV either, so...
>
> I am still not sure if we need it now. As we both noticed, what is
> really measured here is current, not voltage.
You're right. But as stated above, if we ever need it, then the earlier
libsensors supports it, the better, so users who need it don't have to
upgrade libsensors in a hurry.
Also, not being a big fan of the arbitrary 0.001 Ohm approach, I
welcome every step towards an alternative, even if this sole step would
be insufficient.
> > (...)
> > Well well... If it makes everyone's life easier, I would be happy to
> > (let you) document the 0.001 Ohm rule in D/h/sysfs-interface and
> > possibly sensors.conf.5.
> >
> I would not call it a rule ... maybe a guideline. If there is something better
> than "assume a 0.001 Ohm shunt resistor", I'd be all for it. It is just the best
> idea I was able to up with ...
My point is exactly that I would like it better (I might even call it
acceptable!) if it were a documented rule. If every driver does this,
and it is documented, then at least users won't be surprised.
> I still think that is better than reporting known current measurements as voltages
> and expecting user space to convert it to currents - especially if it is as obvious
> as it is here.
As long as we lack a proper way to deal with it in user-space, I can't
disagree.
Speaking of this, I just had an idea...
What if we create attribute curr[1-*]_resistor, which would hold the
value of the resistor used? Unit to be defined (milli-Ohm?) It would
either be initialized to 1 milli-Ohm as you've been using so far, or
left uninitialized (0) and the current value would only be returned by
the driver after user-space sets the value (through a set statement in
the configuration file.) Either way, this would let the user specify
the resistor value, as we do with the ones used for voltage input
scaling.
This would solve your concern (drivers can keep exporting curr[1-*]
attributes for current sensors) and mind (components external to the
monitoring device are specified by user-space).
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (8 preceding siblings ...)
2011-05-11 16:57 ` Jean Delvare
@ 2011-05-11 18:40 ` Guenter Roeck
2011-05-11 19:17 ` Jean Delvare
2011-05-11 23:36 ` Guenter Roeck
11 siblings, 0 replies; 13+ messages in thread
From: Guenter Roeck @ 2011-05-11 18:40 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
On Wed, 2011-05-11 at 12:57 -0400, Jean Delvare wrote:
> Hi Guenter,
>
> On Wed, 11 May 2011 07:14:20 -0700, Guenter Roeck wrote:
> > On Wed, May 11, 2011 at 08:39:12AM -0400, Jean Delvare wrote:
> > > I have nothing against extending the sysfs interface to support uV
> > > voltages. But this must be done in a way which doesn't break current
> > > installations. Arbitrarily reporting in uV instead of the standard mV
> > > isn't an option, neither for the ina209 driver alone, nor for all
> > > drivers.
> > >
> > > One way to do it would be to invent a brand new set of attributes for
> > > uV voltages. For example volt[0-*]_input, etc. This is straightforward
> > > and won't break anything, and would be transparent for applications,
> > > however this would incur a lot of redundancy in the sysfs interface
> > > definition document and in libsensors. If done smartly, this may be
> > > bearable. The user constraints would be: you need the latest version of
> > > libsensors for ina219 support, otherwise the attributes in question
> > > aren't visible at all.
> > >
> > > Another way would be to create a dedicated attribute for hwmon drivers
> > > to advertise whether they are reporting voltages in uV or mV. For
> > > example, file "unit_in" would contain -6 when the chip reports voltages
> > > in uV, -3 if the chip reports voltages in mV (which would be the
> > > default for backwards compatibility.) This would require very little
> > > work in the sysfs-interface document and in libsensors, and would be
> > > transparent to applications. The user constraints would be: you need
> > > the latest version of libsensors for ina219 support, otherwise the
> > > attributes in question are improperly scaled. Whether this is better or
> > > worse than the constraints of the first option can be discussed... It
> > > has the problem that the incorrectness is silent, but the advantage
> > > that it can be corrected in sensors.conf if known (with, again, the
> > > problem that a future update of libsensors will require a fix of
> > > sensors.conf.)
> > >
> > I would prefer something like inX_unit, ie per-sensor attributes.
> > But I don't have a strong opinion about it either.
>
> This was my initial idea as well, but then I thought of the cost both in
> the kernel drivers and in libsensors if a device needs many such
> attributes. As I don't expect the same device to be used to monitor
> values in the kV range and values in the uV range at the same time,
> per-channel scaling doesn't seem to be a required feature.
>
> But well maybe I shouldn't worry about the cost and only look at the
> cleanliness of the solution. In which case you are certainly right.
>
> > > I don't have a strong opinion. I don't think the INA219 chip is popular
> > > enough that the second option is problematic. But if we go that route,
> > > we should implement the libsensors side immediately so that it starts
> > > propagating to the user base.
> > >
> > > Note, the second option would also have the benefit that we can switch
> > > to nV or V or kV at any time if we need to support strange hardware
> > > monitoring devices. I don't expect it, but I didn't expect that we'd
> > > need uV either, so...
> >
> > I am still not sure if we need it now. As we both noticed, what is
> > really measured here is current, not voltage.
>
> You're right. But as stated above, if we ever need it, then the earlier
> libsensors supports it, the better, so users who need it don't have to
> upgrade libsensors in a hurry.
>
> Also, not being a big fan of the arbitrary 0.001 Ohm approach, I
> welcome every step towards an alternative, even if this sole step would
> be insufficient.
>
> > > (...)
> > > Well well... If it makes everyone's life easier, I would be happy to
> > > (let you) document the 0.001 Ohm rule in D/h/sysfs-interface and
> > > possibly sensors.conf.5.
> > >
> > I would not call it a rule ... maybe a guideline. If there is something better
> > than "assume a 0.001 Ohm shunt resistor", I'd be all for it. It is just the best
> > idea I was able to up with ...
>
> My point is exactly that I would like it better (I might even call it
> acceptable!) if it were a documented rule. If every driver does this,
> and it is documented, then at least users won't be surprised.
>
> > I still think that is better than reporting known current measurements as voltages
> > and expecting user space to convert it to currents - especially if it is as obvious
> > as it is here.
>
> As long as we lack a proper way to deal with it in user-space, I can't
> disagree.
>
> Speaking of this, I just had an idea...
>
> What if we create attribute curr[1-*]_resistor, which would hold the
> value of the resistor used? Unit to be defined (milli-Ohm?) It would
> either be initialized to 1 milli-Ohm as you've been using so far, or
> left uninitialized (0) and the current value would only be returned by
> the driver after user-space sets the value (through a set statement in
> the configuration file.) Either way, this would let the user specify
> the resistor value, as we do with the ones used for voltage input
> scaling.
>
Just as good or bad as defining a calibration factor, in my opinion.
Both convert uV readings to mA. If we go along that route, we might as
well do the same for voltages etc.
Milli-Ohm would be insufficient, since there are smaller resistors
available. Mouser offers a sense resistor with 0.000125 Ohms, so you
would have to use micro-Ohm.
> This would solve your concern (drivers can keep exporting curr[1-*]
> attributes for current sensors) and mind (components external to the
> monitoring device are specified by user-space).
>
Not really ... current sense resistors are similar to voltage divider
resistors, and external to the chip. Assumption for voltage divider
resistors is that the driver doesn't care and conversion is handled in
userland. Unfortunately, that does not work for currents, since the
driver has to make _some_ assumption how to convert uV as reported by
the ADC to mA.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (9 preceding siblings ...)
2011-05-11 18:40 ` Guenter Roeck
@ 2011-05-11 19:17 ` Jean Delvare
2011-05-11 23:36 ` Guenter Roeck
11 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2011-05-11 19:17 UTC (permalink / raw)
To: lm-sensors
On Wed, 11 May 2011 11:40:56 -0700, Guenter Roeck wrote:
> On Wed, 2011-05-11 at 12:57 -0400, Jean Delvare wrote:
> > What if we create attribute curr[1-*]_resistor, which would hold the
> > value of the resistor used? Unit to be defined (milli-Ohm?) It would
> > either be initialized to 1 milli-Ohm as you've been using so far, or
> > left uninitialized (0) and the current value would only be returned by
> > the driver after user-space sets the value (through a set statement in
> > the configuration file.) Either way, this would let the user specify
> > the resistor value, as we do with the ones used for voltage input
> > scaling.
>
> Just as good or bad as defining a calibration factor, in my opinion.
Calibration factor? You mean, the compute statement is 0.001 Ohm isn't
OK?
> Both convert uV readings to mA. If we go along that route, we might as
> well do the same for voltages etc.
Err, but we don't _need_ it for voltages, so why would we make things
needlessly complex?
> Milli-Ohm would be insufficient, since there are smaller resistors
> available. Mouser offers a sense resistor with 0.000125 Ohms, so you
> would have to use micro-Ohm.
Sure, fine with me. This will still allow values up to 4.2 kOhm on
32-bit systems, I presume this is sufficient.
> > This would solve your concern (drivers can keep exporting curr[1-*]
> > attributes for current sensors) and mind (components external to the
> > monitoring device are specified by user-space).
>
> Not really ... current sense resistors are similar to voltage divider
> resistors, and external to the chip. Assumption for voltage divider
> resistors is that the driver doesn't care and conversion is handled in
> userland. Unfortunately, that does not work for currents, since the
> driver has to make _some_ assumption how to convert uV as reported by
> the ADC to mA.
Unless we go for suboption b, i.e. the resistor value starts at 0 and
the driver doesn't report any current value until user-space has set
the value. Then the driver doesn't have to assume anything.
I agree that voltage and current cases aren't fundamentally different,
except for the fact that unscaled voltage values do exist, while every
current sensor will need a resistor.
What I would like is that we come up with a standard and documented way
to implement and use current sensors. It can be my proposal above, or
it can be your arbitrary 0.001 Ohm resistor. But I don't want to leave
the implementation up to every driver author. This is how lm-sensors 2
worked, and we definitely do NOT want anything like this ever again.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power
2011-05-10 14:46 [lm-sensors] [PATCH] hwmon: Driver for INA219 current and power Martin Hicks
` (10 preceding siblings ...)
2011-05-11 19:17 ` Jean Delvare
@ 2011-05-11 23:36 ` Guenter Roeck
11 siblings, 0 replies; 13+ messages in thread
From: Guenter Roeck @ 2011-05-11 23:36 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
On Wed, 2011-05-11 at 15:17 -0400, Jean Delvare wrote:
> On Wed, 11 May 2011 11:40:56 -0700, Guenter Roeck wrote:
> > On Wed, 2011-05-11 at 12:57 -0400, Jean Delvare wrote:
> > > What if we create attribute curr[1-*]_resistor, which would hold the
> > > value of the resistor used? Unit to be defined (milli-Ohm?) It would
> > > either be initialized to 1 milli-Ohm as you've been using so far, or
> > > left uninitialized (0) and the current value would only be returned by
> > > the driver after user-space sets the value (through a set statement in
> > > the configuration file.) Either way, this would let the user specify
> > > the resistor value, as we do with the ones used for voltage input
> > > scaling.
> >
> > Just as good or bad as defining a calibration factor, in my opinion.
>
> Calibration factor? You mean, the compute statement is 0.001 Ohm isn't
> OK?
>
I meant that curr1_resistor and a more generic [curr|in]1_cal_gain are
really the same to me.
Having said that, I actually do care to some degree. PMBus devices
support two registers for current calibration:
IOUT_CAL_GAIN
The IOUT_CAL_GAIN command is used to set the ratio of the voltage at the
current sense pins to the sensed current. For devices using a fixed
current sense resistor, it is typically the same value as the resistance
of the resistor.
IOUT_CAL_OFFSET
The IOUT_CAL_OFFSET is used to null out any offsets in the output
current sensing circuit. This command is most often used in conjunction
with the IOUT_CAL_GAIN command (above) to minimize the error of the
current sensing circuit.
If we make any ABI changes, we should support both calibration gain and
offset.
> > Both convert uV readings to mA. If we go along that route, we might as
> > well do the same for voltages etc.
>
> Err, but we don't _need_ it for voltages, so why would we make things
> needlessly complex?
>
Arguable. PMBus devices do have a register to specify the voltage gain.
> > Milli-Ohm would be insufficient, since there are smaller resistors
> > available. Mouser offers a sense resistor with 0.000125 Ohms, so you
> > would have to use micro-Ohm.
>
> Sure, fine with me. This will still allow values up to 4.2 kOhm on
> 32-bit systems, I presume this is sufficient.
>
> > > This would solve your concern (drivers can keep exporting curr[1-*]
> > > attributes for current sensors) and mind (components external to the
> > > monitoring device are specified by user-space).
> >
> > Not really ... current sense resistors are similar to voltage divider
> > resistors, and external to the chip. Assumption for voltage divider
> > resistors is that the driver doesn't care and conversion is handled in
> > userland. Unfortunately, that does not work for currents, since the
> > driver has to make _some_ assumption how to convert uV as reported by
> > the ADC to mA.
>
> Unless we go for suboption b, i.e. the resistor value starts at 0 and
> the driver doesn't report any current value until user-space has set
> the value. Then the driver doesn't have to assume anything.
>
> I agree that voltage and current cases aren't fundamentally different,
> except for the fact that unscaled voltage values do exist, while every
> current sensor will need a resistor.
>
> What I would like is that we come up with a standard and documented way
> to implement and use current sensors. It can be my proposal above, or
> it can be your arbitrary 0.001 Ohm resistor. But I don't want to leave
> the implementation up to every driver author. This is how lm-sensors 2
> worked, and we definitely do NOT want anything like this ever again.
>
Makes sense. I'll leave it up to you to decide which way to go.
Note that I specifically don't mind adding the ABI if you think we
should do it. After all, I do have a bunch of chips to test it with ;).
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 13+ messages in thread