.../devicetree/bindings/i2c/i2c-mux-gpio.yaml | 3 +++ drivers/i2c/muxes/i2c-mux-gpio.c | 14 ++++++++++---- include/linux/platform_data/i2c-mux-gpio.h | 2 ++ 3 files changed, 15 insertions(+), 4 deletions(-)
Hi all, The i2c-gpio-mux can be used to describe a multiplexer built upon several i2c isolators having an enable pin (such as LTC4310): +---------------+ +------+ +------+ | +-----------+ | | dev | | dev | | | GPIO_EN_A |-|-----------| +------+ +------+ | +-----------+ | +-----+---+ | | | | |--| isol. A |---------+---------+ | +-----+ | | +---------+ | SOC | I2C |---|--| | +-----+ | | +---------+ | | |--| isol. B |------+---------+---------+ | +-----------+ | +-----+---+ | | | | | GPIO_EN_B |-|-----------| +------+ +------+ +------+ | +-----------+ | | dev | | dev | | dev | +---------------+ +------+ +------+ +------+ These isolators often need some time between their enable pin's assertion and the first i2c transfer. If the first i2c transfer happens before this enabling time is reached, transfer fails. There is no available option to configure such a time in the i2c-gpio-mux driver. Add a optional property in the bindings called 'transition-delay-us'. If present, driver waits for this delay every time a new bus is selected, i.e. before returning from the bus_select() callback. Changes in v2: * Rewrite bindings' commit log * Express the 'transition delay' in us instead of ms Changes in v3: * Rename DT property to 'settle-time-us' * Use fsleep instead of udelay [v1] : https://lore.kernel.org/all/20240527113908.127893-1-bastien.curutchet@bootlin.com/ [v2] : https://lore.kernel.org/all/20240529091739.10808-1-bastien.curutchet@bootlin.com/ Bastien Curutchet (3): dt-bindings: i2c: gpio: Add 'settle-time-us' property i2c: mux: gpio: Re-order #include to match alphabetic order i2c: mux: gpio: Add support for the 'settle-time-us' property .../devicetree/bindings/i2c/i2c-mux-gpio.yaml | 3 +++ drivers/i2c/muxes/i2c-mux-gpio.c | 14 ++++++++++---- include/linux/platform_data/i2c-mux-gpio.h | 2 ++ 3 files changed, 15 insertions(+), 4 deletions(-) -- 2.45.0
Hi Bastien, with: - commit log fixed (gpio/mux-gpio) - int/u32 changed applied to i2c/i2c-host Thanks, Andi On Mon, Jun 17, 2024 at 02:08:15PM GMT, Bastien Curutchet wrote: > Hi all, > > The i2c-gpio-mux can be used to describe a multiplexer built upon > several i2c isolators having an enable pin (such as LTC4310): > > +---------------+ +------+ +------+ > | +-----------+ | | dev | | dev | > | | GPIO_EN_A |-|-----------| +------+ +------+ > | +-----------+ | +-----+---+ | | > | | |--| isol. A |---------+---------+ > | +-----+ | | +---------+ > | SOC | I2C |---|--| > | +-----+ | | +---------+ > | | |--| isol. B |------+---------+---------+ > | +-----------+ | +-----+---+ | | | > | | GPIO_EN_B |-|-----------| +------+ +------+ +------+ > | +-----------+ | | dev | | dev | | dev | > +---------------+ +------+ +------+ +------+ > > These isolators often need some time between their enable pin's > assertion and the first i2c transfer. If the first i2c transfer > happens before this enabling time is reached, transfer fails. > > There is no available option to configure such a time in the > i2c-gpio-mux driver. > > Add a optional property in the bindings called 'transition-delay-us'. > If present, driver waits for this delay every time a new bus is > selected, i.e. before returning from the bus_select() callback. > > Changes in v2: > * Rewrite bindings' commit log > * Express the 'transition delay' in us instead of ms > > Changes in v3: > * Rename DT property to 'settle-time-us' > * Use fsleep instead of udelay > > [v1] : https://lore.kernel.org/all/20240527113908.127893-1-bastien.curutchet@bootlin.com/ > [v2] : https://lore.kernel.org/all/20240529091739.10808-1-bastien.curutchet@bootlin.com/ > > Bastien Curutchet (3): > dt-bindings: i2c: gpio: Add 'settle-time-us' property > i2c: mux: gpio: Re-order #include to match alphabetic order > i2c: mux: gpio: Add support for the 'settle-time-us' property > > .../devicetree/bindings/i2c/i2c-mux-gpio.yaml | 3 +++ > drivers/i2c/muxes/i2c-mux-gpio.c | 14 ++++++++++---- > include/linux/platform_data/i2c-mux-gpio.h | 2 ++ > 3 files changed, 15 insertions(+), 4 deletions(-) > > -- > 2.45.0 >
Hi Peter, any thoughts on this. Do you want me to go ahead and pick this series up? Andi On Mon, Jun 17, 2024 at 02:08:15PM GMT, Bastien Curutchet wrote: > Hi all, > > The i2c-gpio-mux can be used to describe a multiplexer built upon > several i2c isolators having an enable pin (such as LTC4310): > > +---------------+ +------+ +------+ > | +-----------+ | | dev | | dev | > | | GPIO_EN_A |-|-----------| +------+ +------+ > | +-----------+ | +-----+---+ | | > | | |--| isol. A |---------+---------+ > | +-----+ | | +---------+ > | SOC | I2C |---|--| > | +-----+ | | +---------+ > | | |--| isol. B |------+---------+---------+ > | +-----------+ | +-----+---+ | | | > | | GPIO_EN_B |-|-----------| +------+ +------+ +------+ > | +-----------+ | | dev | | dev | | dev | > +---------------+ +------+ +------+ +------+ > > These isolators often need some time between their enable pin's > assertion and the first i2c transfer. If the first i2c transfer > happens before this enabling time is reached, transfer fails. > > There is no available option to configure such a time in the > i2c-gpio-mux driver. > > Add a optional property in the bindings called 'transition-delay-us'. > If present, driver waits for this delay every time a new bus is > selected, i.e. before returning from the bus_select() callback. > > Changes in v2: > * Rewrite bindings' commit log > * Express the 'transition delay' in us instead of ms > > Changes in v3: > * Rename DT property to 'settle-time-us' > * Use fsleep instead of udelay > > [v1] : https://lore.kernel.org/all/20240527113908.127893-1-bastien.curutchet@bootlin.com/ > [v2] : https://lore.kernel.org/all/20240529091739.10808-1-bastien.curutchet@bootlin.com/ > > Bastien Curutchet (3): > dt-bindings: i2c: gpio: Add 'settle-time-us' property > i2c: mux: gpio: Re-order #include to match alphabetic order > i2c: mux: gpio: Add support for the 'settle-time-us' property > > .../devicetree/bindings/i2c/i2c-mux-gpio.yaml | 3 +++ > drivers/i2c/muxes/i2c-mux-gpio.c | 14 ++++++++++---- > include/linux/platform_data/i2c-mux-gpio.h | 2 ++ > 3 files changed, 15 insertions(+), 4 deletions(-) > > -- > 2.45.0 >
Hi Andi! 2024-07-09 at 23:45, Andi Shyti wrote: > Hi Peter, > > any thoughts on this. Do you want me to go ahead and pick this Looks mighty fine to me, please pick it up. And sorry to all for being unresponsive. Cheers, Peter
Hi all, On 6/17/24 14:08, Bastien Curutchet wrote: > Hi all, > > The i2c-gpio-mux can be used to describe a multiplexer built upon > several i2c isolators having an enable pin (such as LTC4310): > > +---------------+ +------+ +------+ > | +-----------+ | | dev | | dev | > | | GPIO_EN_A |-|-----------| +------+ +------+ > | +-----------+ | +-----+---+ | | > | | |--| isol. A |---------+---------+ > | +-----+ | | +---------+ > | SOC | I2C |---|--| > | +-----+ | | +---------+ > | | |--| isol. B |------+---------+---------+ > | +-----------+ | +-----+---+ | | | > | | GPIO_EN_B |-|-----------| +------+ +------+ +------+ > | +-----------+ | | dev | | dev | | dev | > +---------------+ +------+ +------+ +------+ > > These isolators often need some time between their enable pin's > assertion and the first i2c transfer. If the first i2c transfer > happens before this enabling time is reached, transfer fails. > > There is no available option to configure such a time in the > i2c-gpio-mux driver. > > Add a optional property in the bindings called 'transition-delay-us'. > If present, driver waits for this delay every time a new bus is > selected, i.e. before returning from the bus_select() callback. > > Changes in v2: > * Rewrite bindings' commit log > * Express the 'transition delay' in us instead of ms > > Changes in v3: > * Rename DT property to 'settle-time-us' > * Use fsleep instead of udelay > > [v1] : https://lore.kernel.org/all/20240527113908.127893-1-bastien.curutchet@bootlin.com/ > [v2] : https://lore.kernel.org/all/20240529091739.10808-1-bastien.curutchet@bootlin.com/ > I don't think I've received any feedback since the bindings were reviewed by Krzysztof. Has anyone had a chance to look at this V3 iteration yet? Best regards, Bastien
© 2016 - 2026 Red Hat, Inc.