06 Oct, 2012
2 commits
-
The code instantiating an i2c-mux-gpio platform device doesn't
necessarily know in advance the GPIO pin numbers it wants to use. If
pins are on a GPIO device which gets its base GPIO number assigned
dynamically at run-time, the values can't be hard-coded.In that case, let the caller tell i2c-mux-gpio the name of the GPIO
chip and the (relative) GPIO pin numbers to use. At probe time, the
i2c-mux-gpio driver will look for the chip and apply the proper offset
to turn relative GPIO pin numbers to absolute GPIO pin numbers.The same could be (and was so far) done on the caller's end, however
doing it in i2c-mux-gpio has two benefits:
* It avoids duplicating the code on every caller's side (about 30
lines of code.)
* It allows for deferred probing for the muxed part of the I2C bus
only. If finding the GPIO chip is the caller's responsibility, then
deferred probing (if the GPIO chip isn't there yet) will not only
affect the mux and the I2C bus segments behind it, but also the I2C
bus trunk.Signed-off-by: Jean Delvare
Cc: Peter Korsgaard -
Let I2C bus segments behind multiplexers have a class. This allows for
device auto-detection on these segments. As long as parent segments
don't share the same class, it should be fine.I implemented support in drivers i2c-mux-gpio and i2c-mux-pca954x. I
left i2c-mux-pca9541 and i2c-mux-pinctrl alone for the moment as I
don't know if this feature makes sense for the use cases of these
drivers.Signed-off-by: Jean Delvare
Cc: Peter Korsgaard
Cc: David Daney
Cc: Michael Lawnick
Cc: Rodolfo Giometti
12 May, 2012
1 commit
-
Update the MAINTAINERS entry and all other references accordingly.
Based on an original patch by Wolfram Sang.
Signed-off-by: Jean Delvare
Acked-by: Peter Korsgaard[wsa: fixed merge conflict due to rework in i2c_add_mux_adapter()]
Signed-off-by: Wolfram Sang