[PATCH 2.6.12-rc2-mm3] i2c: modify lm87 to use auto fan_div

Grant Coady grant_lkml at dodo.com.au
Sun Apr 17 14:19:33 CEST 2005

Hi Khali,
On Sun, 17 Apr 2005 12:57:09 +0200, Jean Delvare <khali at linux-fr.org> wrote:

>Hi Grant,
>> So I see it more as me putting wrong priorities on things, thus 
>> I now accept your argument of valid alarm + fan speed display, 
>> the 'sufferer' will be fan speed resolution, but that does not 
>> matter for ridiculous settings, which is what we want handle 
>> with "Just Works".  Agree?
>Agreed. We want to handle all cases but with varying level of effort.
>In particular, we do not want to do anything special when the low limit
>is disabled. There are only two valid reasons to disable the limit:
>1* No fan is connected. No need to waste our energy on this case,
Reasons don't matter, user says zero, we disable alarm, no touch 
fan clock easy rule.

I lost sight of some things, spent hours yesterday proving negative 
voltage readings, as they are ratiometric to the positive +5V, not 
a reference -- dunno if 'sensors' can do that -- then only one of 
three datasheets had a useful transfer calculation.  Sorted the 
switch "what" for limits, just the display of min/max get swapped, 
the register settings -- though I did that empirically, rather 
than prove a transfer function. 

>2* The fan is actually running slower that the chip supports. The
>current code will switch to the highest divider, which is the correct
>thing to do. No additional code is needed.
okay, yes -- but should we not then return error message in this 
case?  User has set a value and apparently nothing happened, (user 
doesn't check her logs any :)  Why bother?

>Disabling the low limit when you have a fan running at a standard speed
>is a bad idea, which is why I ask you not to add code to support that
I see your point know I had the alarm state in sight, we want 
fan speed, even when fan_min register goes to zero we have alarm 
state, so it is okay.  Just want fan speed too, can do that.

Having to explain this to each other improves my understanding.
Hope you not too annoyed with me :)

Something has to take a hit, and fan limit resolution is it, I've 
already dropped the chop point from 192 down to 128, then check 
if fan > 192 and do one adjustment in the set_fan_min.  Rest of 
adjustment in measurement side, not bidirectional until we see a 
need?  Hitting fan_min resolution early will (I hope) improve the 
thing.  Getting late my time -- more tomorrow.  

With measurements, proof.


More information about the lm-sensors mailing list