How to add nano precision measurement to hwmon

How to add nano precision measurement to hwmon

[Lucas Tanure]

Hi,

We have here in our company an internal hardware platform for our linux 
development that can measure current in a few circuits with nanoamps 
precision.
The measured values are exposed by a 32bit register that must read as a 
32bit float.

If we follow the hwmon sysfs interface we loss precision converting to 
milliamps, where the final value exposed is zero.

Example :
Measure 291nA becomes 0mA under sysfs curr1_input

The best solution for me would be a file in sysfs that I could just 
expose the float from my register (like curr1_input_float), this 
solution has two benefits for me:

- I wouldn't need to convert my internal float to int
- This would give the best precision that I can have from my hardware

The value could be exposed as a 32bit hex string, like 0x349c3abc.

So, how should I proceed with this ?

Thanks

Lucas Tanure

Re: How to add nano precision measurement to hwmon

[Guenter Roeck]

Hi Lucas,

On 02/17/2017 08:07 AM, Lucas Tanure wrote:
> Hi,
>
> We have here in our company an internal hardware platform for our linux development that can measure current in a few circuits with nanoamps precision.
> The measured values are exposed by a 32bit register that must read as a 32bit float.
>
> If we follow the hwmon sysfs interface we loss precision converting to milliamps, where the final value exposed is zero.
>
> Example :
> Measure 291nA becomes 0mA under sysfs curr1_input
>
> The best solution for me would be a file in sysfs that I could just expose the float from my register (like curr1_input_float), this solution has two benefits for me:
>
> - I wouldn't need to convert my internal float to int
> - This would give the best precision that I can have from my hardware
>
> The value could be exposed as a 32bit hex string, like 0x349c3abc.
>
> So, how should I proceed with this ?
>

A hex string would be really bad; userspace (generic) would not know what to do with it.

You could on purpose violate the ABI and report the current in nano-Amps with currX_input
(properly documented). This way the sensors command would still work after proper
adjustments in /etc/sensors3.conf. If the current sense resistor is configurable,
you could also not tell me at all and assume a current sense resistor which is
1,000,000 times larger than the one you actually use (after all, currency is
usually measured as voltage loss over a current sense resistor).

Another possibility would be to add a curr1_input_na attribute, but I would prefer
the above mechanism.

Guenter

Re: How to add nano precision measurement to hwmon

[Lucas Tanure]

On 19/02/2017 02:10, Guenter Roeck wrote:
> Hi Lucas,
>
> On 02/17/2017 08:07 AM, Lucas Tanure wrote:
>> Hi,
>>
>> We have here in our company an internal hardware platform for our 
>> linux development that can measure current in a few circuits with 
>> nanoamps precision.
>> The measured values are exposed by a 32bit register that must read as 
>> a 32bit float.
>>
>> If we follow the hwmon sysfs interface we loss precision converting 
>> to milliamps, where the final value exposed is zero.
>>
>> Example :
>> Measure 291nA becomes 0mA under sysfs curr1_input
>>
>> The best solution for me would be a file in sysfs that I could just 
>> expose the float from my register (like curr1_input_float), this 
>> solution has two benefits for me:
>>
>> - I wouldn't need to convert my internal float to int
>> - This would give the best precision that I can have from my hardware
>>
>> The value could be exposed as a 32bit hex string, like 0x349c3abc.
>>
>> So, how should I proceed with this ?
>>
>
> A hex string would be really bad; userspace (generic) would not know 
> what to do with it.
>
> You could on purpose violate the ABI and report the current in 
> nano-Amps with currX_input
> (properly documented). This way the sensors command would still work 
> after proper
> adjustments in /etc/sensors3.conf. If the current sense resistor is 
> configurable,
> you could also not tell me at all and assume a current sense resistor 
> which is
> 1,000,000 times larger than the one you actually use (after all, 
> currency is
> usually measured as voltage loss over a current sense resistor).
>
> Another possibility would be to add a curr1_input_na attribute, but I 
> would prefer
> the above mechanism.
>
> Guenter

