This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3352: I2C device probe fails

Part Number: AM3352

Tool/software: Linux

Hi

I am working with a board based on the beagleBoneBlack using the latest SDK 04_01_00_06. Running a very small rootfs based on core-image-imnimal

I am trying to incorporate a sht3x temp/humdity sensor.

&i2c1 {
	status = "okay";
	clock-frequency = <400000>;
	pinctrl-names = "default";
	pinctrl-0 = <&i2c1_pins>;

	sht@44 {
		compatible = "sht3x";
		reg = <0x44>;
	};

};

Unfortunately the probe of this device fails unless I add printk debug text to the probe function

without debug:

[ 2.551089] omap_hsmmc 481d8000.mmc: card claims to support voltages below defined range
[ 2.594213] input: tps65217_pwrbutton as /devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024/tps65217-pwrbutton/input/input1
[ 2.620112] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[ 2.659425] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[ 2.709542] sht3x: probe of 1-0044 failed with error -121
[ 2.715467] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 400 kHz

Whereas with some trivial debug in place (just a mark and a line number to see where the driver failed): 

[ 2.584144] input: tps65217_pwrbutton as /devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024/tps65217-pwrbutton/input/input1
[ 2.610052] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[ 2.649363] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[ 2.670103] sht3 710
[ 2.699342] sht3 715
[ 2.701541] sht3 719
[ 2.703739] sht3 734
[ 2.714773] sht3 738
[ 2.716970] sht3 743
[ 2.728447] sht3 751
[ 2.731138] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 400 kHz
[ 2.745095] input: gpio_buttons@0 as /devices/platform/gpio_buttons@0/input/input2

I find that I have a working device:

root@elle-board:/sys/devices/platform/ocp/4802a000.i2c/i2c-1/1-0044/hwmon/hwmon0# ls
device humidity1_input humidity1_min of_node temp1_alarm temp1_max_hyst uevent
heater_enable humidity1_max humidity1_min_hyst power temp1_input temp1_min update_interval
humidity1_alarm humidity1_max_hyst name subsystem temp1_max temp1_min_hyst

Relying on what I presume is timing effects of debug strings seems like a pretty poor way of getting something to work.
I would be grateful for any suggestions about how best to make this reliable?

Thanks for the help,
Richard