On Tue, 21 Jun 2011 12:40:49 +0530 (IST), krunal patel wrote: > Hi Jean, > Its working now. Thank you very much for your patch. > dmesg output-------------------- > w83627hf: Found W83627HF chip at 0x290 > Using 6-bit VID table for VIA C7-D CPU > > # sensors -------------- > w83627hf-isa-0290 > Adapter: ISA adapter > in0: +0.69 V (min = +0.00 V, max = +4.08 V) > in1: +1.06 V (min = +0.00 V, max = +4.08 V) > in2: +3.30 V (min = +2.82 V, max = +3.79 V) > in3: +2.99 V (min = +3.57 V, max = +1.98 V) ALARM > in4: +3.28 V (min = +1.98 V, max = +4.05 V) > in5: +3.30 V (min = +3.57 V, max = +3.30 V) ALARM > in6: +3.33 V (min = +1.78 V, max = +0.53 V) ALARM > in7: +3.30 V (min = +0.77 V, max = +2.29 V) ALARM > in8: +3.52 V (min = +3.06 V, max = +0.64 V) ALARM > fan1: 0 RPM (min = 13775 RPM, div = 2) ALARM > fan2: 0 RPM (min = -1 RPM, div = 2) ALARM > fan3: 0 RPM (min = 3515 RPM, div = 2) ALARM > temp1: +52.0 C (high = +9.0 C, hyst = +32.0 C) ALARM sensor = thermistor > temp2: +38.5 C (high = +120.0 C, hyst = +115.0 C) sensor = diode > temp3: -48.0 C (high = +120.0 C, hyst = +115.0 C) sensor = thermistor > cpu0_vid: +1.212 V > beep_enable: enabled According to the documentation I have, your CPU should be running at 0.684 V (assuming it is a ULV variant), so in0 is Vcore. It does not match cpu0_vid, but the other possible VID decoding table wouldn't either. So I think that the VID pins are simply not properly routed to your monitoring chip. Ah, stupid me. Of course they aren't. The W83627HF only has 5 VID pins, so you can't route a 6-bit VID value to it... So basically this means that you can ignore the cpu0_vid value reported by the w83627hf driver, it's bogus. Ideally the drivers would notice the mismatch and wouldn't expose a VID value which can't be correct. I don't have the time to fix it now so I've created a support ticket for later: http://www.lm-sensors.org/ticket/2383 Could you please install the msr-tools package, load the msr driver, and run as root: # rdmsr -x 0x198 and report the result. BTW you should also be able to use the via-cputemp driver. Didn't sensors-detect suggest that? > I looked into driver code and hwmon related code. All sensor data is exported to user space using sysfs. > One thing I understood is there is no interrupt mechanism in sensor chip so we need to read data from chip's memory. So for periodic data we need to do polling at userspace (like sensord). Yes, this is correct, except that _some_ devices actually support interrupts. But libsensors currently doesn't support that, and most drivers don't implement it anyway. > Can I implement timer in driver and do polling in Kernel? Technically you certainly can, but I very much doubt that such code would be accepted in the kernel. If polling is necessary, then it is better done in user-space than in the kernel, because user-space can choose the polling set and period depending on the exact needs. If you think that in-kernel polling has an advantage, please argue. > What I want to do is get userspace event only when Alarm is raised. If I implement timer and netlink communication in driver will it be correct way to do it? As I do not find any other way. I am no expert in this area, but I see no reason to go with netlink, it seems to me that poll/select on the relevant alarm files themselves should work. Guenter, I think you discussed this some times ago? Krunal, please also search for "poll notification" in Documentation/hwmon/sysfs-interface. This suggests that a subset of the attributes implement poll support already. I didn't look into this and won't have time to do so, sorry. But again this only applies to devices which raise interrupts on alarm, so that no in-kernel polling is needed. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
