* Re: [lm-sensors] Linux drivers
2013-05-16 9:06 [lm-sensors] Linux drivers Van Lembergen, Lieven
@ 2013-05-16 10:53 ` Jean Delvare
2013-05-16 11:37 ` Jean Delvare
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2013-05-16 10:53 UTC (permalink / raw)
To: lm-sensors
Hi Lieven,
On Thu, 16 May 2013 09:06:40 +0000, Van Lembergen, Lieven wrote:
> Hello jean, guenther,
>
> Our customer is using the linux driver for the TMP432, but has some extra problems, hope you can help:
> 2 issues:
> - writing of the max_hyst-field for the last 2 internal sensors
> The files to change values is read only ?can they have access?
There is only one register internally, where the hysteresis is stored
as a relative (or delta) value. So the difference between
temp2_crit_hyst and temp2_crit is always the same as the difference
between temp1_crit_hyst and temp1_crit. Same for temp3_crit_hyst.
That's why only one hyst file is writable.
> - extended temperature enabling without patching the init?? Can that be done?
The driver doesn't yet support the extended temperature format. This
could be added, you can either contribute it as a patch or wait for (or
even sponsor) someone to implement it for you.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [lm-sensors] Linux drivers
2013-05-16 9:06 [lm-sensors] Linux drivers Van Lembergen, Lieven
2013-05-16 10:53 ` Jean Delvare
@ 2013-05-16 11:37 ` Jean Delvare
2013-05-16 15:59 ` Guenter Roeck
2013-05-16 16:59 ` Guenter Roeck
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2013-05-16 11:37 UTC (permalink / raw)
To: lm-sensors
On Thu, 16 May 2013 12:53:09 +0200, Jean Delvare wrote:
> On Thu, 16 May 2013 09:06:40 +0000, Van Lembergen, Lieven wrote:
> > - extended temperature enabling without patching the init?? Can that be done?
>
> The driver doesn't yet support the extended temperature format. This
> could be added, you can either contribute it as a patch or wait for (or
> even sponsor) someone to implement it for you.
Sorry, I meant: setting (or clearing) the extended temperature format
is not supported. The extended temperature format itself is supported
already.
The proper mode is supposed to have been set by the BIOS/firmware. If
for some reason this doesn't work for you, the proper way would be to
pass the setting as platform data when you instantiate the device. If
for some reason you can't do that, you can overwrite the configuration
register using i2cset (from package i2c-tools) and the i2c-dev driver,
before the tmp401 driver gets loaded.
We _could_ add a module parameter or a sysfs attribute to select it,
but this means extra code in the driver, and caution is needed because
the value of many registers depend on the format so we would have to
update them all at once to preserve existing settings. A module
parameter would be suboptimal because all chips handled by the driver
would need to have the same setting.
Yet another approach would be to auto-select the range depending on
which limits are set. This means even more code, but has the advantage
to not introduce a new interface.
Guenter, what do you think?
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] Linux drivers
2013-05-16 9:06 [lm-sensors] Linux drivers Van Lembergen, Lieven
2013-05-16 10:53 ` Jean Delvare
2013-05-16 11:37 ` Jean Delvare
@ 2013-05-16 15:59 ` Guenter Roeck
2013-05-16 16:59 ` Guenter Roeck
3 siblings, 0 replies; 5+ messages in thread
From: Guenter Roeck @ 2013-05-16 15:59 UTC (permalink / raw)
To: lm-sensors
On Thu, May 16, 2013 at 01:37:11PM +0200, Jean Delvare wrote:
> On Thu, 16 May 2013 12:53:09 +0200, Jean Delvare wrote:
> > On Thu, 16 May 2013 09:06:40 +0000, Van Lembergen, Lieven wrote:
> > > - extended temperature enabling without patching the init?? Can that be done?
> >
> > The driver doesn't yet support the extended temperature format. This
> > could be added, you can either contribute it as a patch or wait for (or
> > even sponsor) someone to implement it for you.
>
> Sorry, I meant: setting (or clearing) the extended temperature format
> is not supported. The extended temperature format itself is supported
> already.
>
> The proper mode is supposed to have been set by the BIOS/firmware. If
> for some reason this doesn't work for you, the proper way would be to
> pass the setting as platform data when you instantiate the device. If
> for some reason you can't do that, you can overwrite the configuration
> register using i2cset (from package i2c-tools) and the i2c-dev driver,
> before the tmp401 driver gets loaded.
>
> We _could_ add a module parameter or a sysfs attribute to select it,
> but this means extra code in the driver, and caution is needed because
> the value of many registers depend on the format so we would have to
> update them all at once to preserve existing settings. A module
> parameter would be suboptimal because all chips handled by the driver
> would need to have the same setting.
>
> Yet another approach would be to auto-select the range depending on
> which limits are set. This means even more code, but has the advantage
> to not introduce a new interface.
>
> Guenter, what do you think?
>
I dislike module parameters, as those would apply to all instances
of the driver.
I like the idea of auto-selecting the range based on specified limits.
It would be quite flexible, though require some careful coding.
Question is if it is really needed and valuable enough to go through
the trouble of implementing and testing it.
If the platform supports devicetree, another option would be to define
a devicetree property for selecting the range. That would be done during
initialization and thus be much simpler than auto-selecting it.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] Linux drivers
2013-05-16 9:06 [lm-sensors] Linux drivers Van Lembergen, Lieven
` (2 preceding siblings ...)
2013-05-16 15:59 ` Guenter Roeck
@ 2013-05-16 16:59 ` Guenter Roeck
3 siblings, 0 replies; 5+ messages in thread
From: Guenter Roeck @ 2013-05-16 16:59 UTC (permalink / raw)
To: lm-sensors
Resending, as the previous one was rejected by some recipients due to
spam block issues (which should hopefully be resolved by now).
On Thu, May 16, 2013 at 01:37:11PM +0200, Jean Delvare wrote:
> On Thu, 16 May 2013 12:53:09 +0200, Jean Delvare wrote:
> > On Thu, 16 May 2013 09:06:40 +0000, Van Lembergen, Lieven wrote:
> > > - extended temperature enabling without patching the init?? Can that be done?
> >
> > The driver doesn't yet support the extended temperature format. This
> > could be added, you can either contribute it as a patch or wait for (or
> > even sponsor) someone to implement it for you.
>
> Sorry, I meant: setting (or clearing) the extended temperature format
> is not supported. The extended temperature format itself is supported
> already.
>
> The proper mode is supposed to have been set by the BIOS/firmware. If
> for some reason this doesn't work for you, the proper way would be to
> pass the setting as platform data when you instantiate the device. If
> for some reason you can't do that, you can overwrite the configuration
> register using i2cset (from package i2c-tools) and the i2c-dev driver,
> before the tmp401 driver gets loaded.
>
> We _could_ add a module parameter or a sysfs attribute to select it,
> but this means extra code in the driver, and caution is needed because
> the value of many registers depend on the format so we would have to
> update them all at once to preserve existing settings. A module
> parameter would be suboptimal because all chips handled by the driver
> would need to have the same setting.
>
> Yet another approach would be to auto-select the range depending on
> which limits are set. This means even more code, but has the advantage
> to not introduce a new interface.
>
> Guenter, what do you think?
>
I dislike module parameters, as those would apply to all instances
of the driver.
I like the idea of auto-selecting the range based on specified limits.
It would be quite flexible, though require some careful coding.
Question is if it is really needed and valuable enough to go through
the trouble of implementing and testing it.
If the platform supports devicetree, another option would be to define
a devicetree property for selecting the range. That would be done during
initialization and thus be much simpler than auto-selecting it.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread