LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Vincent Whitchurch <vincent.whitchurch@axis.com>,
	devicetree@vger.kernel.org
Cc: kernel@axis.com, robh+dt@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Add settle time support to mux-gpio
Date: Wed, 6 Oct 2021 14:24:06 +0200	[thread overview]
Message-ID: <f056ed07-46d4-7f75-f6af-29f843c37d15@axentia.se> (raw)
In-Reply-To: <20211004153640.20650-1-vincent.whitchurch@axis.com>

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

      parent reply	other threads:[~2021-10-06 12:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 15:36 Vincent Whitchurch
2021-10-04 15:36 ` [PATCH 1/2] dt-bindings: mux: gpio-mux: Add property for settle time Vincent Whitchurch
2021-10-04 15:36 ` [PATCH 2/2] mux: gpio: Support settle-time-us property Vincent Whitchurch
2021-10-06 12:24 ` Peter Rosin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f056ed07-46d4-7f75-f6af-29f843c37d15@axentia.se \
    --to=peda@axentia.se \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=vincent.whitchurch@axis.com \
    --subject='Re: [PATCH 0/2] Add settle time support to mux-gpio' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).