[lm-sensors] sysfs interface for fan present capability

[lm-sensors] sysfs interface for fan present capability

[Hans de Goede]

Hi all,

It looks like I've discover yet another feature of the uguru, a bit in
the fan bank which seemed to be sometimes 1 sometimes 0 actually seems
to indicate whether a fan is present or not. I'm not 100% sure, but I'm
starting to see a pattern and sofar it holds in 100% of the cases I
have. I'll buy myself an extra 3 wire fan and put it on the aux fan
connectors then I'll know for sure soon enough.

Which brings me to the question, do we want to export this to userspace
(I guess we do) and if we do how. May I suggest a readonly boolean
fan[1-x]_present?

Regards,

Hans

[lm-sensors] sysfs interface for fan present capability

[Jean Delvare]

Hi Hans,

> It looks like I've discover yet another feature of the uguru, a bit in
> the fan bank which seemed to be sometimes 1 sometimes 0 actually seems
> to indicate whether a fan is present or not. I'm not 100% sure, but I'm
> starting to see a pattern and sofar it holds in 100% of the cases I
> have. I'll buy myself an extra 3 wire fan and put it on the aux fan
> connectors then I'll know for sure soon enough.
> 
> Which brings me to the question, do we want to export this to userspace
> (I guess we do) and if we do how. May I suggest a readonly boolean
> fan[1-x]_present?

Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
this works physically. It would be great if other chips could implement
this feature, that would make autoconfig easier for fans. If you
implement this feature in the abituguru driver, just include a patch to
Documentation/hwmon/sysfs-interface describing this new interface file.

-- 
Jean Delvare

[lm-sensors] sysfs interface for fan present capability

[Henrique de Moraes Holschuh]

On Sun, 04 Jun 2006, Jean Delvare wrote:
> Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
> this works physically. It would be great if other chips could implement
> this feature, that would make autoconfig easier for fans. If you

We can certainly implement it as in-driver logic if the hardware doesn't
cooperate, but a stuck fan on startup will be shown as not-present unless
you DO have hardware detection.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] sysfs interface for fan present capability

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
>> It looks like I've discover yet another feature of the uguru, a bit in
>> the fan bank which seemed to be sometimes 1 sometimes 0 actually seems
>> to indicate whether a fan is present or not. I'm not 100% sure, but I'm
>> starting to see a pattern and sofar it holds in 100% of the cases I
>> have. I'll buy myself an extra 3 wire fan and put it on the aux fan
>> connectors then I'll know for sure soon enough.
>>
>> Which brings me to the question, do we want to export this to userspace
>> (I guess we do) and if we do how. May I suggest a readonly boolean
>> fan[1-x]_present?
> 
> Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
> this works physically.

I think they are just seeing if it gives any "ticks" at all, so it won't
detect a 2 wire fan even if connected to one if its headers.

And as said I'm not even sure it does that, its basicly a mistery bit in
the uguru which I think does this :)  When I have some more spare time
and renewed energy for the uGuru I'll try to connect a 3 wire fan to my
other fan headers and see what happens.

Regards,

Hans

[lm-sensors] sysfs interface for fan present capability

[Henrique de Moraes Holschuh]

On Sun, 04 Jun 2006, Hans de Goede wrote:
> I think they are just seeing if it gives any "ticks" at all, so it won't
> detect a 2 wire fan even if connected to one if its headers.

Two-wire fans can be detected just as well as three-wire ones, if you
measure current draw :)  In fact, some chips (like the lm75) can actually
COUNT ticks on two-wire fans by measuring spikes in the current draw...

If you detect fan presence using ticks, you will never detect a stuck fan on
startup, which is *dangerous* as it could cause the software inhibit an
alarm on that fan.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] sysfs interface for fan present capability

[Jean Delvare]

Hi Henrique,

> On Sun, 04 Jun 2006, Jean Delvare wrote:
> > Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
> > this works physically. It would be great if other chips could implement
> > this feature, that would make autoconfig easier for fans. If you
> 
> We can certainly implement it as in-driver logic if the hardware doesn't
> cooperate, but a stuck fan on startup will be shown as not-present unless
> you DO have hardware detection.

