Re: [lm-sensors] sensor details for W83627HG-AW

[krunal patel <krunal_smiles@yahoo.com>]

Jean,

Thank you very much for your support and explanation. Please find my comments in line.

Best Regards,
Krunal Patel


--- On Tue, 21/6/11, Jean Delvare <khali@linux-fr.org> wrote:

> From: Jean Delvare <khali@linux-fr.org>
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> To: "krunal patel" <krunal_smiles@yahoo.com>
> Cc: lm-sensors@lm-sensors.org, "Guenter Roeck" <guenter.roeck@ericsson.com>
> Date: Tuesday, 21 June, 2011, 5:20 PM
> 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.
> 
Following is output you asked for
# rdmsr -x 0x198        
400050004000500

> BTW you should also be able to use the via-cputemp driver.
> Didn't
> sensors-detect suggest that?
> 
I didn't used sensors-detect because it was wasting my time in resolving perl issues in my system. So I opened case, located chip and loaded related module.
> > 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.
> 
I thought kernel timer is lighter then application in userspace. 
> > 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.
> 
I am not find related info in linux-2.6.27.45, I will look in latest version.
> 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@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors