Hi all, Here is my third proposal for an common auto-fan control interface. See these previous threads for the first and second proposals and associated comments: http://archives.andrew.net.au/lm-sensors/msg07517.html http://archives.andrew.net.au/lm-sensors/msg08091.html The interface is still made up of two parts: per fan temp channels selection, and trip points selection. Temp channels selection ======================= It looks like the possibility to select more than one temp channel for a given fan controler is needed (Philip Pokorny), so we wouldn't simplify this. As in the first proposal, the values would be bitfields, 1<<N == temp channel N matters to compute the considered fan's speed. Files : fan1_auto_channels fan2_auto_channels Trip points =========== Two distinct models exist: trip points set for a given fan, or trip points set for a given temperature channels. Looks like there is no easy conversion from one model to the other so this gives two possible sets of files (each driver picks the one matching the hardware implementation): fan1_auto_temp_off fan1_auto_temp_min fan1_auto_temp_max fan1_auto_pwm_min fan1_auto_pwm_max fan2_auto_temp_off fan2_auto_temp_min fan2_auto_temp_max fan2_auto_pwm_min fan2_auto_pwm_max OR temp1_auto_temp_off temp1_auto_temp_min temp1_auto_temp_max temp1_auto_pwm_min temp1_auto_pwm_max temp2_auto_temp_off temp2_auto_temp_min temp2_auto_temp_max temp2_auto_pwm_min temp2_auto_pwm_max temp3_auto_temp_off temp3_auto_temp_min temp3_auto_temp_max temp3_auto_pwm_min temp3_auto_pwm_max 3 trip points in any case, but only 5 values (pwm_off is implied as 0%). Rules are: if temp < off, fan is off if off < temp < min, fan speed is either 0 or pwm_min (allows for hysteresis) if min < temp < max, fan speed is between pwm_min and pwm_max. Exact value is left to the driver/hardware, but should be next to a weighted average if possible. if temp > max, fan goes to full speed (typically pwm = 100%). Additional notes ================ 1* For some reason, the adm1031 driver had auto_ as a prefix instead of inside the names. I prefer my way because it clearly shows which element the values are attached to. OTOH I agree that "filtering" files with "ls" is somewhat easier with auto as the prefix (especially if you do *not* want to see the auto-fan files). No strong opinion actually. 2* As Mark Hoffman and Mark Studebaker noticed, this interface will necessarily leave extra features or modes behind. Thus, this interface should be considered non-limitative and subject to further extensions as additional common patterns show among various chips. In particular, driver authors should be free to: - not implement this interface if the chip design is too different - implement a different interface if they think it's needed (additionally or exclusively) The other interface (or additions to the standard interface) should be prefixed in such a way that it won't collide with a further extension of the standard interface (until the feature is actually discussed and standardized). All in all, this interface is meant for chips those implementations roughly fit into it, and that's about it. Comments, anyone? Thanks, Jean Delvare