No, this feature is only valuable if implemented by the hardware. If we
emulate it in any way, it would be in user space and not in the
drivers, but even there I fail to see the value.

-- 
Jean Delvare

[lm-sensors] sysfs interface for fan present capability

[Jean Delvare]

> On Sun, 04 Jun 2006, Hans de Goede wrote:
> > I think they are just seeing if it gives any "ticks" at all, so it won't
> > detect a 2 wire fan even if connected to one if its headers.
> 
> Two-wire fans can be detected just as well as three-wire ones, if you
> measure current draw :)  In fact, some chips (like the lm75) can actually
> COUNT ticks on two-wire fans by measuring spikes in the current draw...

Definitely not the LM75, as it is a temperature-only sensor chip. But I
remember reading datasheets mentioning tick count on 2-wires fans,
indeed. Strangely enough, some vendors are doing the opposite and
propose 4-wire fans, the idea being that tick counts tend to be lost
when fan speed control is in use on 3-wire fans.

> If you detect fan presence using ticks, you will never detect a stuck fan on
> startup, which is *dangerous* as it could cause the software inhibit an
> alarm on that fan.

Indeed - which is why I don't want us to emulate it in software.

-- 
Jean Delvare

[lm-sensors] sysfs interface for fan present capability

[Henrique de Moraes Holschuh]

On Sun, 04 Jun 2006, Jean Delvare wrote:
> > On Sun, 04 Jun 2006, Jean Delvare wrote:
> > > Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
> > > this works physically. It would be great if other chips could implement
> > > this feature, that would make autoconfig easier for fans. If you
> > 
> > We can certainly implement it as in-driver logic if the hardware doesn't
> > cooperate, but a stuck fan on startup will be shown as not-present unless
> > you DO have hardware detection.
> 
> No, this feature is only valuable if implemented by the hardware. If we
> emulate it in any way, it would be in user space and not in the
> drivers, but even there I fail to see the value.

I fully agree, and I suggest that the sysfs interface description makes it
clear that this attribute can be exported only if it is a *hardware sense*
result...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] sysfs interface for fan present capability

[Henrique de Moraes Holschuh]

On Sun, 04 Jun 2006, Jean Delvare wrote:
> Definitely not the LM75, as it is a temperature-only sensor chip. But I

My bad, I should have typed lm85 (which would not be strictly correct,
either: the ADM1027 does it.  It is a LM85 compatible chip, but I don't
think the lm85b/c can do it).

> indeed. Strangely enough, some vendors are doing the opposite and
> propose 4-wire fans, the idea being that tick counts tend to be lost
> when fan speed control is in use on 3-wire fans.

As soon as you drive fans using PWM you screw up any sort of simple tick
counters completely, as you have a spike on every PWM cycle start, plus no
spikes generated during the second phase of the PWM cycle.

Probably they want four wires so that you can have Vcc, GND, Vcc-sense and
sense, so that PWM does not disable the sensor. 

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] sysfs interface for fan present capability

[Jean Delvare]

Hi Henrique,

> On Sun, 04 Jun 2006, Jean Delvare wrote:
> > > On Sun, 04 Jun 2006, Jean Delvare wrote:
> > > > Sure, why not. fan[1-*]_present sounds like a good idea. I wonder how
> > > > this works physically. It would be great if other chips could implement
> > > > this feature, that would make autoconfig easier for fans. If you
> > > 
> > > We can certainly implement it as in-driver logic if the hardware doesn't
> > > cooperate, but a stuck fan on startup will be shown as not-present unless
> > > you DO have hardware detection.
> > 
> > No, this feature is only valuable if implemented by the hardware. If we
> > emulate it in any way, it would be in user space and not in the
> > drivers, but even there I fail to see the value.
> 
> I fully agree, and I suggest that the sysfs interface description makes it
> clear that this attribute can be exported only if it is a *hardware sense*
> result...

This is true of all sysfs attributes, not just this one. See patch
04/11 I just sent to Greg, I updated the documentation to make it
clearer.

