RFC PATCH 2.6 sysfs names: fscher: change div to ripple
khali at linux-fr.org
Wed Apr 27 23:14:31 CEST 2005
> But whether it's the same hardware implementation or not, if it has
> the same effect, then it's the same feature (quack's like a duck =>
> it's a duck).
> The fan dividors we're used to seeing are ripple counters on the
> 22.5kHz clock that divide it down to reduce the clock pulses counted
> by the gating fan pulses.
> This ripple counter sounds like the same thing, but working on the
> fan pulses directly rather than on the 22.5kHz clock. So the fan
> tach signal is slower with a higher divisor.
> So the fan_ripple is the *inverse* of the fan_div value, but they
> have the same net effect, and you can account for the reciprical in
> the driver. ie fan_div = 8/fan_ripple (if the max "ripple" value
> is 8)
Thanks for the clarification, it all makes sense now, and actually both
ways can be seen as similar, you're right. It's really only a matter of
whether or not we compensate for the division in the driver. We
typically do for fan clock dividers and not in the FSC chips case, but
this is more or less arbitrary.
> I've had to deal with 4-pulse per rev fans before and I've done it
> with 'compute' commands in sensors.conf. It does not need to be in
> the driver.
Changing the divider (whatever it actually divides) has an impact on the
measurable range and accuracy. This might be a good reason to let the
driver handle it when the chip does, so that we can get the best from
the hardware. Now I agree that the same approach that is currently
followed for the regular fan clock dividers could apply in the FSC case
as well. I have no strong opinion on this (understatement of me being
unable to decide what I think we should do) so any solution that is
consistent will be fine with me.
More information about the lm-sensors