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
