Hi Mark, On Sun, 22 Apr 2007 13:12:07 -0400, Mark M. Hoffman wrote: > > On Thu, 19 Apr 2007 12:04:28 -0700, Juerg Haefliger wrote: > > > I'm struggling with the same issue for the DME1737 I'm currently > > > working on. This chip also features temp zones and "hottest of x,y,z" > > > PWM control. The current sysfs standard is not flexible enough to > > > handle these features, especially the combination of a single PWM > > > being controlled by multiple temp inputs and multiple PMWs being > > > controlled by the same temp input. I believe we need another layer of > > > mapping. I.e. temp->pwm is not sufficient, but rather temp->zone->pwm. > > > > > > I therefore propose the add the following sysfs attributes to our standard: > > > > > > zone[1-*]_auto_channels_temp for temp-to-zone mapping > > > pwm[1-*]_auto_channels_zone for zone-to-pwm mapping > > > zone[1-*]_auto_point[1-*]_temp for zone temp auto points. > > * Jean Delvare <khali at linux-fr.org> [2007-04-22 17:29:04 +0200]: > > I don't see what value it adds compared to what we currently have. > > > > We have pwm[1-*]_auto_channels_temp, which is a bit vector. We have one > > file per PWM, one bit per temperature channel, so all in all we have a > > Npwm x Ntemp matrix, or N-N relation between PWM and temperatures. This > > already allows us to handle cases such as "the hottest of tempA and > > tempB control pwmC" or "tempD controls pwmE and pwmF". > > > > You propose to add the concept of zone. According to the above, each > > zone could include any temperature channel, so we have a N-N relation > > between zones and temperatures. Then you express another N-N relation > > between PWM channels and zones. As far as I can see, this results in a > > N-N relation between temperatures and PWM, just expressed differently. > > Am I missing something? What do you think it would let us express, > > which the current model doesn't? > > I was never a big fan of the pwm_auto standard interface in the first place. > IMHO, the various chips implement automatic fan control in so many different > ways that the abstraction is bound to be mis-aligned for most chips, no matter > how we model it. > > Or if not, then the abstraction would necessarily have so many options that it > hardly even counts as an abstraction. Oh well, you're right. It is quite obvious now that our (my?) standardization attempt of the automatic fan speed control interface is a complete failure. Chips are just too different. We would need an industry standard for the manufacturers to follow. Trying to establish a standard at the software level after the fact was silly. Sorry, I guess I should have admitted sooner. > I don't see it in Documentation/hwmon/sysfs-interface, but IIRC it was agreed > that the pwm_auto standard interface was optional. So, a driver may support > that interface as best it can, OR it can support one which describes its actual > capabilities precisely (so long as there is no collision of sysfs names). It > is important to note that libsensors has no pwm_auto support anyway, and none > is planned. We do need a standard for _manual_ fan speed control, including PWM frequency and output mode (DC vs. PWM), and that one is already in place and works. Not for libsensors, but for pwmconfig/fancontrol. I wouldn't go as far as saying that we wouldn't need a standard for automatic fan speed control. If we had a working one, I guess someone could write a nice graphical interface to tweak the parameters. But the fact is that the chips are too different, so we wouldn't get around device-specific instructions anyway. > So I agree with Jean that we shouldn't extend the "standard" interface. If > you feel that the standard interface is insufficient for your hardware, then > go ahead and create something completely different. If the chip is "close" > to fitting the standard interface, I would prefer you support that as best > you can. If we're going to admit that we can't standardize the automatic fan speed control interface, then I'd rather not advertise a particular model in Documentation/hwmon/sysfs-interface at all. Let's just rip it off altogether, and let driver authors implement things the way they like. The only thing that matters then is that names make sense, that standard units are used, and that they stick to the one value per file rule. I also think that we still want to enforce the rule that we only expose absolute values and not ranges. -- Jean Delvare
