xref: /netbsd-src/share/man/man4/envsys.4 (revision 89c5a767f8fc7a4633b2d409966e2becbb98ff92)
1.\"	$NetBSD: envsys.4,v 1.3 2000/03/09 04:17:20 groo Exp $
2.\"
3.\"
4.\" Copyright (c) 2000 The NetBSD Foundation, Inc.
5.\" All rights reserved.
6.\"
7.\" This code is derived from software contributed to The NetBSD Foundation
8.\" by Tim Rightnour and Bill Squier
9.\"
10.\" Redistribution and use in source and binary forms, with or without
11.\" modification, are permitted provided that the following conditions
12.\" are met:
13.\" 1. Redistributions of source code must retain the above copyright
14.\"    notice, this list of conditions and the following disclaimer.
15.\" 2. Redistributions in binary form must reproduce the above copyright
16.\"    notice, this list of conditions and the following disclaimer in the
17.\"    documentation and/or other materials provided with the distribution.
18.\" 3. All advertising materials mentioning features or use of this software
19.\"    must display the following acknowledgement:
20.\"        This product includes software developed by the NetBSD
21.\"        Foundation, Inc. and its contributors.
22.\" 4. Neither the name of The NetBSD Foundation nor the names of its
23.\"    contributors may be used to endorse or promote products derived
24.\"    from this software without specific prior written permission.
25.\"
26.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
27.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
28.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
29.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
30.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
31.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
32.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
33.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
34.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
35.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
36.\" POSSIBILITY OF SUCH DAMAGE.
37.\"
38
39.Dd February 26, 2000
40.Dt ENVSYS 4
41.Os
42.Sh NAME
43.Nm envsys
44.Nd Environmental Systems API
45.Sh SYNOPSIS
46.Fd #include <sys/envsys.h>
47.Sh DESCRIPTION
48.Pp
49.Bd -offset center
50.Em This API is experimental and may be deprecated at
51.Em any time
52.Ed
53.Pp
54There are a number of considerations:
55.Bl -enum
56.It
57This API is designed to support various environmental sensor ICs
58available on modern motherboards.  Initially it supports three
59distinct sensor types; fan speed, temperature, and voltage.
60Additional sensor types can be added with new ioctl's without
61disrupting the current API.
62.It
63Many sensor ICs have no fixed assignment of registers to
64physical phenomena.  Thus, some userland mechanism of
65assigning meanings to the registers is required to allow
66userland utilities to produce reasonable output.
67.It
68The number of registers for each class of sensor varies
69among devices.  Therefore a way to enumerate all data of
70a particular sensor type is required.  Fixed limits on the
71number of sensors per type is not desirable.
72.It
73Some ICs provide useful statistical information.
74Collecting reliable statistical information in userland
75from a polled device is problematic.  We would like to use
76the on-chip information when it is available.
77.It
78A useful balance between complexity of use and amount
79of available information is desired.  While it may be
80possible to allow for an unlimited number of statistical
81measures to be returned by a device, we have chosen only
82four common ones: current, minimum, maximum, and average.
83Even with this limited set, it may be impractical or
84impossible for devices to produce them all.  Thus, a
85mechanism to determine which statistics are valid is required.
86.It
87The API is designed in a way that can be used to monitor
88both system-internal, and system-external environmental
89sensors.
90.El
91.Pp
92For the purposes of this API, all devices must number the sensors
93sequentially, beginning with 0.  Moreover, all sensors of the same
94type must occupy a sub-interval of [0..n-1].  This arrangement
95allows easy iteration over the entire collection of sensors or over
96sensors of a particular type.
97.Pp
98The following
99.Xr ioctl 2 's
100must be supported by any device claiming to
101be compliant with version 1.0 of
102.Nm
103.Pp
104.Bl -tag -width indent
105.It Dv ENVSYS_VERSION (int)
106Returns API version * 1000.  A userland application could use
107this command to determine further supported ioctl's of the
108device.
109.It Dv ENVSYS_GRANGE (envsys_range_t)
110The caller fills in the
111.Va units
112member of:
113.Bd -literal
114typedef struct envsys_range {
115	u_int low;
116	u_int high;
117
118	u_int units;	/* see GTREDATA */
119} envsys_range_t;
120.Ed
121.Pp
122The driver fills in the
123.Va low
124and
125.Va high
126values such that
127sensor numbers from
128.Va low
129to
130.Va high ,
131inclusive, contain sensors of type
132.Va units .
133.Pp
134NOTE:
135.Va high
136<
137.Va low
138implies no sensors of the unit type specified exist.
139.It Dv ENVSYS_GTREDATA (envsys_tre_data)
140This command makes use of:
141.Bd -literal
142typedef struct envsys_tre_data {
143	u_int sensor;
144	union {				/* all data is given */
145		u_int32_t data_us;	/* in microKelvins, */
146		int32_t data_s;		/* rpms, volts, amps, */
147	} cur, min, max, avg;		/* ohms, watts, etc */
148					/* see units below */
149
150	u_int32_t	warnflags;	/* warning flags */
151	u_int32_t	validflags;	/* sensor valid flags */
152	u_int		units;		/* type of sensor */
153} envsys_tre_data_t;
154.Ed
155.Pp
156At request time, the caller of this command fills only the
157.Va sensor
158member with the sensor number for which data is being
159requested.  The structure is returned with available data
160filled in by the driver.
161.Pp
162Zero or more of the following bits may be set in
163.Va validflags :
164.Pp
165.Bl -tag -width indent -compact -offset indent
166.It Dv ENVSYS_FVALID
167Not set implies an illegal sensor number was requested.
168.Pp
169.It Dv ENVSYS_FCURVALID
170.It Dv ENVSYS_FMINVALID
171.It Dv ENVSYS_FMAXVALID
172.It Dv ENVSYS_FAVGVALID
173Set if these fields are filled with valid data
174.Pp
175Although
176.Dv !ENVSYS_FVALID
177might be implied from the absence of
178all other *VALID flags, it is conceivable that some ICs have
179a period during which valid sensors contain invalid data.
180.El
181.Pp
182Valid
183.Va warnflags
184are:
185.Pp
186.Bl -tag -width indent -compact -offset indent
187.It Dv ENVSYS_WARN_OK
188.It Dv ENVSYS_WARN_UNDER
189.It Dv ENVSYS_WARN_CRITUNDER
190.It Dv ENVSYS_WARN_OVER
191.It Dv ENVSYS_WARN_CRITOVER
192.El
193.Pp
194The driver may return
195.Dv ENVSYS_WARN_OK
196at all times if the hardware or driver does not support warning flags.
197.Pp
198Valid
199.Va units
200are:
201.Pp
202.Bl -tag -width indent -compact -offset indent
203.It Dv ENVSYS_STEMP
204.It Dv ENVSYS_SFANRPM
205.It Dv ENVSYS_SVOLTS_AC
206.It Dv ENVSYS_SVOLTS_DC
207.It Dv ENVSYS_SOHMS
208.It Dv ENVSYS_SWATTS
209.Ir Dv ENVSYS_SAMPS
210.El
211.It Dv ENVSYS_STREINFO (envsys_basic_info_t)
212.It Dv ENVSYS_GTREINFO (envsys_basic_info_t)
213These commands make use of:
214.Bd -literal
215typedef struct envsys_basic_info {
216	u_int	sensor;		/* sensor number */
217	u_int	units;		/* type of sensor */
218	char	desc[33];	/* sensor description */
219	u_int	rpms;		/* for fans */
220	u_int	rfact;		/* for volts, (factor x 10^4) */
221	u_int32_t validflags;	/* sensor valid flags */
222} envsys_basic_info_t;
223.Ed
224.Pp
225.Dv ENVSYS_STREINFO is for setting this information in the driver,
226while
227.DV ENVSYS_GTREINFO is for retrieving this information.
228.Pp
229To retrieve information, simply fill in the
230.Va sensor
231member.
232.Pp
233All environmental sensor types read the supplied
234.Va desc
235field and store the contents for subsequent requests.  The
236driver is expected to supply a default
237.Dv NULL
238terminated string for
239.Va desc .
240.Pp
241RPM sensor types additionally read the nominal RPM value from
242.Va rpms .
243Voltage sensors read
244.Va rfact .
245Drivers are expected to multiply DC voltage values by this factor before
246returning them to the user.
247.Pp
248The driver will fill in the
249.Va flags
250value, indicating to the user that he has successfully programmed or
251retrieved data from an existing sensor.
252.El
253.Sh SEE ALSO
254.Xr lm 4
255.Sh BUGS
256This entire API should be replaced by a
257.Xr sysctl 8
258interface or a kernel events mechanism, should one be developed.
259
260