I2C3 M0 SCL not changing on Radxa E25 with kernel 6.1.65

#1

Hello!
I’m trying to use I2C3 interface on Radxa E25 board with CM3I module. System builded with kernel 6.1.65 using the Radxa’s ‘bsp’ (/linux/stable) and ‘debos-radxa’ (bullseye) development frameworks. I activated I2C3 (M0) as:

rk3568-radxa-e25-addition

&i2c3 {
status = “okay”;
pinctrl-0 = <&i2c3m0_xfer>;
};
&i2c3m0_xfer {
rockchip,pins =
<1 RK_PA1 1 &pcfg_pull_up_drv_level_1>,
<1 RK_PA0 1 &pcfg_pull_up_drv_level_1>;
};

Interface is presented in system:

i2cdetect -l

root@uspd:~# i2cdetect -l
i2c-3 i2c rk3x-i2c I2C adapter
i2c-0 i2c rk3x-i2c I2C adapter

dmesg | grep i2c

[ 2.243214] i2c_dev: i2c /dev entries driver

But as I see on oscilloscope - SDA is changing but SCL is not when i am using command to read something “i2cdetect -a 3”.

In sysfs, after system started SCL pin (<1 RK_PA1 …>) already exported as gpio33, but SDA pin (<1 RK_PA0 …>) is not:

cat /sys/kernel/debug/gpio

gpiochip1: GPIOs 32-63, parent: platform/fe740000.gpio, gpio1:
gpio-33 ( |sysfs ) in hi
gpio-34 ( |sysfs ) in lo
gpio-42 ( |reset ) out hi

Unexporting gpio33 don’t resolve problem.

pinctrl nodes with same pins are disabled or not used at all in device tree (acodec_pins, audiopwm_loutn, audiopwm_rout, can1m0_pins and uart3m0_xfer).

I tested kernel with dts fork .rk356x-4.19 from ‘bsp’ and I2C works here properly.

What could cause this problem?

#2

Problem was in my custom udev rules file that export gpios and create symbol links:

01-gpios.rules

ACTION==“add”, SUBSYSTEM==“gpio”, DEVPATH=="/devices//gpiochip32", ATTR{subsystem/export}=“33”, ATTR{subsystem/export}=“34”, RUN+="/bin/mkdir -p /dev/gpio/"
ACTION==“add”, SUBSYSTEM==“gpio”, DEVPATH=="/devices//gpio33", ATTR{active_low}=“0”, ATTR{direction}=“in”, RUN+="/bin/ln -sf /sys%p/ /dev/gpio/din0"
ACTION==“add”, SUBSYSTEM==“gpio”, DEVPATH=="/devices/*/gpio34", ATTR{active_low}=“0”, ATTR{direction}=“in”, RUN+="/bin/ln -sf /sys%p/ /dev/gpio/din1"

But here is interesting behavior: commenting rules in file or deleting the whole file from running system with rules reloading (udevadm control --reload-rules && udevadm trigger) didn’t resolve problem - after reboot in sysfs and devfs this deleted nodes was always presented! Only way to resolve this that i discovered - do not include this udev rules file on the stage of building image with ‘debos-radxa’.
In this case if I manually create rules after system starts same gpio nodes correctly proccessed (adding/removing) by udev.

UPD: If i manually writing udev rules file (via .sh script) on another step of builder, for example, before clean_rootfs.sh - rules working normally.