On Tue, Jun 21, 2011 at 07:50:50AM -0400, Jean Delvare wrote: > 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? > Yes it does, assuming the driver performs some activity on those files, ie supports interrupts which trigger a file event. It is on my plate to update some of the hwmon drivers to support it, but I did not yet have the time to do it. > 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. > Exactly. Thanks, Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
