[lm-sensors] sysfs-interface: pwm [0-100] rather than [0-255] ?

[lm-sensors] sysfs-interface: pwm [0-100] rather than [0-255] ?

[Frank Myhr]

Hi,

I've added automatic pwm control to the it87.c driver and it's working
on my Gigabyte GA-MA770-DS3 motherboard with it8718f chip. I plan to
contribute the modified driver, but need to do significant cleanup and
logical patch-splitting before it's in a fit state to submit.
In my naivete I didn't read sysfs-interface until I'd already rolled
my own non-conforming interface for it87. My bad, my pain as I fix that.
I do have a comment, though:

For pwm[1-*], it seems to me to make better sense to use a range
[0, 100] ("% duty cycle"), rather than the current 8-bit range [0, 255].

Points in favor of using range [0, 100] "% duty cycle" for pwm[1-*]:

1) Consistency: other hwmon sysfs attributes that correspond to
physical quantities (temp[1-*], fan[1-*], etc.) are in physical units.

2) Freedom from chip implementation: 0-100% duty cycle remains
the same regardless of whether specific chip uses 6,7,8 or whatever
bits to represent it.

3) Meaningful value: natural for user to think in terms of 0-100% duty
cycle, rather than "255 means 100%... 60% would be... (pulls out calculator)"

Of course I remain naive, and so have some questions:

a) Is there any possibility of changing pwm[1-*] to use range [0, 100] ?*

b) If backward compatibility with [0, 255] range must be preserved,
would it be acceptable to make available an additional redundant
attribute, named something like pwm[1-*]_duty that would have range [0, 100] ?*

c) Is your [dog / cat / fish / fill in the blank] less naive than I am? :-)

*Note that the following attributes would also be affected:
pwm[1-*]_auto_point[1-*]_pwm
temp[1-*]_auto_point[1-*]_pwm

Thanks,
Frank

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

Re: [lm-sensors] sysfs-interface: pwm [0-100] rather than [0-255] ?

[Jean Delvare]

Hi Frank,

First of all: when you start a new discussion topic, please also start
a new thread on the mailing list, rather than replying to an old post
and changing the subject line. The way you did, threading looks
horrible. See by yourself:
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-June/thread.html#23382

On Mon, 23 Jun 2008 23:06:29 -0400, Frank Myhr wrote:
> I've added automatic pwm control to the it87.c driver and it's working
> on my Gigabyte GA-MA770-DS3 motherboard with it8718f chip. I plan to
> contribute the modified driver, but need to do significant cleanup and
> logical patch-splitting before it's in a fit state to submit.
> In my naivete I didn't read sysfs-interface until I'd already rolled
> my own non-conforming interface for it87. My bad, my pain as I fix that.
> I do have a comment, though:
> 
> For pwm[1-*], it seems to me to make better sense to use a range
> [0, 100] ("% duty cycle"), rather than the current 8-bit range [0, 255].
> 
> Points in favor of using range [0, 100] "% duty cycle" for pwm[1-*]:
> 
> 1) Consistency: other hwmon sysfs attributes that correspond to
> physical quantities (temp[1-*], fan[1-*], etc.) are in physical units.

A duty cycle expressed in % is not a physical unit.

> 
> 2) Freedom from chip implementation: 0-100% duty cycle remains
> the same regardless of whether specific chip uses 6,7,8 or whatever
> bits to represent it.

Same is true of the 0-255 range we use at the moment.

> 
> 3) Meaningful value: natural for user to think in terms of 0-100% duty
> cycle, rather than "255 means 100%... 60% would be... (pulls out calculator)"

True.

> 
> Of course I remain naive, and so have some questions:
> 
> a) Is there any possibility of changing pwm[1-*] to use range [0, 100] ?*

No there isn't. This would break compatibility when the users upgrade,
and several applications would have to be updated (pwmconfig and
fancontrol to start with.)

> 
> b) If backward compatibility with [0, 255] range must be preserved,
> would it be acceptable to make available an additional redundant
> attribute, named something like pwm[1-*]_duty that would have range [0, 100] ?*

I see very little benefit in doing this. In fact the only benefit is
your point 3 above. Drawbacks are many: bigger drivers, higher memory
usage, possible confusion between both interfaces.

> 
> c) Is your [dog / cat / fish / fill in the blank] less naive than I am? :-)

Well, my baby daughter didn't propose this change ;-)

> 
> *Note that the following attributes would also be affected:
> pwm[1-*]_auto_point[1-*]_pwm
> temp[1-*]_auto_point[1-*]_pwm

