[lm-sensors] sensor details for W83627HG-AW

krunal patel krunal_smiles at yahoo.com
Wed Jun 22 10:22:53 CEST 2011


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 at ericsson.com> wrote:

> From: Guenter Roeck <guenter.roeck at ericsson.com>
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> To: "Jean Delvare" <khali at linux-fr.org>
> Cc: "krunal patel" <krunal_smiles at yahoo.com>, "lm-sensors at lm-sensors.org" <lm-sensors at lm-sensors.org>
> 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
> 




More information about the lm-sensors mailing list