| Message ID | 20240527113908.127893-2-bastien.curutchet@bootlin.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | i2c: mux: gpio: Add 'transition-delay-ms' property | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
On 27/05/2024 13:39, Bastien Curutchet wrote: > The i2c-gpio-mux can be used to describe a multiplexer built upon > several i2c isolators having an enable pin (such as LTC4310). These > isolators can need some time between their enable pin's assertion and > the first i2c transfer. > > Add a 'transition-delay-ms' property that indicates the delay to be > respected before doing the first i2c transfer. > That's quite limited hardware description, comparing to cover letter. Please provide full description here, not in cover letter. This is the binding, so the hardware part. Anyway, this does not look like property of mux itself. If there is no isolator, the mux would work fine, right? Then why you are not adding this property to every possible bus and I2C controller? I2C isolator could be placed there as well. So just like RC binding, that's not a property of I2C mux. Maybe this fits usage of GPIO RC / delay binding. Best regards, Krzysztof
Hi Krzysztof, On 5/27/24 16:38, Krzysztof Kozlowski wrote: > On 27/05/2024 13:39, Bastien Curutchet wrote: >> The i2c-gpio-mux can be used to describe a multiplexer built upon >> several i2c isolators having an enable pin (such as LTC4310). These >> isolators can need some time between their enable pin's assertion and >> the first i2c transfer. >> >> Add a 'transition-delay-ms' property that indicates the delay to be >> respected before doing the first i2c transfer. >> > > That's quite limited hardware description, comparing to cover letter. > Please provide full description here, not in cover letter. This is the > binding, so the hardware part. Ok, I'll add details in next iteration. > > Anyway, this does not look like property of mux itself. If there is no > isolator, the mux would work fine, right? > In the case I'm thinking about, there is no mux at all on the hardware, only two isolators. Each of them have several devices behind. I use the i2c-gpio-mux to drive the isolators enable pins to always enable only one of the isolators at a time. > Then why you are not adding this property to every possible bus and I2C > controller? I2C isolator could be placed there as well. > I actually thought about adding a description of I2C isolators because my real use case is only one I2C isolator on a I2C bus. The isolator has an enable pin that I want to drive low when the bus is unused to save power. But I didn't find a proper way to describe it. I think a property for I2C controllers is not ideal to describe the GPIO, the transition-delay and the fact that there could be devices in front of the isolator and/or devices behind it (see below) +------------+ | GPIO | | controller | +------------+ +------------+ | | I2C |------+-------------+ | | controller | | | | +------------+ +---+---+ +------+------+ | | dev A | | I2C EN|---------------+ +-------+ | isolator | +------+------+ | +-------+-----------+------- | | +---+---+ +---+---+ | dev B | | dev C | +-------+ +-------+ So I started to describe it as a device itself but then I realized that I was doing something very similar to the i2c-gpio-mux description that's why I finally submitted this patch series. > So just like RC binding, that's not a property of I2C mux. Maybe this > fits usage of GPIO RC / delay binding. > IMHO that’s more of a MUX property than an RC binding because every MUX needs some time to switch from one bus to another. It’s just that for the vast majority of MUXes, this time is so small that it doesn’t need to be described. Best regards, Bastien
On 28/05/2024 08:59, Bastien Curutchet wrote: > >> So just like RC binding, that's not a property of I2C mux. Maybe this >> fits usage of GPIO RC / delay binding. >> > > IMHO that’s more of a MUX property than an RC binding because every MUX > needs some time to switch from one bus to another. It’s just that for > the vast majority of MUXes, this time is so small that it doesn’t need > to be described. Hm, true, it's fine then. However this probably should be microseconds not milliseconds to allow greater granularity, just like gpio-delay. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml index f34cc7ad5a00..5bca58b78359 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml @@ -57,6 +57,9 @@ properties: last value used. $ref: /schemas/types.yaml#/definitions/uint32 + transition-delay-ms: + description: Delay to wait before doing any transfer when a new bus gets selected. + allOf: - $ref: i2c-mux.yaml
The i2c-gpio-mux can be used to describe a multiplexer built upon several i2c isolators having an enable pin (such as LTC4310). These isolators can need some time between their enable pin's assertion and the first i2c transfer. Add a 'transition-delay-ms' property that indicates the delay to be respected before doing the first i2c transfer. Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com> --- Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml | 3 +++ 1 file changed, 3 insertions(+)