-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Conversation
This has been seen to work: https://forums.raspberrypi.com/viewtopic.php?p=2203123#p2203123 |
There was a problem hiding this 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]>
Note comments on a7c1456 over unintended consequences of this for i2c0mux failing. Changing force_nr should be conditional on |
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. |
:-) I was about to go for
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. |
However, other parts of the bus numbering system reject 0 as a forced value, so it's academic. |
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
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
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 abase
parameter that allows the bus number for channel 0 to be specified, with the remaining channels allocated sequentially after it.