Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for generic i2c-mux base-nr property #6038

Merged
merged 2 commits into from
Mar 14, 2024

Conversation

pelwell
Copy link
Contributor

@pelwell pelwell commented Mar 14, 2024

It can be desirable to have a fixed, known base address for the channels of a mux. However, there is no easy way to do that from a DT overlay (aliases ought to work, but the overlay application logic can't perform the required string pasting to create "i2c", and creating one alias per channel is tedious). To that end, create a base-nr DT property and a base parameter that allows the bus number for channel 0 to be specified, with the remaining channels allocated sequentially after it.

@pelwell
Copy link
Contributor Author

pelwell commented Mar 14, 2024

This has been seen to work: https://forums.raspberrypi.com/viewtopic.php?p=2203123#p2203123

Copy link
Collaborator

@popcornmix popcornmix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have a merge commit, but otherwise I'm okay with it.

i2c_mux_add_adapter takes a force_nr parameter that allows an explicit
bus number to be associated with a channel. However, only i2c-mux-reg
and i2c-mux-gpio make use of it.

To help with situations where it is desirable to have a fixed, known
base address for the channels of a mux, create a "base-nr" property.
When force_nr is 0 and base-nr is set and non-zero, form a force_nr
value from the sum of base-nr and the channel ID.

Signed-off-by: Phil Elwell <[email protected]>
Add a 'base' parameter to set an explicit bus number for the channels,
where the requested bus number is base + channel ID.

Signed-off-by: Phil Elwell <[email protected]>
@pelwell pelwell merged commit 841bb8e into raspberrypi:rpi-6.6.y Mar 14, 2024
12 checks passed
@6by9
Copy link
Contributor

6by9 commented Mar 15, 2024

Note comments on a7c1456 over unintended consequences of this for i2c0mux failing.
(I think it's actually due to 841bb8e at fault)

Changing force_nr should be conditional on of_property_read_u32 returning a value, otherwise with no force_nr we get the channels initialised with 0, 1, 2, etc, not all with 0.

@pelwell
Copy link
Contributor Author

pelwell commented Mar 15, 2024

I've been staring at that line, and not noticing that I had an unsaved change in my editor:

 		of_property_read_u32(dev_node, "base-nr", &base_nr);
-		if (!force_nr)
+		if (!force_nr && base_nr)
 			force_nr = base_nr + chan_id;

Now it makes sense.

@6by9
Copy link
Contributor

6by9 commented Mar 15, 2024

:-)

I was about to go for

@@ -358,8 +358,7 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
                u32 base_nr = 0;
                u32 reg;
 
-               of_property_read_u32(dev_node, "base-nr", &base_nr);
-               if (!force_nr)
+               if (!force_nr && !of_property_read_u32(dev_node, "base-nr", &base_nr))
                        force_nr = base_nr + chan_id;
 
                if (muxc->arbitrator)

Technically you could have base-nr defined as 0 if the mux was the only thing in your system, and the parent had been assigned somewhere that it wasn't going to clash. The mux child buses would then be 0, 1, 2, 3, etc, with the parent as eg 10.

@pelwell
Copy link
Contributor Author

pelwell commented Mar 15, 2024

However, other parts of the bus numbering system reject 0 as a forced value, so it's academic.

popcornmix added a commit to raspberrypi/firmware that referenced this pull request Mar 19, 2024
See: raspberrypi/linux#6054

kernel: overlays: i2c-rtc: pcf8563 supports wakeup-source
See: raspberrypi/linux#6052

kernel: ARM: dts: bcm2712: Move /soc/sound to bcm2712-rpi
See: raspberrypi/linux#6051

kernel: I2C: Improve reliability at higher bus speeds
See: raspberrypi/linux#6050

kernel: dmaengine: dw-axi-dmac: Fix a non-atomic update
See: raspberrypi/linux#6044

kernel: dtoverlays: Add a disconnect_on_idle override to i2c-mux
See: raspberrypi/linux#6040

kernel: Add support for generic i2c-mux base-nr property
See: raspberrypi/linux#6038

kernel: dtoverlays: Fixup pendown gpio polarity for ads7846 users
See: raspberrypi/linux#6029
popcornmix added a commit to raspberrypi/rpi-firmware that referenced this pull request Mar 19, 2024
See: raspberrypi/linux#6054

kernel: overlays: i2c-rtc: pcf8563 supports wakeup-source
See: raspberrypi/linux#6052

kernel: ARM: dts: bcm2712: Move /soc/sound to bcm2712-rpi
See: raspberrypi/linux#6051

kernel: I2C: Improve reliability at higher bus speeds
See: raspberrypi/linux#6050

kernel: dmaengine: dw-axi-dmac: Fix a non-atomic update
See: raspberrypi/linux#6044

kernel: dtoverlays: Add a disconnect_on_idle override to i2c-mux
See: raspberrypi/linux#6040

kernel: Add support for generic i2c-mux base-nr property
See: raspberrypi/linux#6038

kernel: dtoverlays: Fixup pendown gpio polarity for ads7846 users
See: raspberrypi/linux#6029
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants