cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jdefields
Explorer
Explorer
344 Views
Registered: ‎12-02-2014

Zynqmp: Adding i2c recovery info causes i2c issues

Jump to solution

Hi all,

I'm on a custom board, running i2c0 and i2c1 (Running the xilinx-v2018.2 tag linux code).  Both of those busses are running fine, and all devices on there are working as expected.  As a test, I want to add i2c recovery info to the device tree, but it causes those busses to have communication issues simply by instantiating the recovery structure.  I'm using MIO26/27 for i2c0 and MIO28/29 for i2c1.

Here's the additions I added to the device tree:

pinctrl:

 

&pinctrl0 {
	status = "okay";
    
    pinctrl_i2c0_default: i2c0-default {
		mux {
			groups = "i2c0_6_grp";
			function = "i2c0";
		};

		conf {
			groups = "i2c0_6_grp";
			bias-pull-up;
			slew-rate = <SLEW_RATE_SLOW>;
			io-standard = <IO_STANDARD_LVCMOS18>;
		};
	};

	pinctrl_i2c0_gpio: i2c0-gpio {
		mux {
			groups = "gpio0_26_grp", "gpio0_27_grp";
			function = "gpio0";
		};

		conf {
			groups = "gpio0_26_grp", "gpio0_27_grp";
			slew-rate = <SLEW_RATE_SLOW>;
			io-standard = <IO_STANDARD_LVCMOS18>;
		};
	};

	pinctrl_i2c1_default: i2c1-default {
		mux {
			groups = "i2c1_7_grp";
			function = "i2c1";
		};

		conf {
			groups = "i2c1_7_grp";
			bias-pull-up;
			slew-rate = <SLEW_RATE_SLOW>;
			io-standard = <IO_STANDARD_LVCMOS18>;
		};
	};

	pinctrl_i2c1_gpio: i2c1-gpio {
		mux {
			groups = "gpio0_28_grp", "gpio0_29_grp";
			function = "gpio0";
		};

		conf {
			groups = "gpio0_28_grp", "gpio0_29_grp";
			slew-rate = <SLEW_RATE_SLOW>;
			io-standard = <IO_STANDARD_LVCMOS18>;
		};
	};
};

 

i2c0:

 

&i2c0 {
	clock-frequency = <100000>;
	status = "okay";
    pinctrl-names = "default", "gpio";
    pinctrl-0 = <&pinctrl_i2c0_default>;
    pinctrl-1 = <&pinctrl_i2c0_gpio>;
    scl-gpios = <&gpio 26 GPIO_ACTIVE_HIGH>;
    sda-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;

 

i2c1:

 

&i2c1 {
	clock-frequency = <100000>;
	status = "okay";
    pinctrl-names = "default", "gpio";
    pinctrl-0 = <&pinctrl_i2c1_default>;
    pinctrl-1 = <&pinctrl_i2c1_gpio>;
    scl-gpios = <&gpio 28 GPIO_ACTIVE_HIGH>;
    sda-gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;

 

 

Does anything look like an issue there?

I can see these debug messages from the cadence driver:
cdns-i2c ff020000.i2c: using scl-gpio 365 and sda-gpio 364 for recovery
cdns-i2c ff030000.i2c: using scl-gpio 367 and sda-gpio 366 for recovery

Where do those numbers come from?  My base gpio number is 290 in /sys/class/gpio, I would expect those to be 316, 317, 318, and 319.

0 Kudos
1 Solution

Accepted Solutions
jdefields
Explorer
Explorer
261 Views
Registered: ‎12-02-2014

I figured out how to force the gpiochip numbering for the zynq gpio controller, which resolved my issue.

Ended up changing chip->base = -1; to chip->base = 290; in drivers/gpio/gpio-zynq.c

After this change, the recovery info is registered, and the i2c bus and all other GPIO are working as expected.

View solution in original post

0 Kudos
2 Replies
jdefields
Explorer
Explorer
315 Views
Registered: ‎12-02-2014
OOF. So adding the gpio information to the i2c controller is somehow re-arranging the order of the gpio controllers (and their starting numbers).  Normally I have the main GPIO controller at offset 290, and then two i2c IO expanders that follow.  Now the two i2c expanders are coming up first.
 
Does anyone have an idea for how I can maintain the original ordering?
0 Kudos
jdefields
Explorer
Explorer
262 Views
Registered: ‎12-02-2014

I figured out how to force the gpiochip numbering for the zynq gpio controller, which resolved my issue.

Ended up changing chip->base = -1; to chip->base = 290; in drivers/gpio/gpio-zynq.c

After this change, the recovery info is registered, and the i2c bus and all other GPIO are working as expected.

View solution in original post

0 Kudos