Hi,
i have a temperature sensor device named "TI TMP461" which is quite the
same than the tmp451 which is already included in the lm90 driver.
I just want to add the tmp461 to the driver but currently i have no way
to differ between the tmp461 and tmp451.
The main different is that the tmp461 address can be configured by to Pins
whereas the tmp451 has a fixed address.
The register layout is quite the same except that the tmp461 has one
register more (0x16 Channel Enable Register).
Every zero bit is the same for both bits, so we cannot use these bits for
identification.
Does anybody of you have a tmp451 to read out the register 0x16 (which is
not implement but i expect a value). May be we can use this to
identify the tmp461.
Regards
Andy
On 12/10/2015 04:08 AM, Andreas Werner wrote:
> Hi,
> i have a temperature sensor device named "TI TMP461" which is quite the
> same than the tmp451 which is already included in the lm90 driver.
>
> I just want to add the tmp461 to the driver but currently i have no way
> to differ between the tmp461 and tmp451.
>
> The main different is that the tmp461 address can be configured by to Pins
> whereas the tmp451 has a fixed address.
>
> The register layout is quite the same except that the tmp461 has one
> register more (0x16 Channel Enable Register).
>
> Every zero bit is the same for both bits, so we cannot use these bits for
> identification.
>
> Does anybody of you have a tmp451 to read out the register 0x16 (which is
> not implement but i expect a value). May be we can use this to
> identify the tmp461.
>
Here is a register dump.
00: 5d 69 00 04 08 bf 00 ff 53 00 00 00 00 00 00 00 ]i.???..S.......
10: a0 00 00 00 00 f0 00 00 00 a9 00 00 00 00 00 00 ?....?...?......
20: b8 0a 01 00 00 XX 00 00 00 00 0e 00 00 00 00 00 ???..X....?.....
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00 ..............U.
there is nothing to distinguish the two chips as far as I can see.
Is your system a devicetree system ? If so, you can just
provide a compatible statement such as
compatible = "ti,tmp461", "ti,tmp451";
or simply instantiate the chip as tmp451.
Feel free to provide a patch adding '{ "tmp461", tmp451 },'
to lm90_id as well as the necessary documentation, but I don't
think there is anything we can do to detect the chip.
On the other side, I am a bit concerned that the chip detection doesn't
work well, since the chip ID register is really unsupported and just happens
to return 0 for both chips. I wonder if there are other TI chips which may
be mis-detected as TMP451.
Thanks,
Guenter
On Thu, Dec 10, 2015 at 08:41:57AM -0800, Guenter Roeck wrote:
> On 12/10/2015 04:08 AM, Andreas Werner wrote:
> >Hi,
> >i have a temperature sensor device named "TI TMP461" which is quite the
> >same than the tmp451 which is already included in the lm90 driver.
> >
> >I just want to add the tmp461 to the driver but currently i have no way
> >to differ between the tmp461 and tmp451.
> >
> >The main different is that the tmp461 address can be configured by to Pins
> >whereas the tmp451 has a fixed address.
> >
> >The register layout is quite the same except that the tmp461 has one
> >register more (0x16 Channel Enable Register).
> >
> >Every zero bit is the same for both bits, so we cannot use these bits for
> >identification.
> >
> >Does anybody of you have a tmp451 to read out the register 0x16 (which is
> >not implement but i expect a value). May be we can use this to
> >identify the tmp461.
> >
>
> Here is a register dump.
>
> 00: 5d 69 00 04 08 bf 00 ff 53 00 00 00 00 00 00 00 ]i.???..S.......
> 10: a0 00 00 00 00 f0 00 00 00 a9 00 00 00 00 00 00 ?....?...?......
> 20: b8 0a 01 00 00 XX 00 00 00 00 0e 00 00 00 00 00 ???..X....?.....
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00 ..............U.
>
> there is nothing to distinguish the two chips as far as I can see.
> Is your system a devicetree system ? If so, you can just
> provide a compatible statement such as
> compatible = "ti,tmp461", "ti,tmp451";
> or simply instantiate the chip as tmp451.
>
> Feel free to provide a patch adding '{ "tmp461", tmp451 },'
> to lm90_id as well as the necessary documentation, but I don't
> think there is anything we can do to detect the chip.
>
> On the other side, I am a bit concerned that the chip detection doesn't
> work well, since the chip ID register is really unsupported and just happens
> to return 0 for both chips. I wonder if there are other TI chips which may
> be mis-detected as TMP451.
>
> Thanks,
> Guenter
>
Hi,
thanks for the register dump :-)
There is one difference. The temperature ranges differ:
TMP451:
Standard Mode: 0 to +127
Extended Mode: -64 to +191
TMP461:
Standard Mode: -40 to +127
Extended Mode: -64 to +191
Therefore the calcualtion is different then the tmp451 one.
I also aggree with you with the magical ID register. I hate such
kind of register with are not documented and may have a value.
I have a DT based board yes, but i have also planed to submit my changes
and also wanted to implement the autodetection of the chip.
I have also planned (or need) to implement the "n-Factor Correction" for the
CPU diodes. There is a register to set this value in the tmp451 and tmp461.
Would that make sense to add a DT property for the driver to be able
to set this value? What do you think?
Regards
Andy
On 12/10/2015 09:12 AM, Andreas Werner wrote:
> On Thu, Dec 10, 2015 at 08:41:57AM -0800, Guenter Roeck wrote:
>> On 12/10/2015 04:08 AM, Andreas Werner wrote:
>>> Hi,
>>> i have a temperature sensor device named "TI TMP461" which is quite the
>>> same than the tmp451 which is already included in the lm90 driver.
>>>
>>> I just want to add the tmp461 to the driver but currently i have no way
>>> to differ between the tmp461 and tmp451.
>>>
>>> The main different is that the tmp461 address can be configured by to Pins
>>> whereas the tmp451 has a fixed address.
>>>
>>> The register layout is quite the same except that the tmp461 has one
>>> register more (0x16 Channel Enable Register).
>>>
>>> Every zero bit is the same for both bits, so we cannot use these bits for
>>> identification.
>>>
>>> Does anybody of you have a tmp451 to read out the register 0x16 (which is
>>> not implement but i expect a value). May be we can use this to
>>> identify the tmp461.
>>>
>>
>> Here is a register dump.
>>
>> 00: 5d 69 00 04 08 bf 00 ff 53 00 00 00 00 00 00 00 ]i.???..S.......
>> 10: a0 00 00 00 00 f0 00 00 00 a9 00 00 00 00 00 00 ?....?...?......
>> 20: b8 0a 01 00 00 XX 00 00 00 00 0e 00 00 00 00 00 ???..X....?.....
>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00 ..............U.
>>
>> there is nothing to distinguish the two chips as far as I can see.
>> Is your system a devicetree system ? If so, you can just
>> provide a compatible statement such as
>> compatible = "ti,tmp461", "ti,tmp451";
>> or simply instantiate the chip as tmp451.
>>
>> Feel free to provide a patch adding '{ "tmp461", tmp451 },'
>> to lm90_id as well as the necessary documentation, but I don't
>> think there is anything we can do to detect the chip.
>>
>> On the other side, I am a bit concerned that the chip detection doesn't
>> work well, since the chip ID register is really unsupported and just happens
>> to return 0 for both chips. I wonder if there are other TI chips which may
>> be mis-detected as TMP451.
>>
>> Thanks,
>> Guenter
>>
>
> Hi,
> thanks for the register dump :-)
>
> There is one difference. The temperature ranges differ:
>
> TMP451:
> Standard Mode: 0 to +127
> Extended Mode: -64 to +191
>
> TMP461:
> Standard Mode: -40 to +127
> Extended Mode: -64 to +191
>
> Therefore the calcualtion is different then the tmp451 one.
>
Not really. The tmp451 will return 0 for negative temperatures in standard mode,
the tmp461 will return negative (signed) values. Temperatures are stored
as signed values, so the code should be ok as is. Am I missing something ?
> I also aggree with you with the magical ID register. I hate such
> kind of register with are not documented and may have a value.
>
> I have a DT based board yes, but i have also planed to submit my changes
> and also wanted to implement the autodetection of the chip.
I don't think auto-detection (other than handling the chip as tmp451)
will be possible, but I am looking forward to seeing your patch(es).
>
> I have also planned (or need) to implement the "n-Factor Correction" for the
> CPU diodes. There is a register to set this value in the tmp451 and tmp461.
> Would that make sense to add a DT property for the driver to be able
> to set this value? What do you think?
>
Yes, since this is a board (hardware) property. Other chips have similar
registers. We'll just have to find a good set of property names and descriptions.
Thanks,
Guenter
On 12/10/2015 09:12 AM, Andreas Werner wrote:
> On Thu, Dec 10, 2015 at 08:41:57AM -0800, Guenter Roeck wrote:
>> On 12/10/2015 04:08 AM, Andreas Werner wrote:
>>> Hi,
>>> i have a temperature sensor device named "TI TMP461" which is quite the
>>> same than the tmp451 which is already included in the lm90 driver.
>>>
>>> I just want to add the tmp461 to the driver but currently i have no way
>>> to differ between the tmp461 and tmp451.
>>>
>>> The main different is that the tmp461 address can be configured by to Pins
>>> whereas the tmp451 has a fixed address.
>>>
>>> The register layout is quite the same except that the tmp461 has one
>>> register more (0x16 Channel Enable Register).
>>>
>>> Every zero bit is the same for both bits, so we cannot use these bits for
>>> identification.
>>>
>>> Does anybody of you have a tmp451 to read out the register 0x16 (which is
>>> not implement but i expect a value). May be we can use this to
>>> identify the tmp461.
>>>
>>
>> Here is a register dump.
>>
>> 00: 5d 69 00 04 08 bf 00 ff 53 00 00 00 00 00 00 00 ]i.???..S.......
>> 10: a0 00 00 00 00 f0 00 00 00 a9 00 00 00 00 00 00 ?....?...?......
>> 20: b8 0a 01 00 00 XX 00 00 00 00 0e 00 00 00 00 00 ???..X....?.....
>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00 ..............U.
>>
>> there is nothing to distinguish the two chips as far as I can see.
>> Is your system a devicetree system ? If so, you can just
>> provide a compatible statement such as
>> compatible = "ti,tmp461", "ti,tmp451";
>> or simply instantiate the chip as tmp451.
>>
>> Feel free to provide a patch adding '{ "tmp461", tmp451 },'
>> to lm90_id as well as the necessary documentation, but I don't
>> think there is anything we can do to detect the chip.
>>
>> On the other side, I am a bit concerned that the chip detection doesn't
>> work well, since the chip ID register is really unsupported and just happens
>> to return 0 for both chips. I wonder if there are other TI chips which may
>> be mis-detected as TMP451.
>>
>> Thanks,
>> Guenter
>>
>
> Hi,
> thanks for the register dump :-)
>
> There is one difference. The temperature ranges differ:
>
> TMP451:
> Standard Mode: 0 to +127
> Extended Mode: -64 to +191
>
> TMP461:
> Standard Mode: -40 to +127
> Extended Mode: -64 to +191
>
> Therefore the calcualtion is different then the tmp451 one.
>
> I also aggree with you with the magical ID register. I hate such
> kind of register with are not documented and may have a value.
>
> I have a DT based board yes, but i have also planed to submit my changes
> and also wanted to implement the autodetection of the chip.
>
> I have also planned (or need) to implement the "n-Factor Correction" for the
> CPU diodes. There is a register to set this value in the tmp451 and tmp461.
> Would that make sense to add a DT property for the driver to be able
> to set this value? What do you think?
>
See max6697.c for some examples. Maybe we can use similar bindings.
Guenter
...
> On Thu, Dec 10, 2015 at 09:43:53AM -0800, Guenter Roeck wrote:
> >
> >There is one difference. The temperature ranges differ:
> >
> >TMP451:
> >Standard Mode: 0 to +127
> >Extended Mode: -64 to +191
> >
> >TMP461:
> >Standard Mode: -40 to +127
> >Extended Mode: -64 to +191
> >
> >Therefore the calcualtion is different then the tmp451 one.
> >
> Not really. The tmp451 will return 0 for negative temperatures in standard mode,
> the tmp461 will return negative (signed) values. Temperatures are stored
> as signed values, so the code should be ok as is. Am I missing something ?
>
It will work to read the local and external temperature yes, but not
for setting the temperatur.
If setting in standard mode, the tmp451 part fix the value to 0-127
but for the tmp461 we have -40 to 127.
I'v currently no chip here in the office to test it, hopefully I will
get one next week.
> >I also aggree with you with the magical ID register. I hate such
> >kind of register with are not documented and may have a value.
> >
> >I have a DT based board yes, but i have also planed to submit my changes
> >and also wanted to implement the autodetection of the chip.
>
> I don't think auto-detection (other than handling the chip as tmp451)
> will be possible, but I am looking forward to seeing your patch(es).
>
Yes, i think autodetection makes it very crapy. May be i will find
another solution.
> >
> >I have also planned (or need) to implement the "n-Factor Correction" for the
> >CPU diodes. There is a register to set this value in the tmp451 and tmp461.
> >Would that make sense to add a DT property for the driver to be able
> >to set this value? What do you think?
> >
> Yes, since this is a board (hardware) property. Other chips have similar
> registers. We'll just have to find a good set of property names and descriptions.
>
Ok, I will find a way to do it :-)
> Thanks,
> Guenter
>
Regards
Andy
...
>On Thu, Dec 10, 2015 at 09:49:43AM -0800, Guenter Roeck wrote:
> >
> >I have a DT based board yes, but i have also planed to submit my changes
> >and also wanted to implement the autodetection of the chip.
> >
> >I have also planned (or need) to implement the "n-Factor Correction" for the
> >CPU diodes. There is a register to set this value in the tmp451 and tmp461.
> >Would that make sense to add a DT property for the driver to be able
> >to set this value? What do you think?
> >
>
> See max6697.c for some examples. Maybe we can use similar bindings.
>
Seems to be a good way. I think I will also add the extended mode selection
via DT.
> Guenter
>
Regards
Andy
Hallo Andreas,
On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote:
> thanks for the register dump :-)
Can you please share the register dump of your TMP461 with us?
Thanks,
--
Jean Delvare
SUSE L3 Support
On Sat, Dec 12, 2015 at 11:08:42AM +0100, Jean Delvare wrote:
> Hallo Andreas,
>
> On Thu, 10 Dec 2015 18:12:31 +0100, Andreas Werner wrote:
> > thanks for the register dump :-)
>
> Can you please share the register dump of your TMP461 with us?
>
> Thanks,
> --
> Jean Delvare
> SUSE L3 Support
Hi,
here is the register dump of the tmp461.
It seemse that we really cannot detect if it is a tmp461 or a tmp451.
Also the magic "ID Register" offset 0xff is 0x00 for both devices.
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 5a 00 2c 00 05 7f 80 7f 80 00 00 00 00 00 00 00 Z.,.?????.......
10: 00 00 00 f0 00 80 03 00 00 7f 00 00 00 00 00 00 ...?.??..?......
20: 7f 0a 01 00 00 XX 00 00 00 00 0e 00 00 00 40 00 ???..X....?...@.
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00 ..............U.
Regards
Andy
Hi Andreas,
On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote:
> here is the register dump of the tmp461.
Thanks.
> It seemse that we really cannot detect if it is a tmp461 or a tmp451.
> Also the magic "ID Register" offset 0xff is 0x00 for both devices.
I would use register 0x16, which doesn't exist but reads 0x00 on the
TMP451. It could in theory also read 0x00 on the TMP461 but only if
both channels are disabled, which makes little sense. More likely at
least one channel will be enabled so you'll have value 0x01-0x03 if
this is a TMP461.
--
Jean Delvare
SUSE L3 Support
On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote:
> Hi Andreas,
>
> On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote:
> > here is the register dump of the tmp461.
>
> Thanks.
>
> > It seemse that we really cannot detect if it is a tmp461 or a tmp451.
> > Also the magic "ID Register" offset 0xff is 0x00 for both devices.
>
> I would use register 0x16, which doesn't exist but reads 0x00 on the
> TMP451. It could in theory also read 0x00 on the TMP461 but only if
> both channels are disabled, which makes little sense. More likely at
> least one channel will be enabled so you'll have value 0x01-0x03 if
> this is a TMP461.
>
Yes you are right. Both channels are enabled during POR, so the chance
to have a 0x00 as in the TMP451 will be very low.
> --
> Jean Delvare
> SUSE L3 Support
On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote:
> Hi Andreas,
>
> On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote:
> > here is the register dump of the tmp461.
>
> Thanks.
>
> > It seemse that we really cannot detect if it is a tmp461 or a tmp451.
> > Also the magic "ID Register" offset 0xff is 0x00 for both devices.
>
> I would use register 0x16, which doesn't exist but reads 0x00 on the
> TMP451. It could in theory also read 0x00 on the TMP461 but only if
> both channels are disabled, which makes little sense. More likely at
> least one channel will be enabled so you'll have value 0x01-0x03 if
> this is a TMP461.
>
Excellent idea!
Guenter
On Thu, Dec 17, 2015 at 06:57:51AM -0800, Guenter Roeck wrote:
> On Thu, Dec 17, 2015 at 12:48:08PM +0100, Jean Delvare wrote:
> > Hi Andreas,
> >
> > On Tue, 15 Dec 2015 16:11:24 +0100, Andreas Werner wrote:
> > > here is the register dump of the tmp461.
> >
> > Thanks.
> >
> > > It seemse that we really cannot detect if it is a tmp461 or a tmp451.
> > > Also the magic "ID Register" offset 0xff is 0x00 for both devices.
> >
> > I would use register 0x16, which doesn't exist but reads 0x00 on the
> > TMP451. It could in theory also read 0x00 on the TMP461 but only if
> > both channels are disabled, which makes little sense. More likely at
> > least one channel will be enabled so you'll have value 0x01-0x03 if
> > this is a TMP461.
> >
> Excellent idea!
>
> Guenter
Ok, i will implement the detection for the tm461 and also the temp calculation
for setting the temperature value.
Will send a patch as soon as i am done.
Regards
Andy