AM67A: Enable i2c4 on AM67

Hi Evan,

You're correct, it should probably be "ti,am64-i2c", "ti,omap4-i2c".

If you use that instead, do you still see the probe failure error?

Best,
Jared

Hi Jared,

With that change, I see:
omap_i2c bus@f0000:i2c@fe80000: invalid resource (null)
omap_i2c: probe of bus@f0000:i2c@fe80000 failed with error -22

Hi Evan,

Looking closer, I also realized there is no GIC interrupt for the I2C4.

Can you try the following:

	main_i2c4: i2c@fe80000 {
		compatible = "ti,am64-i2c", "ti,omap4-i2c";
		reg = <0x00 0xfe80000 0x00 0x100>;
		interrupts = <&main_gpio_intr 178 IRQ_TYPE_LEVEL_HIGH>;
		#address-cells = <1>;
		#size-cells = <0>;
		power-domains = <&k3_pds 257 TI_SCI_PD_EXCLUSIVE>;
		clocks = <&k3_clks 257 2>;
		clock-names = "fck";
		status = "disabled";
	};

Best,
Jared

Hi Jared,

I used "okay" instead of "disabled" getting a new error:
omap_i2c bus@f0000:i2c@fe80000: error -6: IRQ index 0 not found

Hi Evan,

Can you try:

	main_i2c4: i2c@fe80000 {
		compatible = "ti,am64-i2c", "ti,omap4-i2c";
		reg = <0x00 0xfe80000 0x00 0x100>;
		interrupt-parent = <&main_gpio_intr>;
		interrupts = <178>;
		#address-cells = <1>;
		#size-cells = <0>;
		power-domains = <&k3_pds 257 TI_SCI_PD_EXCLUSIVE>;
		clocks = <&k3_clks 257 2>;
		clock-names = "fck";
		status = "disabled";
	};

Best,
Jared

Hi Jared,

status='disabled' will not initialize the peripheral. I'm getting the same behavior when using 'okay'
On our boards main_i2c4 will map to i2c-5.

kernel[640]: omap_i2c bus@f0000:i2c@fe80000: invalid resource (null)
kernel[640]: omap_i2c: probe of bus@f0000:i2c@fe80000 failed with error -22

Thanks

Hi Jared,

I found that 257 for clock and power domain is the first issue.
I set it to 0x6c and now it's deferring the probe indefinitely.

Hi Jared,

I also tried 0x65 and see it defer probe forever.

Where does the 257 value come from?

Hi Evan,

257 comes from here: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j722s/devices.html#soc-doc-j722s-public-devices-desc-device-list 

Best,
Jared

Hi Jared,

Looks like maybe it's printing invalid resource when it calls into:

Thanks Jared! This makes much more sense. I'll give it a try.

Hi Jared,

Devices are able to communicate on i2c4 with this change, but I noticed the interrupt still may not be working right?
I've removed all of my devices (All i2c4 ICs are depopulated from the board), but despite this, I still get slow response when using i2cdetect -r 5. The log prints this:

omap_i2c fe80000.i2c: controller timed out

Hi Evan,

I would expect the i2c4 to be slower, since the interrupt is routed through the gpiomux interrupt router instead of the GIC.

Does the timeout occur every time, or is it sporadic?

Best,
Jared

Hi Jared,

It's consistent. Every address that isn't connected causes the timeout.
When I use this function on other i2c buses, the addresses without a device attached are fast to complete.

When a device -is- attached, the i2cdetect completes for those addresses very quickly.

HI Evan,

I see... That's interesting. I assume it has something to do with the gpiomux interrupt router, but I don't know what the issue is.

I'll ask our development team if they have any knowledge.

Best,
Jared

Hi Evan,

Does this version work? (taken from:  RE: AM67A: Enable i2c4 on AM67 ) 

	main_i2c4: i2c@fe80000 {
		compatible = "ti,am64-i2c", "ti,omap4-i2c";
		reg = <0x00 0xfe80000 0x00 0x100>;
		interrupts = <&main_gpio_intr 178 IRQ_TYPE_LEVEL_HIGH>;
		#address-cells = <1>;
		#size-cells = <0>;
		power-domains = <&k3_pds 257 TI_SCI_PD_EXCLUSIVE>;
		clocks = <&k3_clks 257 2>;
		clock-names = "fck";
	};

Best,
Jared

HI Jared,

I tried it again and get the same response as before:

omap_i2c fe80000.i2c: error -6: IRQ index 0 not found

Perhaps we need interrupt-cells = <2> or <3>?

Hi Evan,

Yeah, the main_gpio_intr has interrupt-cells = <1>, but changing that to <2> would likely cause issues with the preexisting child interrupts.

Best,
Jared

Should we try a different interrupt controller? I remember the datasheet listed a few others.

Hi Jared, I set the clock frequency in the dts to 1MHz, and it's still communicating at 400KHz, but it is no longer timing out?

Hi Evan,

Evan Williams said:

Should we try a different interrupt controller? I remember the datasheet listed a few others.

I don't think the R5FSS0_CORE0 or MCU_R5FSS0_CORE0 routers have device-tree nodes.

Evan Williams said:

Hi Jared, I set the clock frequency in the dts to 1MHz, and it's still communicating at 400KHz, but it is no longer timing out?

I saw that it was originally set to 100KHz, if you set it to 400KHz, does it work properly?

Best,
Jared

Hi Jared, No. 100KHz and 400KHz both cause some kind of delay on i2cdetect and invalid reads.

I found that it's actually sending the addresses still at 400khz, but then does communicate at 1MHz.

Hi Evan,

Interesting. I've raised a ticket internally, but for now, at least I2C4 is working.

Best,
Jared

Hi Jared,

That's good news, could you please confirm which version of SDK was used?

Hi Evan,

The patch was applied to the 11.0 SDK.

Best,
Jared