There are two kernel subsystems involved which have slightly different behaviours - pinctrl and GPIO.You said enabling muxing on I20 while assigning GPIO44/45 to I2C1 should lead to an error and problems. Because I didn't know better until now, I did exactly that in my current setup. I am using two MIPI cameras, CAM0 on CSI0 and I2C0 (GPIO0/1) and CAM1 on CSI1 and I2C1 (GPIO44/45). In the DTOverlay for CAM0 I have enabled i2c0if and i2c0mux. In the DTOverlay for CAM2 I2C1 is assigned to GPIO44/45 using pinctrl-0 = <&i2c1_gpio44>. This setup does work fine and I can see no errors in the kernel log. Now I am a bit confused about this? Is there a chance this could work somehow?
GPIOs will set pins to being input or output, and allow reading/writing the state of them. pinctrl deals with mapping alternate functions. Both do have the concept of claiming a pin, and generally enforce exclusive use thereafter.
The i2cmux and claiming pins through pinctrl is a little odd as they get claimed when the mux switches to that output, not on probe. If I2C-1 has already mapped 44&45, I would have expected that change to the mux to fail. So potentially it would be if you did something like "sudo i2cdetect -y 10" to try and use the second mapping of i2c controller 0 that it would fail.
TBH the easiest thing is to use "pinctrl get" to see what mapping has been programmed.
How the controllers get mapped is down to device tree aliases and symbols. The i2c0 overlay changes the i2c0 alias to point at i2c0if. If you haven't done that, then the i2c11 alias is still pointing at i2c0if, and i2c0 alias is at the deactivated i2c0mux port 0.In order to fix my setup, I tried to disable the I2C0 muxing in the DTOverlay for CAM0. Therefor, I disabled i2c0mux and added pinctrl-0 = <&i2c0_gpio0> to i2c0if. I would assume to see /dev/i2c-0 now, but I only see /dev/i2c-11. Am I doing something wrong?
Statistics: Posted by 6by9 — Thu Nov 21, 2024 11:30 am