[lm-sensors] Displaying Voltage as Temperature?!?

[lm-sensors] Displaying Voltage as Temperature?!?

[Chris Pattenden]

Howdy.

I have a thermistor connected to a voltage sensing port (in0_input) on 
my ADC chip. I have everything running (i.e, /etc/sensors.conf has the 
voltage->temperature conversion curve programmed into a 'convert' line 
and 'sensors' is displaying the correct temperature) but the temperature 
is being displayed as "+21.0 V". Obviously, I'd like to display "+21.0 C".

Is there any way to force sensors to display the reading as a 
temperature without rewriting my ADC driver to fake a temperature 
sensing device (which it isn't)?

Thanks,
Chris




_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Displaying Voltage as Temperature?!?

[Guenter Roeck]

On Mon, Jul 08, 2013 at 10:15:42AM -0400, Chris Pattenden wrote:
> Howdy.
> 
> I have a thermistor connected to a voltage sensing port (in0_input)
> on my ADC chip. I have everything running (i.e, /etc/sensors.conf
> has the voltage->temperature conversion curve programmed into a
> 'convert' line and 'sensors' is displaying the correct temperature)
> but the temperature is being displayed as "+21.0 V". Obviously, I'd
> like to display "+21.0 C".
> 
> Is there any way to force sensors to display the reading as a
> temperature without rewriting my ADC driver to fake a temperature
> sensing device (which it isn't)?
> 
Short answer is no.

One possibility might be to implement your ADC driver as iio driver
and then use the ntc_thermistor driver. That would require OF support
in your platform, though, and might make it necessary to add another
set of tables to the ntc_thermistor driver if you use a different
thermistor.

It might also be possible to tell an iio driver that a specific channel
is connected to a thermistor, and ask it to return a temperature instead
of a voltage. In that case you could use an iio driver and connect it to
iio_hwmon. I don't know enough about iio to know for sure and/or to
provide details, though.

A third option would be to enhance libsensors to add support for the
functionality you are asking for (ie replace one sensor type with another
via configuration file). There is actually a ticket open for that:
	http://www.lm-sensors.org/ticket/2258

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[lm-sensors] Bug Report: Bus substitution causing a problem

[Chris Pattenden]

Howdy,

I'm working to configure lm_sensors and have notice a few strange issues.

I'm working on a TI 8148 on custom hardware.
Linux 2.6.37
lm_sensors lm_sensors-3.3.4

i2cdetect -l shows the following:

	i2c-2   i2c             OMAP I2C adapter                        I2C adapter
	i2c-4   i2c             OMAP I2C adapter                        I2C adapter



I have two TI ADC128D818 ADCs (I cobbled together my own driver while 
waiting for support -- I see that someone else requested the same driver 
last week :-). They are:
	adc128d818-i2c-4-1d
	adc128d818-i2c-4-37

	
"sensors --bus-list" shows the following:
	bus "i2c-4" "OMAP I2C adapter"
Why bus i2c-2 isn't shown, I don't know. That's likely an issue.


I started using the following sensors.conf:
	chip "adc128d818-i2c-4-1d"
	label in0 "Test"

However, I was told that the "bus was unidentified".
I used the following sensors.conf, hoping to fix the problem:
	bus "i2c-4" "OMAP I2C adapter"
	chip "adc128d818-i2c-4-1d"
	label in0 "Test"
However, none in0 was not renamed as expected -- it printed as "in0".

It turns out that sensors_substitute_busses() incorrectly renumbers 
adc128d818-i2c-4-1d to adc128d818-i2c-2-1d and then can't find the 
labels. If I use the following sensors.conf (or comment out the call to 
sensors_substitute_busses()), sensors works as expected:
	chip "adc128d818-i2c-*-1d"
	label in0 "Test"

Am I doing something wrong or is there something strange going on with 
the bus renaming. What is the point of the bus renaming?

Thanks,
Chris


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Bug Report: Bus substitution causing a problem

[Jean Delvare]

Hi Chris,

On Mon, 08 Jul 2013 17:18:46 -0400, Chris Pattenden wrote:
> I'm working to configure lm_sensors and have notice a few strange issues.
> 
> I'm working on a TI 8148 on custom hardware.
> Linux 2.6.37
> lm_sensors lm_sensors-3.3.4
> 
> i2cdetect -l shows the following:
> 
> 	i2c-2   i2c             OMAP I2C adapter                        I2C adapter
> 	i2c-4   i2c             OMAP I2C adapter                        I2C adapter
> 
> 
> 
> I have two TI ADC128D818 ADCs (I cobbled together my own driver while 
> waiting for support -- I see that someone else requested the same driver 
> last week :-). They are:
> 	adc128d818-i2c-4-1d
> 	adc128d818-i2c-4-37
> 
> 	
> "sensors --bus-list" shows the following:
> 	bus "i2c-4" "OMAP I2C adapter"
> Why bus i2c-2 isn't shown, I don't know. That's likely an issue.

No it's not. sensors --bus-list only lists the relevant buses - the
ones with at least one hwmon chip. There's no chip on i2c-2, so it's
not listed.

> I started using the following sensors.conf:
> 	chip "adc128d818-i2c-4-1d"
> 	label in0 "Test"
> 
> However, I was told that the "bus was unidentified".
> I used the following sensors.conf, hoping to fix the problem:
> 	bus "i2c-4" "OMAP I2C adapter"
> 	chip "adc128d818-i2c-4-1d"
> 	label in0 "Test"
> However, none in0 was not renamed as expected -- it printed as "in0".
> 
> It turns out that sensors_substitute_busses() incorrectly renumbers 
> adc128d818-i2c-4-1d to adc128d818-i2c-2-1d and then can't find the 
> labels.

The problem here is that your i2c bus driver is evil and attributes the
same name to two different buses. It should not do that. This is a bug
in the i2c-omap driver. It should give each bus a distinct name, for
example by including the base I/O address in it.

> If I use the following sensors.conf (or comment out the call to 
> sensors_substitute_busses()), sensors works as expected:
> 	chip "adc128d818-i2c-*-1d"
> 	label in0 "Test"

Yes, this works because you don't actually need a bus statement in your
case.  It is only needed if the same I2C address is used by the same
chip type on two or more I2C buses. In your case the bus type and the
I2C address are sufficient to uniquely identify each chip.

> Am I doing something wrong or is there something strange going on with 
> the bus renaming. What is the point of the bus renaming?

As explained in the manual page, the I2C bus numbers are not guaranteed
to be stable across reboots, while I2C bus names are. But of course the
whole logic assumes unique I2C bus names, and you don't have that on
your system at the moment.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Bug Report: Bus substitution causing a problem

[Guenter Roeck]

On Tue, Jul 09, 2013 at 12:00:13AM +0200, Jean Delvare wrote:
> Hi Chris,
> 
> On Mon, 08 Jul 2013 17:18:46 -0400, Chris Pattenden wrote:
> > I'm working to configure lm_sensors and have notice a few strange issues.
> > 
> > I'm working on a TI 8148 on custom hardware.
> > Linux 2.6.37
> > lm_sensors lm_sensors-3.3.4
> > 
> > i2cdetect -l shows the following:
> > 
> > 	i2c-2   i2c             OMAP I2C adapter                        I2C adapter
> > 	i2c-4   i2c             OMAP I2C adapter                        I2C adapter
> > 
> > 
> > 
> > I have two TI ADC128D818 ADCs (I cobbled together my own driver while 
> > waiting for support -- I see that someone else requested the same driver 
> > last week :-). They are:
> > 	adc128d818-i2c-4-1d
> > 	adc128d818-i2c-4-37
> > 
> > 	
> > "sensors --bus-list" shows the following:
> > 	bus "i2c-4" "OMAP I2C adapter"
> > Why bus i2c-2 isn't shown, I don't know. That's likely an issue.
> 
> No it's not. sensors --bus-list only lists the relevant buses - the
> ones with at least one hwmon chip. There's no chip on i2c-2, so it's
> not listed.
> 
> > I started using the following sensors.conf:
> > 	chip "adc128d818-i2c-4-1d"
> > 	label in0 "Test"
> > 
> > However, I was told that the "bus was unidentified".
> > I used the following sensors.conf, hoping to fix the problem:
> > 	bus "i2c-4" "OMAP I2C adapter"
> > 	chip "adc128d818-i2c-4-1d"
> > 	label in0 "Test"
> > However, none in0 was not renamed as expected -- it printed as "in0".
> > 
> > It turns out that sensors_substitute_busses() incorrectly renumbers 
> > adc128d818-i2c-4-1d to adc128d818-i2c-2-1d and then can't find the 
> > labels.
> 
> The problem here is that your i2c bus driver is evil and attributes the
> same name to two different buses. It should not do that. This is a bug
> in the i2c-omap driver. It should give each bus a distinct name, for
> example by including the base I/O address in it.
> 
Unfortunately it is not the only such driver.

Same output on P2020:

i2c-0   i2c             MPC adapter                             I2C adapter
i2c-1   i2c             MPC adapter                             I2C adapter

And on P5040:

i2c-0   i2c             MPC adapter                             I2C adapter
i2c-1   i2c             MPC adapter                             I2C adapter
i2c-2   i2c             MPC adapter                             I2C adapter
i2c-3   i2c             MPC adapter                             I2C adapter

Question is ... would a patch to fix that be accepted by the i2c maintainers ?

Guenter

Re: [lm-sensors] Bug Report: Bus substitution causing a problem

[Guenter Roeck]

On Tue, Jul 09, 2013 at 12:00:13AM +0200, Jean Delvare wrote:
> Hi Chris,
> 
> On Mon, 08 Jul 2013 17:18:46 -0400, Chris Pattenden wrote:
> > I'm working to configure lm_sensors and have notice a few strange issues.
> > 
> > I'm working on a TI 8148 on custom hardware.
> > Linux 2.6.37
> > lm_sensors lm_sensors-3.3.4
> > 
> > i2cdetect -l shows the following:
> > 
> > 	i2c-2   i2c             OMAP I2C adapter                        I2C adapter
> > 	i2c-4   i2c             OMAP I2C adapter                        I2C adapter
> > 
> > 
> > 
> > I have two TI ADC128D818 ADCs (I cobbled together my own driver while 
> > waiting for support -- I see that someone else requested the same driver 
> > last week :-). They are:
> > 	adc128d818-i2c-4-1d
> > 	adc128d818-i2c-4-37
> > 
> > 	
> > "sensors --bus-list" shows the following:
> > 	bus "i2c-4" "OMAP I2C adapter"
> > Why bus i2c-2 isn't shown, I don't know. That's likely an issue.
> 
> No it's not. sensors --bus-list only lists the relevant buses - the
> ones with at least one hwmon chip. There's no chip on i2c-2, so it's
> not listed.
> 
> > I started using the following sensors.conf:
> > 	chip "adc128d818-i2c-4-1d"
> > 	label in0 "Test"
> > 
> > However, I was told that the "bus was unidentified".
> > I used the following sensors.conf, hoping to fix the problem:
> > 	bus "i2c-4" "OMAP I2C adapter"
> > 	chip "adc128d818-i2c-4-1d"
> > 	label in0 "Test"
> > However, none in0 was not renamed as expected -- it printed as "in0".
> > 
> > It turns out that sensors_substitute_busses() incorrectly renumbers 
> > adc128d818-i2c-4-1d to adc128d818-i2c-2-1d and then can't find the 
> > labels.
> 
> The problem here is that your i2c bus driver is evil and attributes the
> same name to two different buses. It should not do that. This is a bug
> in the i2c-omap driver. It should give each bus a distinct name, for
> example by including the base I/O address in it.
> 
Unfortunately it is not the only such driver.

Same output on P2020:

i2c-0   i2c             MPC adapter                             I2C adapter
i2c-1   i2c             MPC adapter                             I2C adapter

And on P5040:

i2c-0   i2c             MPC adapter                             I2C adapter
i2c-1   i2c             MPC adapter                             I2C adapter
i2c-2   i2c             MPC adapter                             I2C adapter
i2c-3   i2c             MPC adapter                             I2C adapter

Question is ... would a patch to fix that be accepted by the i2c maintainers ?

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Bug Report: Bus substitution causing a problem

[Jean Delvare]

On Mon, 8 Jul 2013 15:27:32 -0700, Guenter Roeck wrote:
> On Tue, Jul 09, 2013 at 12:00:13AM +0200, Jean Delvare wrote:
> > The problem here is that your i2c bus driver is evil and attributes the
> > same name to two different buses. It should not do that. This is a bug
> > in the i2c-omap driver. It should give each bus a distinct name, for
> > example by including the base I/O address in it.
>
> Unfortunately it is not the only such driver.
> 
> Same output on P2020:
> 
> i2c-0   i2c             MPC adapter                             I2C adapter
> i2c-1   i2c             MPC adapter                             I2C adapter
> 
> And on P5040:
> 
> i2c-0   i2c             MPC adapter                             I2C adapter
> i2c-1   i2c             MPC adapter                             I2C adapter
> i2c-2   i2c             MPC adapter                             I2C adapter
> i2c-3   i2c             MPC adapter                             I2C adapter
> 
> Question is ... would a patch to fix that be accepted by the i2c maintainers ?

I think it would, yes, as long as you explain why it is needed.

-- 
Jean Delvare

Re: [lm-sensors] Bug Report: Bus substitution causing a problem

[Jean Delvare]

On Mon, 8 Jul 2013 15:27:32 -0700, Guenter Roeck wrote:
> On Tue, Jul 09, 2013 at 12:00:13AM +0200, Jean Delvare wrote:
> > The problem here is that your i2c bus driver is evil and attributes the
> > same name to two different buses. It should not do that. This is a bug
> > in the i2c-omap driver. It should give each bus a distinct name, for
> > example by including the base I/O address in it.
>
> Unfortunately it is not the only such driver.
> 
> Same output on P2020:
> 
> i2c-0   i2c             MPC adapter                             I2C adapter
> i2c-1   i2c             MPC adapter                             I2C adapter
> 
> And on P5040:
> 
> i2c-0   i2c             MPC adapter                             I2C adapter
> i2c-1   i2c             MPC adapter                             I2C adapter
> i2c-2   i2c             MPC adapter                             I2C adapter
> i2c-3   i2c             MPC adapter                             I2C adapter
> 
> Question is ... would a patch to fix that be accepted by the i2c maintainers ?

I think it would, yes, as long as you explain why it is needed.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors