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