The 0-255 range for pwm values has its share of benefits. It is the
natural range for many chips, so it saves conversions back and forth.
Other chips almost always have a 0-2^n range which can easily be mapped
to 0-255 with no resolution loss.

The 0-100 range, on the other hand, required conversions. Given that
only integer values can be used in sysfs, this would decrease the
resolution. This would be a real problem. It is frequent that only the
smallest pwm values are usable to control a fan, so if you can't use
all the available values, the granularity can become too important for
smooth fan speed control to be possible.

If you think that converting from 0-255 to 0-100% is too difficult for
the users, this is something for applications to address. pwmconfig and
fancontrol could be adjusted to understand duty cycles expressed in
percent for example. It shouldn't be too difficult. It could bring in
some confusion though, for people used to the 0-255 range.

The sysfs interface itself will not change, pwm value range is 0-255.

-- 
Jean Delvare

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

Re: [lm-sensors] sysfs-interface: pwm [0-100] rather than [0-255] ?

[Frank Myhr]

Hi Jean,

Thank you for your quick and detailed response.

Jean Delvare wrote:
> Hi Frank,
> 
> First of all: when you start a new discussion topic, please also start
> a new thread on the mailing list, rather than replying to an old post
> and changing the subject line. The way you did, threading looks
> horrible. See by yourself:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-June/thread.html#23382

Gack! <face color="#ff0000">It seems I'm still learning about my mailer.</face>
Sorry about that. (Not corrected with this post, since damage is already done.)


>> Points in favor of using range [0, 100] "% duty cycle" for pwm[1-*]:
>>
>> 1) Consistency: other hwmon sysfs attributes that correspond to
>> physical quantities (temp[1-*], fan[1-*], etc.) are in physical units.
> 
> A duty cycle expressed in % is not a physical unit.

You're correct that % is dimensionless. However, % means 1/100,
I don't know of a symbol that means 1/255. But I'll concede that this point
is at least partially redundant with point (3) below.


>> 2) Freedom from chip implementation: 0-100% duty cycle remains
>> the same regardless of whether specific chip uses 6,7,8 or whatever
>> bits to represent it.
> 
> Same is true of the 0-255 range we use at the moment.

True.


>> 3) Meaningful value: natural for user to think in terms of 0-100% duty
>> cycle, rather than "255 means 100%... 60% would be... (pulls out calculator)"
> 
> True.


>> a) Is there any possibility of changing pwm[1-*] to use range [0, 100] ?*
> 
> No there isn't. This would break compatibility when the users upgrade,
> and several applications would have to be updated (pwmconfig and
> fancontrol to start with.)

OK.


>> b) If backward compatibility with [0, 255] range must be preserved,
>> would it be acceptable to make available an additional redundant
>> attribute, named something like pwm[1-*]_duty that would have range [0, 100] ?*
>> *Note that the following attributes would also be affected:
>> pwm[1-*]_auto_point[1-*]_pwm
>> temp[1-*]_auto_point[1-*]_pwm
> 
> I see very little benefit in doing this. In fact the only benefit is
> your point 3 above. Drawbacks are many:

> bigger drivers, higher memory usage,

A couple of extra functions... is this significant?


possible confusion between both interfaces.

Yes.


>> c) Is your [dog / cat / fish / fill in the blank] less naive than I am? :-)
> 
> Well, my baby daughter didn't propose this change ;-)

Your baby daughter already thinks in binary. Congratulations :-)


> The 0-255 range for pwm values has its share of benefits. It is the
> natural range for many chips, so it saves conversions back and forth.

lm_sensors does conversions for other attributes like rpm, pwm frequency.


> Other chips almost always have a 0-2^n range which can easily be mapped
> to 0-255 with no resolution loss.
> 
> The 0-100 range, on the other hand, required conversions. Given that
> only integer values can be used in sysfs, this would decrease the
> resolution. This would be a real problem. It is frequent that only the
> smallest pwm values are usable to control a fan, so if you can't use
> all the available values, the granularity can become too important for
> smooth fan speed control to be possible.

I didn't imagine that greater than 1% precision in pwm setting would
ever be necessary. Of course the range could just as easily be [0-1000]
or some other decimal range, as is done for voltage and temperature.


> If you think that converting from 0-255 to 0-100% is too difficult for
> the users, this is something for applications to address. pwmconfig and
> fancontrol could be adjusted to understand duty cycles expressed in
> percent for example. It shouldn't be too difficult. It could bring in
> some confusion though, for people used to the 0-255 range.


> The sysfs interface itself will not change, pwm value range is 0-255.

OK.


