thanks. I did miss your 3/16 mail. I changed the subject so we can start a new thread :) I have seen some of your mails blocked on the mailing list but received at my address; you should _not_ use html mail or it will get blocked. I tested and checked-in your 4-line fix. In the future please provide a real patch generated by 'diff -u'. I reviewed the datasheet about comparator/interrupt modes. Unfortunately, only the temps support comparator mode; voltages and fans support only interrupt mode (datasheet sections 7.7.5-7.7.7) Please feed back our disappointment to your chip designers. I've never seen a hardware sensor that didn't support comparator mode. Comparator mode is our driver standard as it is the most reliable for the reasons I've previously mentioned. Without comparator mode, we really need an interrupt-driven driver or the additional logic you've put into 'sensors'. My recommendation is that we set the temperature sensors to comparator mode. The code at line 729 should put bits 7 and 6 of reg. 0x4C to 00 (comparator mode), which is what the comment says, but it sets it to 01 (2 times interrupt mode). This is probably left over from whatever driver you copied from. So my recommendation is to set the bits to 00. mds Huang0 at Winbond.com.tw wrote: > Dear MDS, Jean > > Did you ever receive my mail below sent on 2005-03-16 ? I do not get > any response from you, I checked the sent mail just now, find that I > sent > it by "HTML" format, maybe it was blocked by your spam filter. > > I checked the lm_sensors CVS just now, find that the codes(please refer > to the mail below) to fix the bug of negative fan measured value has not > been added into w83792d.c. > MDS, would you please fix it for me? Because I do not have a CVS > account. > You may test it first before you commit it into CVS. I find that the > lm_sensors-2.9.1 will be released soon, I hope it will NOT contain this > negative fan measured value bug. :-) > > As to the document doc\chips\w83792d, it still has NOT been finished, > because I'm busy these days, I will send it to you as soon as possible > when I finish it. Very sorry for the delay. > > As to the discussion on whether use "hardware-level" alarm mechanism > or my "software-level" one, I want to keep my original codes, because > after a compare and test to these two methods, I think my method is > better(please refer to my related mails in this thread). If most of the > users disagree about it in the future, we may fix it later. :-) > > Thanks > > Best Regards > > Chunhao > 2005-03-26 > > > > ---------------- Sent on 2005-03-16 --------------------------------- > Hi Jean, MDS > > >>Sounds like an "interrupt mode" to me (as opposed to "comparator > > mode"). > >>The alarm bits raise on state change and wear off when read. In >>comparator mode you would obtain what you'd expect (alarm bit always >>reflecting the result of the comparison). > > >>If the W83792D can be reprogramed in comparator mode AND this does NOT >>affect any physical output, then just do that. If the alarm bits DO >>affect an output, then you should not change the mode, which means > > that > >>you cannot use hardware alarms if the chip is in interrupt mode. > > > Hm... very sorry that I do not catch what you said very well. How to > reprogramed 792 driver in "comparator mode" instead of "interrupt mode"? > Can we say that the method in submitted 792 driver is in "comparator > mode"? > Then I can keep my original codes? > > >>Get a CVS snapshot here: >>http://secure.netroedge.com/~lm78/archive/lm_sensors-daily.tar.gz >>And provide a patch against that. > > > If I need not fix the "point 1" MDS provided, The codes to fix "point 3" > are > very few. > > MDS, Would you please just add 4 lines into the "do...while (0)" loop > of function w83792d_fan()? Just like this: > > 1013 if (((data->fan_div[nr])>=0x07 && > 1014 (data->fan[nr])==0xff) || > 1015 ((data->fan_div[nr])<=0 && > 1016 (data->fan[nr])<0x78)) { > 1017 results[1] = 0; > 1018 break; > 1019 } else if ((data->fan_div[nr])<0x07 && > 1020 (data->fan[nr])==0xff) { > 1021 (data->fan_div[nr])++; > results[1] = FAN_FROM_REG(data->fan[nr], <--added by chunhao > DIV_FROM_REG(data->fan_div[nr])); <--added by chunhao > 1022 } else if ((data->fan_div[nr])>0 && > 1023 (data->fan[nr])<0x78) { > 1024 (data->fan_div[nr])--; > results[1] = FAN_FROM_REG(data->fan[nr], <--added by chunhao > DIV_FROM_REG(data->fan_div[nr])); <--added by chunhao > 1025 } > > The minus fan measured value then will disappear from my system, > would you please test it on your system? If it works too, please commit > it for me. >
