i.MX7D Device Tree Customization for I2C

Hello,

I’ve started working on a device tree dts file for a custom board that we have developed for the i.MX7D Colibri V1.1 B board.

The default dtsi and dts files, for the iMX7D Colibri and Colibri Evaluation Board, setup and configure i2c port 1 and i2c port 4. I have some application code that calls down from user space and sends bytes out from the I2C line that is available from X8 on the Colibri Evaluation Board. This is i2c4 and it seems to be working fine.

In our board specific dts file I am disabling i2c port 1 and i2c port 4 by adding the following to the dts file:

&i2c1 {
	status = "disabled";
}

&i2c4 {
	status = "disabled"
}

For i2c port 3, which we are using on our custom carrier board, I have added the following, based on the existing i2c port 4 setup:

&i2c3 {
	clock-frequency = <100000>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_i2c3>;
};

&pinctrl_i2c3: i2c3grp {
	fsl,pins = <
		MX7D_PAD_LCD_DATA20__I2C3_SCL		0x4000007f
		MX7D_PAD_LCD_DATA21__I2C3_SDA		0x4000007f
	>;
};

What I don’t understand is why are the lines: MX7D_PAD_LCD_DATA20__I2C3_SCL, and MX7D_PAD_LCD_DATA21__I2C3_SDA above are set to a value of: 0x4000007f? These lines are borrowed from your existing setup of i2c port 4 located in the: imx7-colibri.dtsi file.

When reading through the Toradex document: Device Tree Customization in the section: pinmux-imx7 I see a description of the bits that are getting setup by the value 0x4000007f. The 7f part of the value makes sense as it matches up exactly with the bit definitions in the i.MX7D reference manual, so I’m totally cool with that, but the Device Tree Document, linked above indicates that bit 16 is a hysteresis field that can be set. There is no iomux controller register, discussed an i.MX7D reference manual, that has a bit 16 that can be set.

Also, what is the 4 for in the value: 0x4000007f? I would have thought, based on the iomux controller register, that should be set for i2c, that the value should be 0x0000007f. None of the iomux PAD controller registers have any bits that can be set in the high order word. Is this just something that was copied from some other device tree used previously?

I think it should still work just fine for what I’m doing since the bit is reserved and can’t be set anyway, but I wanted to ask just in case I might be looking at this all wrong.

Thank You

Hi

Our ‘Device Tree Customization’ article left the description of bit 30/31 out.

Have a look at the kernel documentation here.
Setting bit 30 makes the iomuxc driver setting the SION bit in the PAD mux register.
Setting bit 31 inhibits changing the PAD control register.

Having bit 16 documented as a hysteresis field is a copy/paste error from the similar table for i.MX 6, you can simply ignore this.

Max

Thanks max.tx!

The link you provided, and your description clears things up completely. :).