[PATCH 0/2] Add settle time support to mux-gpio

[PATCH 0/2] Add settle time support to mux-gpio

[Vincent Whitchurch]

On one of our boards we use gpio-mux with iio-mux to read voltages using an
ADC from a few different channels, and on this board the input voltage needs
some time to stabilize after a switch of the mux.

This series add devicetree and driver support for this kind of hardware which
requries a settle time after muxing.

Vincent Whitchurch (2):
  dt-bindings: mux: gpio-mux: Add property for settle time
  mux: gpio: Support settle-time-us property

 Documentation/devicetree/bindings/mux/gpio-mux.yaml | 5 +++++
 drivers/mux/gpio.c                                  | 9 +++++++++
 2 files changed, 14 insertions(+)

-- 
2.28.0

[PATCH 1/2] dt-bindings: mux: gpio-mux: Add property for settle time

[Vincent Whitchurch]

Hardware may require some time for the muxed analog signals to settle
after the muxing is changed.  Allow this time to be specified in the
devicetree.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 Documentation/devicetree/bindings/mux/gpio-mux.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
index 0a7c8d64981a..7cffa0711f02 100644
--- a/Documentation/devicetree/bindings/mux/gpio-mux.yaml
+++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
@@ -31,6 +31,11 @@ properties:
   idle-state:
     default: -1
 
+  settle-time-us:
+    default: 0
+    description:
+      Time required for analog signals to settle after muxing.
+
 required:
   - compatible
   - mux-gpios
-- 
2.28.0

[PATCH 2/2] mux: gpio: Support settle-time-us property

[Vincent Whitchurch]

If the devicetree specifies that the hardware requires a settle time,
add an appropriate delay after the mux GPIOs are set.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 drivers/mux/gpio.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mux/gpio.c b/drivers/mux/gpio.c
index cc5f2c1861d4..17d7e03e39f0 100644
--- a/drivers/mux/gpio.c
+++ b/drivers/mux/gpio.c
@@ -8,6 +8,7 @@
  */
 
 #include <linux/bitmap.h>
+#include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/gpio/consumer.h>
 #include <linux/mod_devicetable.h>
@@ -18,12 +19,14 @@
 
 struct mux_gpio {
 	struct gpio_descs *gpios;
+	u32 delay;
 };
 
 static int mux_gpio_set(struct mux_control *mux, int state)
 {
 	struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
 	DECLARE_BITMAP(values, BITS_PER_TYPE(state));
+	u32 delay = mux_gpio->delay;
 	u32 value = state;
 
 	bitmap_from_arr32(values, &value, BITS_PER_TYPE(value));
@@ -32,6 +35,9 @@ static int mux_gpio_set(struct mux_control *mux, int state)
 				       mux_gpio->gpios->desc,
 				       mux_gpio->gpios->info, values);
 
+	if (delay)
+		fsleep(delay);
+
 	return 0;
 }
 
@@ -72,6 +78,9 @@ static int mux_gpio_probe(struct platform_device *pdev)
 	WARN_ON(pins != mux_gpio->gpios->ndescs);
 	mux_chip->mux->states = BIT(pins);
 
+	mux_gpio->delay = 0;
+	device_property_read_u32(dev, "settle-time-us", &mux_gpio->delay);
+
 	ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state);
 	if (ret >= 0 && idle_state != MUX_IDLE_AS_IS) {
 		if (idle_state < 0 || idle_state >= mux_chip->mux->states) {
-- 
2.28.0

Re: [PATCH 0/2] Add settle time support to mux-gpio

[Peter Rosin]

Hi!

On 2021-10-04 17:36, Vincent Whitchurch wrote:
> On one of our boards we use gpio-mux with iio-mux to read voltages using an
> ADC from a few different channels, and on this board the input voltage needs
> some time to stabilize after a switch of the mux.
> 
> This series add devicetree and driver support for this kind of hardware which
> requries a settle time after muxing.

It feels backwards to hide a universally useful thing like this fsleep in
drivers/mux/gpio.c. I think it belongs in drivers/iio/multiplexer/iio-mux.c
instead. Because the sleep is needed for the analog parts of the actual mux,
not the digital parts of the mux-controller.

However, currently the iio-mux does not know when the mux changes state (and
it can change state from "underneath" iio-mux by some other driver using the
same mux-control to drive some other mux).

But, fixing that so that the iio-mux knows if mux_control_select changes
the state (e.g. returning 1 instead of 0 on state changes) does not fix
this problem. Because the mux-control, again, can be used by some other
driver that changed its state right before the iio-mux selected it without
then needing a state change. And that could potentially happen quicker
than the prescribed fsleep.

So, fixing it needs some kind of new api that returns when the mux-control
changed its state last, e.g.
	ret = mux_control_select_stamp(mux, state, &stamp);
that does the same thing as mux_control_select, but also fills in a time
stamp for when the mux changed state.

Another similar option is to add an extra delay argument, e.g.
	ret = mux_control_select_delay(mux, stamp, delay_us);
that instead makes the call not return before the delay has passed since
the last state change, regardless who changed state. The mux-control would
need to keep track of when the last state changes happened of course, just
as in the above _select_stamp variant.

I think I like the last _select_delay variant best.

Cheers,
Peter