Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 5011

Interfacing (DSI, CSI, I2C, etc.) • Re: CM4 I2C Clarification

$
0
0
Hey,

I have spent the last hours trying to understanding the I2C concept on the CM4. In the follwing I will summarize my findings and my remaining questions, grouped by I2C bus. I would be happy if somebody could help answer the questions and correct me, if some findings are wrong.


I2C0
Owned by the VPU/Firmware by default
- Does this cause problems? Can the bus be used normally (if i2c_vc=on is NOT set in config.txt)?
Originally owned by the firmware, but largely now used from the kernel as we've switched away from the legacy camera and display stacks.
Can be muxed between GPIO0/1, GPIO28/29 and GPIO44/45
It can be, but 28&29 are used for ethernet on a CM4, so you'd be advised not to try that muxing
- Muxing is activated by setting i2c_vc=on in config.txt or by enabling i2c0if and i2c0mux in a DTOverlay
- When muxed /dev/i2c-0 corresponds to GPIO0/1, /dev/i2c-10 (= i2c_csi_dsi) corresponds to GPIO28/29 or GPIO44/45 (depending on the board wiring)
- When muxed /dev/i2c-11 also appears. What is the reason behind this interface?
It's a quirk of the kernel mux framework. The parent controller is also created, but with no pinctrl associated to it. If you try using it, you'll see whichever of i2c-0 and i2c-10 was used last (there is an option to deselect any output, but that isn't configured).
dtOverlay=i2c0,<param> disables the muxing of the bus and assigns it to fixed pins (GPIO0/1, GPIO28/29, GPIO44/45 or GPIO 46/47) -> Becomes /dev/i2c-0

What exactly does i2c_vc=on do?
You've already described it. It enables the i2c0if and i2c0mux.
dtoverlay=i2c0 enables i2c0if and assigns it some GPIOs.
I2C1
Owned by the ARM by default

dtOverlay=i2c1,<param> can be used to assign the bus to GPIO2/3 or GPIO44/45 -> Becomes /dev/i2c-1
- What happens when GPIO44/45 is selected for I2C1 and muxing is activated for I2C0? Isn't this a conflict?
It would be, so don't do it. The kernel should throw an error if you try and claim already claimed GPIOs.
What exactly does i2c_arm=on do?
dtparam=i2c_arm=on enables i2c1.
dtoverlay=i2c1 enables i2c1 and allows you to change the GPIO assignments.
I2C3
Only available in BCM2711

dtOverlay=i2c3,<param> can be used activate I2C3 and to connect it to either GPIO2/3 or GPIO4/5 -> Becomes /dev/i2c-3


I2C4
Only available in BCM2711

dtOverlay=i2c4,<param> can be used activate I2C4 and to connect it to either GPIO6/7 or GPIO8/9 -> Becomes /dev/i2c-4


I2C5

Only available in BCM2711

dtOverlay=i2c5,<param> can be used activate I2C5 and to connect it to either GPIO10/11 or GPIO12/13 -> Becomes /dev/i2c-5


I2C6

Only available in BCM2711

dtOverlay=i2c6,<param> can be used activate I2C6 and to connect it to either GPIO0/1 or GPIO22/23 -> Becomes /dev/i2c-6
- What happens when GPIO0/1 is selected for I2C6 and muxing is activated for I2C0? Isn't this a conflict?
It would be, so don't do it.

Statistics: Posted by 6by9 — Wed Nov 20, 2024 6:21 pm



Viewing all articles
Browse latest Browse all 5011

Trending Articles