I suppose this discussion can be summarized by stating that I prefer
to express pwm in decimal units, whereas you prefer binary. We each have
some valid reasons (well, I have ONE at least!) for our preferences. If it
were a new interface, I might try to continue to argue for my preference.
But since it's already established (by you!) I'll adjust my thinking, as
hard as that may be ;-)

Thanks again,
Frank

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

Re: [lm-sensors] sysfs-interface: pwm [0-100] rather than [0-255] ?

[Jean Delvare]

Hi Frank,

On Tue, 24 Jun 2008 08:39:10 -0400, Frank Myhr wrote:
> Jean Delvare wrote:
> > I see very little benefit in doing this. In fact the only benefit is
> > your point 3 above. Drawbacks are many:
> 
> > bigger drivers, higher memory usage,
> 
> A couple of extra functions... is this significant?

I agree that this should be just a couple of extra functions, and very
simple ones at that. But then you multiply this by the number of
drivers, and for run-time memory, you multiply it by the number of pwm
outputs, too.

This wouldn't be enough to stop doing it if we had a good reason to do
it and no other drawbacks. But here it sums up with the other drawbacks.

> > possible confusion between both interfaces.
> 
> Yes.

Note that I didn't only mean for the user. For the driver authors and
reviewers, it would be a possible source of confusion as well.

> > The 0-255 range for pwm values has its share of benefits. It is the
> > natural range for many chips, so it saves conversions back and forth.
> 
> lm_sensors does conversions for other attributes like rpm, pwm frequency.

The reason for these conversions is to make all drivers export the data
in a standard format. This was needed because you need to know how each
chip works to interpret the register values. For voltage inputs you
need to know the DAC resolution, for fan speeds you need to know the
frequency of the gated clock, etc. The actual unit doesn't matter much.
We could have decided to export voltages with a unit of 8 mV, fan
speeds as the time in ms needed for the fan to spin once, and
temperatures in hundredth of Kelvin. We decided for units which were as
chip-neutral as possible, with enough margin so that future chips
should fit as well (with more or less success...) For voltages and
fans, a non-trivial conversion was needed, no matter the unit, so it
made sense to go for units which were human-friendly.

For PWM that was a bit different because it was possible to handle all
chips with almost no conversions. Shifting and masking is very cheap. I
guess that's the reason why range 0-255 was chosen.

> > Other chips almost always have a 0-2^n range which can easily be mapped
> > to 0-255 with no resolution loss.
> > 
> > The 0-100 range, on the other hand, required conversions. Given that
> > only integer values can be used in sysfs, this would decrease the
> > resolution. This would be a real problem. It is frequent that only the
> > smallest pwm values are usable to control a fan, so if you can't use
> > all the available values, the granularity can become too important for
> > smooth fan speed control to be possible.
> 
> I didn't imagine that greater than 1% precision in pwm setting would
> ever be necessary. Of course the range could just as easily be [0-1000]
> or some other decimal range, as is done for voltage and temperature.

I didn't imagine 1% precision being needed either, but experience has
proven me wrong.

Going with range 0-1000 would not necessarily be more natural than
0-255. While people commonly think of duty cycles in %, per-thousand is
not commonly used in this context.

> I suppose this discussion can be summarized by stating that I prefer
> to express pwm in decimal units, whereas you prefer binary.

Actually I prefer the standard that is already established over a new
one. I'm not think of it in terms of binary vs. decimal.

> We each have
> some valid reasons (well, I have ONE at least!) for our preferences. If it
> were a new interface, I might try to continue to argue for my preference.
> But since it's already established (by you!) I'll adjust my thinking, as
> hard as that may be ;-)

It wasn't actually established by me personally. Looking at the
lm-sensors project history, the first pwm interface was implemented by
Mark S. Studebaker on March 14th, 1999, for the W83782D and W83783S
chips:
  http://www.lm-sensors.org/changeset/314
That's presumably where the de-facto standard of using a 0-255 range
was established, and we're living with it since then.

I agree that, if there was no such standard, we could discuss what the
best strategy would be. Having a human-friendly unit would have its
weight in the balance. Honestly I don't know what the decision would be.

-- 
Jean Delvare

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

Re: [lm-sensors] sysfs-interface: pwm [0-100] rather than [0-255] ?

[Frank Myhr]

Jean,

Thank you for your detailed summary of some of the thinking that went
into the current sysfs-interface. Very much appreciated. I can hardly
believe my good fortune in receiving such quick and thoughtful answers
from you. And I apologize for mistakenly crediting you for the [0-255]
choice for pwm range, thanks for setting the record straight.

I don't want to take up any more of your time (right now anyway!).
I accept the [0-255] pwm range as the way it is, and hope that I can
soon contribute automatic pwm control for it87.

Thanks,
Frank

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