Re: [PATCH v2 0/3] Add settle time support to iio-mux

From: Jonathan Cameron
Date: Mon Oct 18 2021 - 16:09:16 EST


On Sun, 17 Oct 2021 23:08:06 +0200
Peter Rosin <peda@xxxxxxxxxx> wrote:

> On 2021-10-17 19:31, Jonathan Cameron wrote:
> > On Sat, 9 Oct 2021 01:09:56 +0200
> > Peter Rosin <peda@xxxxxxxxxx> wrote:
> >
> >> Hi Vincent!
> >>
> >> On 2021-10-07 15:46, 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.
> >>>
> >>> v1 -> v2:
> >>> - Move property support to iio-mux and delay handling to mux core as suggested
> >>> by Peter.
> >>>
> >>> v1: https://lore.kernel.org/all/20211004153640.20650-1-vincent.whitchurch@xxxxxxxx/
> >>>
> >>> Vincent Whitchurch (3):
> >>> mux: add support for delay after muxing
> >>> dt-bindings: iio: io-channel-mux: Add property for settle time
> >>> iio: multiplexer: iio-mux: Support settle-time-us property
> >>>
> >>> .../iio/multiplexer/io-channel-mux.yaml | 5 +++
> >>> drivers/iio/multiplexer/iio-mux.c | 7 +++-
> >>> drivers/mux/core.c | 36 ++++++++++++++++---
> >>> include/linux/mux/consumer.h | 23 +++++++++---
> >>> include/linux/mux/driver.h | 4 +++
> >>> 5 files changed, 65 insertions(+), 10 deletions(-)
> >>>
> >>
> >> This looks really nice, thank you! The only question I see is if it should
> >> go via my (virtually unused) mux tree or via the iio tree. Yes, the meat is
> >> in mux/core.c, but I'm happy to just ack these patches and have Jonathan
> >> handle them. But, I'm also fine with handling it in the mux tree (but I'm
> >> getting old and forgetful, and it's been so many moons that I need to
> >> re-learn the steps).
> >>
> >> Jonathan, you or me? If you, you can add:
> >>
> >> Acked-by: Peter Rosin <peda@xxxxxxxxxx>
> >
> > I don't really mind, but the 4/3 and 5/3 have broken my b4 based flow + Rob
> > hasn't yet given an Ack on those two, so I'll not pick any of them up just yet.
> > I can sort out the two oddly numbered patches if Rob is happy, though they'll
> > probably not have the nice link tags that b4 automates.
> >
> > Note Rob didn't actually say he was happy with patch 2 yet as far as I can tell.
>
> Getting Rob's ack on 2/3 is of course a prerequisite to 1/3 and 3/3.
Given Rob has now given that, I'll queue these 3 patches up.

Applied to the iio-togreg branch of iio.git and pushed out as testing for 0-day
to poke at.

>
> Just ignore 4/3 and 5/3 if they are holding things back or are making things
> difficult in any way. I'll resend them later if need be, as they really have
> very little to do with this series.
>
> With hindsight I should probably have sent them as a fresh series, and I can
> re-post them as such immediately if that helps? But then again, maybe that
> just muddies the water even further...

Let's deal with those two separately. I can pick them off list if Rob is happy
with those two. The dt bindings patchwork has them as needing review so
I'm sure they'll get it shortly.

Thanks,

Jonathan

>
> Cheers,
> Peter