[lm-sensors] [RESEND] LM73 hwmon driver i2c auto-detection problem

[lm-sensors] [RESEND] LM73 hwmon driver i2c auto-detection problem

[Robert Casanova]

[-- Attachment #1.1: Type: text/plain, Size: 1539 bytes --]

We are trying to use the hwmon framework to read the temperature values out
of a LM73 device we have in our i2c bus on the OMAPL-138. It's current
address is 0x49.
The actual behavior for the LM73 driver seems to be to try to autodetect if
there are any other devices of that same type on the i2c bus by looking at
the std addresses where it could find one:
0x48, 0x49, 0x4a, 0x4c, 0x4d, 0x4e

What happens is that we have a different device with completely different
registers at @0x48 so when the autodetection method gets called it tries to
read 2bytes out of the register 0x07 and this other device has only 1byte of
data at that register, then the whole bus times out.

We have tried declaring the devices we have during our board setup
statically, for instance:
static const struct i2c_board_info __initconst i2c_devices[] = {
{
 I2C_BOARD_INFO("lm73", 0x49),
},
};

static __init void board_init(void) {
...
i2c_register_board_info(1/* i2c-0 above was registered i2c_davinci.1*/,
 i2c_devices,
ARRAY_SIZE(i2c_devices));
...
}

But even when the driver gets instantiated at the proper address 0x49 the
sensors_lm73_init gets called making the detect method to get called and
testing an address that could be an LM73 but is not and hanging the bus.

Has anyone found some of the same problems? Is there any way to avoid
completely the autodetection for the hwmon framework? Should the i2c
implementation be able to handle this situation gracefully?

Cheers,

Robert

PS: The other device has a factory non-modifiable address at 0x48.

[-- Attachment #1.2: Type: text/html, Size: 2258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] [RESEND] LM73 hwmon driver i2c auto-detection

[Guenter Roeck]

On Tue, Aug 30, 2011 at 11:25:42AM -0400, Robert Casanova wrote:
> We are trying to use the hwmon framework to read the temperature values out of
> a LM73 device we have in our i2c bus on the OMAPL-138. It's current address is
> 0x49.
> The actual behavior for the LM73 driver seems to be to try to autodetect if
> there are any other devices of that same type on the i2c bus by looking at the
> std addresses where it could find one:
> 0x48, 0x49, 0x4a, 0x4c, 0x4d, 0x4e
> 
> What happens is that we have a different device with completely different
> registers at @0x48 so when the autodetection method gets called it tries to
> read 2bytes out of the register 0x07 and this other device has only 1byte of
> data at that register, then the whole bus times out.
> 
> We have tried declaring the devices we have during our board setup statically,
> for instance:
> static const struct i2c_board_info __initconst i2c_devices[] = {
> {
> I2C_BOARD_INFO("lm73", 0x49),
> },
> };
> 
> static __init void board_init(void) {
> ...
> i2c_register_board_info(1/* i2c-0 above was registered i2c_davinci.1*/,
> i2c_devices,
> ARRAY_SIZE(i2c_devices));
> ...
> }
> 
> But even when the driver gets instantiated at the proper address 0x49 the
> sensors_lm73_init gets called making the detect method to get called and
> testing an address that could be an LM73 but is not and hanging the bus.
> 
> Has anyone found some of the same problems? Is there any way to avoid
> completely the autodetection for the hwmon framework? Should the i2c
> implementation be able to handle this situation gracefully?
> 
Did you try to instantiate the _other_ device ? That should take care of the problem.

Instantiating the LM73 at address 0x49 won't help, since the i2c core code will still
attempt to auto-detect the chip at address 0x48.

Guenter


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

Re: [lm-sensors] [RESEND] LM73 hwmon driver i2c auto-detection

[Robert Casanova]

[-- Attachment #1.1: Type: text/plain, Size: 2431 bytes --]

Actually that was one of my options but I couldn't find some i2c-dummy
driver or something similar, but now that you pointed out I've found a
compatible driver for that device and as Guenter said it does reserve the
address not being available to the i2c subsystem for auto-detection.

If there was no compatible driver (or not yet) for a device in my same
situation is there some sort of a generic driver to fill it up?

Thanks

On 30 August 2011 13:05, Guenter Roeck <guenter.roeck@ericsson.com> wrote:

> On Tue, Aug 30, 2011 at 11:25:42AM -0400, Robert Casanova wrote:
> > We are trying to use the hwmon framework to read the temperature values
> out of
> > a LM73 device we have in our i2c bus on the OMAPL-138. It's current
> address is
> > 0x49.
> > The actual behavior for the LM73 driver seems to be to try to autodetect
> if
> > there are any other devices of that same type on the i2c bus by looking
> at the
> > std addresses where it could find one:
> > 0x48, 0x49, 0x4a, 0x4c, 0x4d, 0x4e
> >
> > What happens is that we have a different device with completely different
> > registers at @0x48 so when the autodetection method gets called it tries
> to
> > read 2bytes out of the register 0x07 and this other device has only 1byte
> of
> > data at that register, then the whole bus times out.
> >
> > We have tried declaring the devices we have during our board setup
> statically,
> > for instance:
> > static const struct i2c_board_info __initconst i2c_devices[] = {
> > {
> > I2C_BOARD_INFO("lm73", 0x49),
> > },
> > };
> >
> > static __init void board_init(void) {
> > ...
> > i2c_register_board_info(1/* i2c-0 above was registered i2c_davinci.1*/,
> > i2c_devices,
> > ARRAY_SIZE(i2c_devices));
> > ...
> > }
> >
> > But even when the driver gets instantiated at the proper address 0x49 the
> > sensors_lm73_init gets called making the detect method to get called and
> > testing an address that could be an LM73 but is not and hanging the bus.
> >
> > Has anyone found some of the same problems? Is there any way to avoid
> > completely the autodetection for the hwmon framework? Should the i2c
> > implementation be able to handle this situation gracefully?
> >
> Did you try to instantiate the _other_ device ? That should take care of
> the problem.
>
> Instantiating the LM73 at address 0x49 won't help, since the i2c core code
> will still
> attempt to auto-detect the chip at address 0x48.
>
> Guenter
>
>

[-- Attachment #1.2: Type: text/html, Size: 3116 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] [RESEND] LM73 hwmon driver i2c auto-detection

[Jean Delvare]

Hi Robert,

Please don't top-post.

On Tue, 30 Aug 2011 14:20:58 -0400, Robert Casanova wrote:
> Actually that was one of my options but I couldn't find some i2c-dummy
> driver or something similar, but now that you pointed out I've found a
> compatible driver for that device and as Guenter said it does reserve the
> address not being available to the i2c subsystem for auto-detection.
> 
> If there was no compatible driver (or not yet) for a device in my same
> situation is there some sort of a generic driver to fill it up?

i2c-core includes a dummy driver which will bind to any I2C device with
name "dummy", so you can probably just declare an i2c device with name
"dummy" at 0x48 and it would do the trick.

But the best fix in your case would be to disable probing of the I2C
bus entirely, as apparently you don't need it. Just set
i2c_adapter.class to 0 (_not_ I2C_CLASS_HWMON) and you're done.

As a side note, the lm73 driver could certainly be improved to make
detection less problematic. I'll do that now, but I do not consider
this the proper fix to your problem.

-- 
Jean Delvare

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