Hi Guenter,

You don't see any option to expose the 32bit float to user space ?
I would rather not deal with float conversion inside the kernel, as the 
numbers become too large to deal and I lose precision.

Thanks

Lucas Tanure

Re: How to add nano precision measurement to hwmon

[Guenter Roeck]

On 02/19/2017 12:53 AM, Lucas Tanure wrote:
> On 19/02/2017 02:10, Guenter Roeck wrote:
>> Hi Lucas,
>>
>> On 02/17/2017 08:07 AM, Lucas Tanure wrote:
>>> Hi,
>>>
>>> We have here in our company an internal hardware platform for our linux development that can measure current in a few circuits with nanoamps precision.
>>> The measured values are exposed by a 32bit register that must read as a 32bit float.
>>>
>>> If we follow the hwmon sysfs interface we loss precision converting to milliamps, where the final value exposed is zero.
>>>
>>> Example :
>>> Measure 291nA becomes 0mA under sysfs curr1_input
>>>
>>> The best solution for me would be a file in sysfs that I could just expose the float from my register (like curr1_input_float), this solution has two benefits for me:
>>>
>>> - I wouldn't need to convert my internal float to int
>>> - This would give the best precision that I can have from my hardware
>>>
>>> The value could be exposed as a 32bit hex string, like 0x349c3abc.
>>>
>>> So, how should I proceed with this ?
>>>
>>
>> A hex string would be really bad; userspace (generic) would not know what to do with it.
>>
>> You could on purpose violate the ABI and report the current in nano-Amps with currX_input
>> (properly documented). This way the sensors command would still work after proper
>> adjustments in /etc/sensors3.conf. If the current sense resistor is configurable,
>> you could also not tell me at all and assume a current sense resistor which is
>> 1,000,000 times larger than the one you actually use (after all, currency is
>> usually measured as voltage loss over a current sense resistor).
>>
>> Another possibility would be to add a curr1_input_na attribute, but I would prefer
>> the above mechanism.
>>
>> Guenter
>
> Hi Guenter,
>
> You don't see any option to expose the 32bit float to user space ?
> I would rather not deal with float conversion inside the kernel, as the numbers become too large to deal and I lose precision.
>
I'd rather not have to deal with one of many float formats in a kernel ABI.
After all, an ABI is expected to convert from internal formats to standardized
formats.

Besides, u32 can report ~4 A in nano-Ampere, and u64 can report 18,446,744,073 A
in nano-Ampere, so I am not entirely sure I can follow your argument about
loosing precision.

Do you plan to submit your driver upstream ? Maybe it would help to see the code.

Thanks,
Guenter

Re: How to add nano precision measurement to hwmon

[Charles Keepax]

On Sun, Feb 19, 2017 at 08:33:52AM -0800, Guenter Roeck wrote:
> On 02/19/2017 12:53 AM, Lucas Tanure wrote:
> >On 19/02/2017 02:10, Guenter Roeck wrote:
> >>Hi Lucas,
> >>
> >>On 02/17/2017 08:07 AM, Lucas Tanure wrote:
> >Hi Guenter,
> >
> >You don't see any option to expose the 32bit float to user space ?
> >I would rather not deal with float conversion inside the kernel, as the numbers become too large to deal and I lose precision.
> >
> I'd rather not have to deal with one of many float formats in a kernel ABI.
> After all, an ABI is expected to convert from internal formats to standardized
> formats.
> 
> Besides, u32 can report ~4 A in nano-Ampere, and u64 can report 18,446,744,073 A
> in nano-Ampere, so I am not entirely sure I can follow your argument about
> loosing precision.
> 
> Do you plan to submit your driver upstream ? Maybe it would help to see the code.

I have to say I think I agree with Guenter here exposing random binary
stuff in sysfs is not nice and if the user side stuff can actually
be configured to correctly handle us reporting nA that seems like a
no-brainer.

We do intend to upstream the driver, there is some support for the
device in general that I need to upstream first, then Lucas can send
up the hwmon stuff.

Thanks,
Charles