-- 
Jean Delvare

[lm-sensors] sysfs interface for fan present capability

[Jean Delvare]

> On Sun, 04 Jun 2006, Jean Delvare wrote:
> > Definitely not the LM75, as it is a temperature-only sensor chip. But I
> 
> My bad, I should have typed lm85 (which would not be strictly correct,
> either: the ADM1027 does it.  It is a LM85 compatible chip, but I don't
> think the lm85b/c can do it).
> 
> > indeed. Strangely enough, some vendors are doing the opposite and
> > propose 4-wire fans, the idea being that tick counts tend to be lost
> > when fan speed control is in use on 3-wire fans.
> 
> As soon as you drive fans using PWM you screw up any sort of simple tick
> counters completely, as you have a spike on every PWM cycle start, plus no
> spikes generated during the second phase of the PWM cycle.

Some chips try to compensate with additional circuitery. This requires
that you know which fan input is connected to which PWM output though,
and that the motherboard manufacturer did take care of wiring things
properly. And even then I guess you lose most of the accuracy when PWM
gets too low.

-- 
Jean Delvare

[lm-sensors] sysfs interface for fan present capability

[Henrique de Moraes Holschuh]

On Sun, 04 Jun 2006, Jean Delvare wrote:
> > As soon as you drive fans using PWM you screw up any sort of simple tick
> > counters completely, as you have a spike on every PWM cycle start, plus no
> > spikes generated during the second phase of the PWM cycle.
> 
> Some chips try to compensate with additional circuitery. This requires
> that you know which fan input is connected to which PWM output though,
> and that the motherboard manufacturer did take care of wiring things
> properly. And even then I guess you lose most of the accuracy when PWM
> gets too low.

Yes. In fact, the LM85 chips are one of those and one of the current bugs in
the driver is that it is not directing the chips to do so properly.  Well,
when I get my butt off other Debian work, I will submit the patches I've been
using to fix that.

The PWM-compensation algo and circuits impose limits on the speeds one can
measure under PWM, and these limits are variable with the PWM duty cycle.
Slow speeds can never be measured well enough.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] sysfs interface for fan present capability

[Philip Pokorny]

The four wire fan connectors are the same original 3 wires (pwr, gnd, tach) with the fourth wire being a digital pwm control signal to the fan.

The way that it works is to take advantage of the power MOSFET (switch) that is already in every DC fan.  Add the PWM input to the circuit that controls when the switch is turned on so that it *doesn't* turn on when the PWM is active.  The result is that the fan slows down.

This is much simpler, cheaper to implement, and resolves several issues with using low-side or high-side MOSFETs on the motherboard.

CPU fans on the new Intel CPUs (Conroe, Dempsey, Woodcrest) will probably all be four wire.  Penguin Computing uses four wire case fans in its Tempest 2150 for better control and monitoring.

:v)

 -----Original Message-----
From: 	Henrique de Moraes Holschuh [mailto:hmh at debian.org]
Sent:	Sun Jun 04 11:10:28 2006
To:	Jean Delvare
Cc:	Hans de Goede; LM Sensors
Subject:	Re: [lm-sensors] sysfs interface for fan present capability

On Sun, 04 Jun 2006, Jean Delvare wrote:
> Definitely not the LM75, as it is a temperature-only sensor chip. But I

My bad, I should have typed lm85 (which would not be strictly correct,
either: the ADM1027 does it.  It is a LM85 compatible chip, but I don't
think the lm85b/c can do it).

> indeed. Strangely enough, some vendors are doing the opposite and
> propose 4-wire fans, the idea being that tick counts tend to be lost
> when fan speed control is in use on 3-wire fans.

As soon as you drive fans using PWM you screw up any sort of simple tick
counters completely, as you have a spike on every PWM cycle start, plus no
spikes generated during the second phase of the PWM cycle.

Probably they want four wires so that you can have Vcc, GND, Vcc-sense and
sense, so that PWM does not disable the sensor. 

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

_______________________________________________
lm-sensors mailing list
lm-sensors at lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060604/84cdd296/attachment.html