My team and I have been trying out the available I2C buses on the Apalis iMX8X, and we’ve recently noticed a peculiarity regarding the enumeration of MIPI I2C buses, 56226000.i2c and 56246000.i2c. While both buses are able to detect and talk to slaves seemingly without problems, dmesg shows a “can’t get irq number” error when attempting to load the lpi2c driver for these buses.
We’ve previously made our own device tree modifications to enable these buses:
/* Apalis I2C2 (56246000.i2c) MXM3 205, 207 */
&i2c0_mipi_lvds1 {
status = "okay";
};
&mipi1_dphy {
status = "okay";
};
&mipi1_dsi_host {
status = "okay";
};
/* Apalis I2C6 (56226000.i2c) MXM3 35, 37 */
&i2c0_mipi_lvds0 {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c0_mipi_lvds0>;
clock-frequency = <100000>;
status = "okay";
};
&mipi0_dphy {
status = "okay";
};
&mipi0_dsi_host {
status = "okay";
};
Are these error messages cause for concern? We wouldn’t have noticed anything wrong with them if not for running dmesg, as we were able to attach and interface with generic i2c devices on these buses.
@alex.tx , hello, do you know this ?
The “can’t get irq number” message should indicate that this particular instance of driver was not loaded during modprobe phase. Please check here. But since you are able communicate with I2C devices and dmesg shows continuous I2C-x enumeration looks like another instance get loaded correctly.
Can you doublecheck you Device tree sources and DT build log for duplicated i2c@56226000 and i2c@56246000 records?
Hi @alex.tx, thanks for the tip. I managed to fdtdump the resulting dtb and only managed to find a single node for i2c@56226000 and i2c@56246000 each…
i2c@56226000 {
compatible = "fsl,imx8qxp-lpi2c", "fsl,imx7ulp-lpi2c";
reg = <0x56226000 0x00001000>;
interrupts = <0x00000008>;
interrupt-parent = <0x000000f3>;
clocks = <0x000000f4 0x00000000 0x000000f4 0x00000001>;
clock-names = "per", "ipg";
assigned-clocks = <0x00000003 0x0000018b 0x00000002>;
assigned-clock-rates = <0x016e3600>;
power-domains = <0x00000020 0x0000018b>;
status = "okay";
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
pinctrl-names = "default";
pinctrl-0 = <0x000000f5>;
clock-frequency = <0x000186a0>;
phandle = <0x000001af>;
};
i2c@56246000 {
compatible = "fsl,imx8qxp-lpi2c", "fsl,imx7ulp-lpi2c";
reg = <0x56246000 0x00001000>;
interrupts = <0x00000008>;
interrupt-parent = <0x00000101>;
clocks = <0x00000102 0x00000000 0x00000102 0x00000001>;
clock-names = "per", "ipg";
assigned-clocks = <0x00000003 0x0000018f 0x00000002>;
assigned-clock-rates = <0x016e3600>;
power-domains = <0x00000020 0x0000018f>;
status = "okay";
#address-cells = <0x00000001>;
#size-cells = <0x00000000>;
pinctrl-names = "default";
pinctrl-0 = <0x00000103>;
clock-frequency = <0x000186a0>;
phandle = <0x000001b3>;
};
In the DT source, the only instance of i2c@56226000 and i2c@56246000 I can find is located in imx8qxp-ss-lvds.dtsi, which is included in imx8qxp.dtsi.
@alex.tx In fact, I was able to reproduce the message on Toradex’s prebuilt images by enabling apalis-imx8x_dsihdmi_overlay.
Doe’s it affect your communication with devices over selected I2C bus?
@alex.tx Nope. So far everything works fine. We originally asked because we were unsure if it would affect communication with devices over those buses in spite of it working fine now, and whether this is a known issue. Sounds like it is safe to ignore the message for now.
Yes, you can ignore this message. Let us know if you see any further issues regarding I2C communication.
