Failed to get controller clock i2c

[michiel.tjampens]

Got this error in boot log.

[ 4.036653] stm32f7-i2c 5c009000.i2c: error -ENOENT: Failed to get controller clock
[ 4.054809] stm32f7-i2c: probe of 5c009000.i2c failed with error -2

5c009000 refers to i2c6. Below is the relevant section in the optee dts. I2C4 and I2C6 share a clock and I2C4 is working fine. I2C6 is mentioned in the eztpc node, so that ain't it either.

	st,clksrc=<
		CLK_CKPER_DISABLED
		CLK_ETH_PLL4P
		CLK_SDMMC12_PLL3R
		CLK_STGEN_HSI
		CLK_I2C46_HSI
		CLK_SDMMC3_PLL3R
		CLK_USBO_USBPHY
		CLK_UART24_HSI
		CLK_RNG1_CSI
		CLK_MPU_PLL1P
		CLK_AXI_PLL2P
		CLK_MCU_PLL3P
		CLK_RTC_LSI
		CLK_MCO1_DISABLED
		CLK_MCO2_DISABLED
	>;

 The i2c6 section:

&i2c6{
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&i2c6_pins_z_mx>;
	pinctrl-1 = <&i2c6_sleep_pins_z_mx>;
	status = "okay";

	pcf85263: pcf85263@51 {
		compatible = "nxp,pcf85263";
		reg = <0x51>;
		status = "okay";
	};
};

 I2C4 was set up to 400kHz and I2C6 default, changing I2C4 to default didn't help.

Am I forgetting something? Full dts can be found here.

[Erwan SZYMANSKI]

Hello @michiel.tjampens ,
I think you have to do the same as for i2c4, in your core/code/dts/kernel/stm32mp151a-tios-scmi.dtsi, as to know : 

&i2c6 {
	clocks = <&scmi_clk CK_SCMI_I2C6>;
	resets = <&scmi_reset RST_SCMI_I2C6>;
};

Kind regards,
Erwan.

[michiel.tjampens]

Hello @Erwan SZYMANSKI 

That did the trick.But any idea why i2c4 and i2c6 need to be mentioned in the scmi but i2c5 doesn't?

Also i2cdetect takes atleast a second per address... but does in the end find the rtc on the correct address.

Pull-ups are present, idle state is high etc.

[debugging]

I just fixed this same error after debugging  this for a day by adding this line in the SCMI files. This is not mentioned in the WIKI , nor CubeMX generates the SCMI file, nor the WIKI mentions about adding the clocks to OPTEE and EZTPC.

 

I now have the same issue with i2cprobe -y 0 on I2C6, is is very slow and takes one second per address. There are no devices on the bus. . I used the same code for i2cprobe for an MCU and that does not show such behavior

Is this normal or indicate a problem ? AFAIK, I2Cprobe just pulls the lines high and low and see if something happens, like basic GPIO.