Hi Guenter, What I understood is, driver must implement interrupt handler (if chip supports) which will update sysfs files which are read from userspace using select. Can you give me sample code regarding this. I will try at my end. Best Regards, Krunal Patel --- On Tue, 21/6/11, Guenter Roeck <guenter.roeck@xxxxxxxxxxxx> wrote: > From: Guenter Roeck <guenter.roeck@xxxxxxxxxxxx> > Subject: Re: sensor details for W83627HG-AW > To: "Jean Delvare" <khali@xxxxxxxxxxxx> > Cc: "krunal patel" <krunal_smiles@xxxxxxxxx>, "lm-sensors@xxxxxxxxxxxxxx" <lm-sensors@xxxxxxxxxxxxxx> > Date: Tuesday, 21 June, 2011, 5:29 PM > 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
