* [lm-sensors] Re: [PATCH] hwmon : Fix W83627THF VID reading
2005-11-15 10:26 [lm-sensors] [PATCH] hwmon : Fix W83627THF VID reading Ymu
@ 2005-11-15 11:30 ` Jean Delvare
2005-11-20 22:40 ` Mark M. Hoffman
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2005-11-15 11:30 UTC (permalink / raw)
To: lm-sensors
Hi Yuan,
> This patch fixes the VID reading; no cpu0_vid and vrm files created if
> the chip is w83627thf and GPIO5 not enabled.
> Please check.
Looks good to me. I had to fix the patch manually this time again though.
I have done three minor edits to your patch, I hope you won't mind:
1* I think the following test:
+ if (kind != w83697hf &&
+ !(kind = w83627thf && data->vid = 0xff)) {
Can be simplified to:
+ if (kind != w83697hf && data->vid != 0xff)) {
Because data->vid can only have value 0xff for type w83627thf anyway.
2* In w83627thf_read_gpio5, I did:
- sel = superio_inb(W83627THF_GPIO5_IOSR);
+ sel = superio_inb(W83627THF_GPIO5_IOSR) & 0x3f;
The datasheet suggests that the two unused bits of register CRF4
(W83627THF_GPIO5_DR) are always zero, but better safe than sorry.
3* I dropped "default" in that comment:
/* Convert VID to voltage based on default VRM */
It's not more a default value, it's deduced from the CPU model.
I'll stack your patch and will get it into -mm soon so that it gets some
testing. It should then go into mainline for 2.6.16. Thanks for your
contribution!
While checking the W83627THF datasheet, I noticed that there is an
additional GPIO configuration register, CRF5, named "inversion
register". Wouldn't it make sense to check the value of this register
and make sure all pins supposedly used as VID inputs are not inverted?
Mark, can you please confirm that your system which does use GPIO5 for
VID would pass that test? Proposed patch attached, comments and testers
welcome.
Thanks,
--
Jean Delvare
-------------- next part --------------
Improve the W83627THF GPIO5 testing, so that we don't think these pins
are used as VID inputs when they cannot be. This is done by checking
that none of these pins are in inverted mode.
---
drivers/hwmon/w83627hf.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.15-rc1.orig/drivers/hwmon/w83627hf.c 2005-11-15 11:03:52.000000000 +0100
+++ linux-2.6.15-rc1/drivers/hwmon/w83627hf.c 2005-11-15 11:19:49.000000000 +0100
@@ -99,6 +99,7 @@
#define W83627THF_GPIO5_EN 0x30 /* w83627thf only */
#define W83627THF_GPIO5_IOSR 0xf3 /* w83627thf only */
#define W83627THF_GPIO5_DR 0xf4 /* w83627thf only */
+#define W83627THF_GPIO5_INV 0xf5 /* w83627thf only */
static inline void
superio_outb(int reg, int val)
@@ -1218,7 +1219,7 @@
static int w83627thf_read_gpio5(struct i2c_client *client)
{
- int res = 0xff, sel;
+ int res = 0xff, sel, inv;
superio_enter();
superio_select(W83627HF_LD_GPIO5);
@@ -1232,7 +1233,8 @@
/* Make sure the pins are configured for input
There must be at least five (VRM 9), and possibly 6 (VRM 10) */
sel = superio_inb(W83627THF_GPIO5_IOSR) & 0x3f;
- if ((sel & 0x1f) != 0x1f) {
+ inv = superio_inb(W83627THF_GPIO5_INV) & 0x3f;
+ if ((sel & 0x1f) != 0x1f || (inv & sel) != 0x00) {
dev_dbg(&client->dev, "GPIO5 not configured for VID "
"function\n");
goto exit;
^ permalink raw reply [flat|nested] 5+ messages in thread* [lm-sensors] Re: [PATCH] hwmon : Fix W83627THF VID reading
2005-11-15 10:26 [lm-sensors] [PATCH] hwmon : Fix W83627THF VID reading Ymu
2005-11-15 11:30 ` [lm-sensors] " Jean Delvare
@ 2005-11-20 22:40 ` Mark M. Hoffman
2005-11-21 10:53 ` Jean Delvare
2005-11-26 15:55 ` Jean Delvare
3 siblings, 0 replies; 5+ messages in thread
From: Mark M. Hoffman @ 2005-11-20 22:40 UTC (permalink / raw)
To: lm-sensors
Hi Jean:
* Jean Delvare <khali@linux-fr.org> [2005-11-15 12:16:52 +0200]:
> While checking the W83627THF datasheet, I noticed that there is an
> additional GPIO configuration register, CRF5, named "inversion
> register". Wouldn't it make sense to check the value of this register
> and make sure all pins supposedly used as VID inputs are not inverted?
> Mark, can you please confirm that your system which does use GPIO5 for
> VID would pass that test? Proposed patch attached, comments and testers
> welcome.
Your patch does work on my system, but... no, I don't think it means anything
if the inputs are inverted or not. The BIOS might set the inputs to inverted
if the VID signals are inverted by hardware... which I would not consider to
be unusual or unexpected.
Of course, it might just as well leave them *not* inverted *despite* that
they are inverted in hardware... which suggests a new module option if anyone
ever discovers such a board.
BTW: I tested by applying your current quilt stack (up to and including the
improve-gpio5-test patch) to 2.6.15-rc2.
Regards,
--
Mark M. Hoffman
mhoffman@lightlink.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* [lm-sensors] Re: [PATCH] hwmon : Fix W83627THF VID reading
2005-11-15 10:26 [lm-sensors] [PATCH] hwmon : Fix W83627THF VID reading Ymu
2005-11-15 11:30 ` [lm-sensors] " Jean Delvare
2005-11-20 22:40 ` Mark M. Hoffman
@ 2005-11-21 10:53 ` Jean Delvare
2005-11-26 15:55 ` Jean Delvare
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2005-11-21 10:53 UTC (permalink / raw)
To: lm-sensors
Hi Mark,
On 2005-11-20, Mark M. Hoffman wrote:
> * Jean Delvare [2005-11-15 12:16:52 +0200]:
> > While checking the W83627THF datasheet, I noticed that there is an
> > additional GPIO configuration register, CRF5, named "inversion
> > register". Wouldn't it make sense to check the value of this register
> > and make sure all pins supposedly used as VID inputs are not inverted?
> > Mark, can you please confirm that your system which does use GPIO5 for
> > VID would pass that test? Proposed patch attached, comments and testers
> > welcome.
>
> Your patch does work on my system, but... no, I don't think it means
> anything if the inputs are inverted or not. The BIOS might set the inputs
> to inverted if the VID signals are inverted by hardware... which I would
> not consider to be unusual or unexpected.
I do consider it to be unexpected. The W83627HF cannot invert these pins
as far as I know, so if the W83627THF is supposed to be used as a
replacement for the W83627HF, the GPIO pins shouldn't be inverted.
Additionally, the VID signals are supposed to come directly from the
CPU, and if they do they cannot be inverted.
> Of course, it might just as well leave them *not* inverted *despite* that
> they are inverted in hardware... which suggests a new module option if
> anyone ever discovers such a board.
That would be a different problem (getting the proper value, as opposed
to properly guessing if the pins are used as VID inputs), although the
same reasons I gave above make me doubt this could actually happen.
> BTW: I tested by applying your current quilt stack (up to and including
> the improve-gpio5-test patch) to 2.6.15-rc2.
Great, thanks. I'll probably push upwards a part of it this week so that
it gets a broader testing in -mm.
--
Jean Delvare
^ permalink raw reply [flat|nested] 5+ messages in thread
* [lm-sensors] Re: [PATCH] hwmon : Fix W83627THF VID reading
2005-11-15 10:26 [lm-sensors] [PATCH] hwmon : Fix W83627THF VID reading Ymu
` (2 preceding siblings ...)
2005-11-21 10:53 ` Jean Delvare
@ 2005-11-26 15:55 ` Jean Delvare
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2005-11-26 15:55 UTC (permalink / raw)
To: lm-sensors
Hi again Mark,
> > Your patch does work on my system, but... no, I don't think it means
> > anything if the inputs are inverted or not. The BIOS might set the inputs
> > to inverted if the VID signals are inverted by hardware... which I would
> > not consider to be unusual or unexpected.
>
> I do consider it to be unexpected. The W83627HF cannot invert these pins
> as far as I know, so if the W83627THF is supposed to be used as a
> replacement for the W83627HF, the GPIO pins shouldn't be inverted.
> Additionally, the VID signals are supposed to come directly from the
> CPU, and if they do they cannot be inverted.
On second though, you're right. We just can't assume anything. I've
backed out the patch I had proposed.
> Great, thanks. I'll probably push upwards a part of it this week so that
> it gets a broader testing in -mm.
I'll do later this afternoon, BTW.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 5+ messages in thread