* Re: [lm-sensors] Update on DS1721, DS1631, DS1631A, DS1731
2011-03-18 4:20 [lm-sensors] Update on DS1721, DS1631, DS1631A, DS1731 Guenter Roeck
@ 2011-03-18 7:57 ` Jean Delvare
2011-03-18 10:28 ` Guenter Roeck
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2011-03-18 7:57 UTC (permalink / raw)
To: lm-sensors
On Thu, 17 Mar 2011 21:20:48 -0700, Guenter Roeck wrote:
> Hi all,
>
> I confirmed that DS1721, DS1631, DS1631A, and DS1731
> work with the existing ds1621 driver:
>
> DS1721 (2x):
> ds1621-i2c-5-48
> Adapter: i2c-devantech-iss at bus 002 device 034
> temp1: +23.5°C (low = +10.0°C, high = +70.0°C)
>
> ds1621-i2c-5-49
> Adapter: i2c-devantech-iss at bus 002 device 034
> temp1: +23.5°C (low = +10.0°C, high = +70.0°C)
>
> DS1631:
> ds1621-i2c-5-4a
> Adapter: i2c-devantech-iss at bus 002 device 034
> temp1: +23.0°C (low = +10.0°C, high = +70.0°C)
>
> DS1631A:
> ds1621-i2c-5-4b
> Adapter: i2c-devantech-iss at bus 002 device 034
> temp1: +23.0°C (low = +10.0°C, high = +70.0°C)
>
> DS1731:
> ds1621-i2c-5-4c
> Adapter: i2c-devantech-iss at bus 002 device 034
> temp1: +23.5°C (low = +10.0°C, high = +70.0°C)
>
> Output from sensors-detect:
>
> Driver `ds1621':
> * Bus `i2c-devantech-iss at bus 002 device 034'
> Busdriver `i2c_devantech_iss', I2C address 0x48
> Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> * Bus `i2c-devantech-iss at bus 002 device 034'
> Busdriver `i2c_devantech_iss', I2C address 0x49
> Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> * Bus `i2c-devantech-iss at bus 002 device 034'
> Busdriver `i2c_devantech_iss', I2C address 0x4a
> Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> * Bus `i2c-devantech-iss at bus 002 device 034'
> Busdriver `i2c_devantech_iss', I2C address 0x4b
> Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> * Bus `i2c-devantech-iss at bus 002 device 034'
> Busdriver `i2c_devantech_iss', I2C address 0x4c
> Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
>
> The chips still support register 0xee, even though that is not documented
> in the datasheets.
>
> Auto-detection and sensors-detect may or may not work depending
> on chip configuration (it always works after power-up).
> Explicit device instantiation always works.
>
> I'll update the list of supported devices to reflect this information.
If memory serves, at least the DS1631 supports better resolution than
the ds1621 driver currently offers. So claiming that it is supported
isn't completely exact. What the driver supports is really the DS1621
and the other chips happen to emulate it.
It should really not be difficult to add proper support for all chips,
I just could never find the time to look into it. The chips I have here
are: one DS1621, two DS1631+ and two DS1624+.
--
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] Update on DS1721, DS1631, DS1631A, DS1731
2011-03-18 4:20 [lm-sensors] Update on DS1721, DS1631, DS1631A, DS1731 Guenter Roeck
2011-03-18 7:57 ` Jean Delvare
@ 2011-03-18 10:28 ` Guenter Roeck
2011-03-18 11:04 ` Jean Delvare
2011-03-18 13:40 ` Guenter Roeck
3 siblings, 0 replies; 5+ messages in thread
From: Guenter Roeck @ 2011-03-18 10:28 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
On Fri, Mar 18, 2011 at 03:57:58AM -0400, Jean Delvare wrote:
> On Thu, 17 Mar 2011 21:20:48 -0700, Guenter Roeck wrote:
> > Hi all,
> >
> > I confirmed that DS1721, DS1631, DS1631A, and DS1731
> > work with the existing ds1621 driver:
> >
> > DS1721 (2x):
> > ds1621-i2c-5-48
> > Adapter: i2c-devantech-iss at bus 002 device 034
> > temp1: +23.5°C (low = +10.0°C, high = +70.0°C)
> >
> > ds1621-i2c-5-49
> > Adapter: i2c-devantech-iss at bus 002 device 034
> > temp1: +23.5°C (low = +10.0°C, high = +70.0°C)
> >
> > DS1631:
> > ds1621-i2c-5-4a
> > Adapter: i2c-devantech-iss at bus 002 device 034
> > temp1: +23.0°C (low = +10.0°C, high = +70.0°C)
> >
> > DS1631A:
> > ds1621-i2c-5-4b
> > Adapter: i2c-devantech-iss at bus 002 device 034
> > temp1: +23.0°C (low = +10.0°C, high = +70.0°C)
> >
> > DS1731:
> > ds1621-i2c-5-4c
> > Adapter: i2c-devantech-iss at bus 002 device 034
> > temp1: +23.5°C (low = +10.0°C, high = +70.0°C)
> >
> > Output from sensors-detect:
> >
> > Driver `ds1621':
> > * Bus `i2c-devantech-iss at bus 002 device 034'
> > Busdriver `i2c_devantech_iss', I2C address 0x48
> > Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> > * Bus `i2c-devantech-iss at bus 002 device 034'
> > Busdriver `i2c_devantech_iss', I2C address 0x49
> > Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> > * Bus `i2c-devantech-iss at bus 002 device 034'
> > Busdriver `i2c_devantech_iss', I2C address 0x4a
> > Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> > * Bus `i2c-devantech-iss at bus 002 device 034'
> > Busdriver `i2c_devantech_iss', I2C address 0x4b
> > Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> > * Bus `i2c-devantech-iss at bus 002 device 034'
> > Busdriver `i2c_devantech_iss', I2C address 0x4c
> > Chip `Dallas Semiconductor DS1621/DS1631' (confidence: 3)
> >
> > The chips still support register 0xee, even though that is not documented
> > in the datasheets.
> >
> > Auto-detection and sensors-detect may or may not work depending
> > on chip configuration (it always works after power-up).
> > Explicit device instantiation always works.
> >
> > I'll update the list of supported devices to reflect this information.
>
> If memory serves, at least the DS1631 supports better resolution than
> the ds1621 driver currently offers. So claiming that it is supported
> isn't completely exact. What the driver supports is really the DS1621
> and the other chips happen to emulate it.
>
> It should really not be difficult to add proper support for all chips,
> I just could never find the time to look into it. The chips I have here
> are: one DS1621, two DS1631+ and two DS1624+.
>
Sure, can do that. What would you suggest ? Pick the best available resolution ?
Also, if we do that, I would use i2c_device_id to select the part, and not try
to auto-detect it. Another option would be to play with the configuration register
and try detecting chip types this way (ie set bit 3,4 and observe the result).
Not sure if that is a good idea, though. Any thoughts on this ?
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] Update on DS1721, DS1631, DS1631A, DS1731
2011-03-18 4:20 [lm-sensors] Update on DS1721, DS1631, DS1631A, DS1731 Guenter Roeck
2011-03-18 7:57 ` Jean Delvare
2011-03-18 10:28 ` Guenter Roeck
@ 2011-03-18 11:04 ` Jean Delvare
2011-03-18 13:40 ` Guenter Roeck
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2011-03-18 11:04 UTC (permalink / raw)
To: lm-sensors
On Fri, 18 Mar 2011 03:28:51 -0700, Guenter Roeck wrote:
> On Fri, Mar 18, 2011 at 03:57:58AM -0400, Jean Delvare wrote:
> > If memory serves, at least the DS1631 supports better resolution than
> > the ds1621 driver currently offers. So claiming that it is supported
> > isn't completely exact. What the driver supports is really the DS1621
> > and the other chips happen to emulate it.
> >
> > It should really not be difficult to add proper support for all chips,
> > I just could never find the time to look into it. The chips I have here
> > are: one DS1621, two DS1631+ and two DS1624+.
> >
> Sure, can do that. What would you suggest ? Pick the best available resolution ?
By default, sure, why not? If anybody needs specific configuration,
they can add platform data.
> Also, if we do that, I would use i2c_device_id to select the part, and not try
> to auto-detect it. Another option would be to play with the configuration register
> and try detecting chip types this way (ie set bit 3,4 and observe the result).
You aren't allowed to write to the device in the detect function.
> Not sure if that is a good idea, though. Any thoughts on this ?
As I said before, I would blast detection code completely, and rely on
explicit instantiation for all devices (i.e. trust i2c_device_id).
--
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] Update on DS1721, DS1631, DS1631A, DS1731
2011-03-18 4:20 [lm-sensors] Update on DS1721, DS1631, DS1631A, DS1731 Guenter Roeck
` (2 preceding siblings ...)
2011-03-18 11:04 ` Jean Delvare
@ 2011-03-18 13:40 ` Guenter Roeck
3 siblings, 0 replies; 5+ messages in thread
From: Guenter Roeck @ 2011-03-18 13:40 UTC (permalink / raw)
To: lm-sensors
Hi Jean,
On Fri, Mar 18, 2011 at 07:04:24AM -0400, Jean Delvare wrote:
> On Fri, 18 Mar 2011 03:28:51 -0700, Guenter Roeck wrote:
> > On Fri, Mar 18, 2011 at 03:57:58AM -0400, Jean Delvare wrote:
> > > If memory serves, at least the DS1631 supports better resolution than
> > > the ds1621 driver currently offers. So claiming that it is supported
> > > isn't completely exact. What the driver supports is really the DS1621
> > > and the other chips happen to emulate it.
> > >
> > > It should really not be difficult to add proper support for all chips,
> > > I just could never find the time to look into it. The chips I have here
> > > are: one DS1621, two DS1631+ and two DS1624+.
> > >
> > Sure, can do that. What would you suggest ? Pick the best available resolution ?
>
> By default, sure, why not? If anybody needs specific configuration,
> they can add platform data.
>
> > Also, if we do that, I would use i2c_device_id to select the part, and not try
> > to auto-detect it. Another option would be to play with the configuration register
> > and try detecting chip types this way (ie set bit 3,4 and observe the result).
>
> You aren't allowed to write to the device in the detect function.
>
> > Not sure if that is a good idea, though. Any thoughts on this ?
>
> As I said before, I would blast detection code completely, and rely on
> explicit instantiation for all devices (i.e. trust i2c_device_id).
>
Ok, sounds like a plan.
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