Question about VID

Question about VID

[Mark M. Hoffman]

Hello everyone:

Looks like w83627thf doesn't have dedicated VID pins.  But, it has a
few GPIO pins... some of which just happen to be the same pin #s as
the dedicated VID pins on the w83627hf.  Haven't tried it yet, but I'd
bet money that's how it's wired too.  Any clever ideas about how to
support something like that in the driver?  I'm thinking of just using
some #ifdef's, but that's not very clever.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Question about VID

[Mark Studebaker]

just assume the vid pins are always there.
If they aren't hooked up, it's no different than for any
other chip or driver.
vid is only used for calculation of limits in sensors.conf.
how many people bother to program the correct "VRM" specification
setting anyway, I don't know, probably isn't that high...

Mark M. Hoffman wrote:

> Hello everyone:
> 
> Looks like w83627thf doesn't have dedicated VID pins.  But, it has a
> few GPIO pins... some of which just happen to be the same pin #s as
> the dedicated VID pins on the w83627hf.  Haven't tried it yet, but I'd
> bet money that's how it's wired too.  Any clever ideas about how to
> support something like that in the driver?  I'm thinking of just using
> some #ifdef's, but that's not very clever.
> 
> Regards,
> 

Question about VID

[Mark Studebaker]

but the only way to tell if the pins are used for VID is to
enable VID and see what the value is.
(oops, there is one way, look at the GPIO direction
programming, if they are set for outputs you know they
aren't VID..)

As I said, the driver doesn't use the VID value internally,
only libsensors may use it for calculations of limits,
so it does no harm.

If the VID is bogus, the user can take care of it by ignoring
it in sensors.conf. Why bother telling the driver not
to return the values of the GPIO inputs?


Jean Delvare wrote:
> 
> > just assume the vid pins are always there.
> > If they aren't hooked up, it's no different than for any
> > other chip or driver.
> 
> But if the pins are connected to something else, we'll be claiming a bad
> VID value, which is IMHO worst that clearly stating that VID isn't
> supported for that chip.
> 
> > vid is only used for calculation of limits in sensors.conf.
> > how many people bother to program the correct "VRM" specification
> > setting anyway, I don't know, probably isn't that high...
> 
> Maybe more than you think. From my own experience, few people read docs,
> but much more do read and tweek config files. And I also guess that our
> users are somewhat more experienced ans serious than the average. If
> they made it through the installation process, which isn't an easy one,
> and the detection process, and are finally getting some results, I think
> they are very likely to try fixing incorrect values, either by
> themselves or by asking for help on the mailing-list.
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/

Question about VID

[Jean Delvare]

> Looks like w83627thf doesn't have dedicated VID pins.  But, it has a
> few GPIO pins... some of which just happen to be the same pin #s as
> the dedicated VID pins on the w83627hf.  Haven't tried it yet, but I'd
> bet money that's how it's wired too.  Any clever ideas about how to
> support something like that in the driver?  I'm thinking of just using
> some #ifdef's, but that's not very clever.

You could use a module parameter, for example vid=0 not to use the GPIO
pins and vid=1 to use them in the way you think they are used. This
leaves some place for vid=2, etc... in case new GPIO wirings are
discovered later.

Then you are free to chose whichever default value you think is the
best. I don't have a W83627THF so I can't say.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Question about VID

[Philip Pokorny]

There is something like this in the ADM1026 driver.

The pins are actually GPIO, but the data sheet shows them "typically" 
connected as VID.  So the driver makes a "rash" assumption that they are 
connected as suggested on the datasheet.

But I did two other things.  I allowed the VID value to be *written* to 
override the assumed value, and I export the GPIO pins raw as "gpio" so 
that an expression in sensors.conf can set the vid value from the gpio 
value by bitsifts (multiply and divide by 2) and masking.

:v)

Mark Studebaker wrote:

> just assume the vid pins are always there.
> If they aren't hooked up, it's no different than for any
> other chip or driver.
> vid is only used for calculation of limits in sensors.conf.
> how many people bother to program the correct "VRM" specification
> setting anyway, I don't know, probably isn't that high...
>
> Mark M. Hoffman wrote:
>
>> Hello everyone:
>>
>> Looks like w83627thf doesn't have dedicated VID pins.  But, it has a
>> few GPIO pins... some of which just happen to be the same pin #s as
>> the dedicated VID pins on the w83627hf.  Haven't tried it yet, but I'd
>> bet money that's how it's wired too.  Any clever ideas about how to
>> support something like that in the driver?  I'm thinking of just using
>> some #ifdef's, but that's not very clever.
>>
>> Regards,
>>
>
>

Question about VID

[Jean Delvare]

> just assume the vid pins are always there.
> If they aren't hooked up, it's no different than for any
> other chip or driver.

But if the pins are connected to something else, we'll be claiming a bad
VID value, which is IMHO worst that clearly stating that VID isn't
supported for that chip.

> vid is only used for calculation of limits in sensors.conf.
> how many people bother to program the correct "VRM" specification
> setting anyway, I don't know, probably isn't that high...

Maybe more than you think. From my own experience, few people read docs,
but much more do read and tweek config files. And I also guess that our
users are somewhat more experienced ans serious than the average. If
they made it through the installation process, which isn't an easy one,
and the detection process, and are finally getting some results, I think
they are very likely to try fixing incorrect values, either by
themselves or by asking for help on the mailing-list.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/