| Message ID | 20241018100338.19420-2-wojciech.siudy@nokia.com |
|---|---|
| State | New |
| Headers | show |
| Series | pca954x: Add DT bindings and driver changes for reset after timeout | expand |
Hi! > If you have a reset GPIO for the mux, then why wouldn't just use it > on timeout? Because we cannot do that on every board. The reset GPIO is provided to ensure, that we have reset signal de-asserted during initialisation. You might have connected other devices to the same reset line so this must be a configurable option. > What happens if you timeout and don't have this property? Just give up? This would be the case just like before introducting this change. Some aplications might do other attempt, the bus driver can try recovery. Unfortunately common reset line for multiple chips is not a rare situation. > Does the timeout time need to be configurable? The timeout we are talking about is error code returned from function pca954x_reg_write(), which calls smbus xfer that is out of this driver scope so there is nothing we can configure. Regards, Wojciech
On Sat, Oct 19, 2024 at 11:09:43AM +0000, Wojciech Siudy (Nokia) wrote: > Hi! > > > If you have a reset GPIO for the mux, then why wouldn't just use it > > on timeout? > > Because we cannot do that on every board. The reset GPIO is provided to > ensure, that we have reset signal de-asserted during initialisation. > You might have connected other devices to the same reset line so this > must be a configurable option. > > > What happens if you timeout and don't have this property? Just > give up? > > This would be the case just like before introducting this change. Some > aplications might do other attempt, the bus driver can try recovery. > Unfortunately common reset line for multiple chips is not a rare > situation. And Linux handles it well now. This is reset of the I2C devices (children), not the controller, right? If so, then: 1. It's not a property of the controller, 2. Linux already handles it - switch to reset controller framework. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml index 9aa0585200c9..37882a5a8c87 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml @@ -63,6 +63,11 @@ properties: necessary for example, if there are several multiplexers on the bus and the devices behind them use same I2C addresses. + i2c-mux-timeout-reset: + type: boolean + description: Sends reset pulse if channel selection or deselection times + out. Do not use if other chips share the same reset line. + idle-state: description: if present, overrides i2c-mux-idle-disconnect $ref: /schemas/mux/mux-controller.yaml#/properties/idle-state @@ -88,6 +93,9 @@ properties: register activates a channel to detect a stuck high fault. On fault the channel is isolated from the upstream bus. +dependencies: + i2c-mux-timeout-reset: [ reset-gpios ] + required: - compatible - reg @@ -146,6 +154,9 @@ examples: interrupt-parent = <&ipic>; interrupts = <17 IRQ_TYPE_LEVEL_LOW>; interrupt-controller; + reset-gpios = <&gpio1 27 1>; + i2c-mux-idle-disconnect; + i2c-mux-timeout-reset; #interrupt-cells = <2>; i2c@2 {
For cases when the mux shares reset line with other chips we cannot use it always when channel selection or deselection times out, because it could break them without proper init/probe. The property is necessary, because reset lines are board-specific. Signed-off-by: Wojciech Siudy <wojciech.siudy@nokia.com> --- Changelog: v5: * Declare dependency of a new property --- .../devicetree/bindings/i2c/i2c-mux-pca954x.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+)