Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 28 Oct 2021 17:12:35 +0900
From:   William Breathitt Gray <vilhelm.gray@gmail.com>
To:     David Lechner <david@lechnology.com>
Cc:     linux-iio@vger.kernel.org, Robert Nelson <robertcnelson@gmail.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/8] counter/ti-eqep: add support for latched position
Message-ID: <YXpbc61WAKgN0DgU@shinobu>
References: <20211017013343.3385923-1-david@lechnology.com>
 <20211017013343.3385923-6-david@lechnology.com>
 <YXkDT2gaFfdIsgTQ@shinobu>
 <444960b4-1120-26fa-bd00-dfbe3c13cf23@lechnology.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="k9Jnbqt0PQC5h0Qc"
Content-Disposition: inline
In-Reply-To: <444960b4-1120-26fa-bd00-dfbe3c13cf23@lechnology.com>
Precedence: bulk


--k9Jnbqt0PQC5h0Qc
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 27, 2021 at 10:40:15AM -0500, David Lechner wrote:
> On 10/27/21 2:44 AM, William Breathitt Gray wrote:
> > On Sat, Oct 16, 2021 at 08:33:40PM -0500, David Lechner wrote:
> >> This adds support to the TI eQEP counter driver for a latched position.
> >> This is a new extension that gets the counter count that was recorded
> >> when an event was triggered. A new device-level latch_mode attribute is
> >> added to select the trigger. Edge capture unit support will be needed
> >> to make full use of this, but "Unit timeout" mode can already be used
> >> to calculate high speeds.
> >>
> >> The unit timer could also have attributes for latched_time and
> >> latched_period that use the same trigger. However this is not a use
> >> case at this time, so they can be added later if needed.
> >=20
> > I see that "latched_count" holds the captured counter count; would this
> > "latched_time" hold the captured unit timer time? If so, does that mean
> > setting the latch mode to "Unit timeout" always results in a
> > "latched_time" equal to 0 (assuming that's when the timeout event
> > triggers)?
> >=20
>=20
> Some `latched_*` attributes will only be useful for one `latched_mode`
> selection but not the other.
>=20
> These latched registers are used to measure speed. There are two ways
> to do this. A) measuring the change in position over a fixed time and
> B) measuring the change in time for a fixed change in position. So for
> A) latched_mode would be set to trigger on timeout and we would use
> the latched_position for the measurement. For B) we would set the
> latched_mode to trigger on reading the count register and use the
> latched_time as the measurement.
>=20
> ...
>=20
> >>   static struct counter_comp ti_eqep_device_ext[] =3D {
> >> +	COUNTER_COMP_DEVICE_ENUM("latch_mode", ti_eqep_latch_mode_read,
> >> +				ti_eqep_latch_mode_write, ti_eqep_latch_modes),
> >=20
> > It seems more appropriate to move this alongside "latched_count" as
> > Count extension because this is setting the trigger mode to latch the
> > respective Count's count. Or does this particular extension also affect
> > the "latched_time" capture for the unit timer?
> >=20
>=20
> In hardware, there are at least 3 registers that get latched that I
> recall. They are in different subsystems (main count, unit timer,
> edge capture). So as you have guessed, that is the reason for having
> the trigger selection at the device level.

Ah, I see what's going on now. I think supporting these latch registers
will involve some further considerations. I'll continue my reply in the
respective docs patch where you've gone more in depth about the
hardware.

William Breathitt Gray

--k9Jnbqt0PQC5h0Qc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAmF6W3MACgkQhvpINdm7
VJJ8Gg/+Jq2nEP9P/wcHD/LVa98CSKJST4B861rtYxFy+q3PDz2ZGrCCB8E0v/HB
RLiSoCdlPSRUkwO2KLVaIPNvhS59izkFeKzK2hm8ihFdNXo8lFa7TAhuQ0dqk/+3
rPEOtCgeYpR6g9SNaiU72hGjIPubcWHS7ZEEJk0ZSNoVScuT9cz56IljInpJ85ub
fvUGDCDwOYgLzHZuSoLmnWaXTk/5tmjx4OF8pdBE9qeRrYkvzEby374y7BuUPiI2
fEo4wQ30gtcpKZ4CCUVZNEJ5YO2fw8YF9TLhlqBPheU6FG3fKTztTPdK3ipIrtca
uRMVPqNk4GvrlRn08zOhytc/6YAw4PfEdqG2yG7l0uw42GeQRCir2zAfpoaTFEuh
1I4grzshGUhdLg4qZkq3mvtcH5QmWfLBavmfyf8p69LUYit5q5gFklI2NNdS9jBf
7Rs2FnuB2C67fqoitD1j0MJePV/yHB8T+VC+NEa2tVO6WfV1gf3hRUyC7Vw0HLG2
LsOgRkz8mhv4qGuOc7XmazQ5aZy2xqE75a2Yg0QEKz4PctwUixT9czg68WUq581G
melUOyjYRnNsBgUJWRe9EtWmoJ1LhGhxosLpqwB4gXKnAJ6evYq5LuQY4AP0/azT
4TOgHyGRQs025wKN5lyM2nmQscRdS7hQH38Mtf10eyAVtszpriU=
=v9A/
-----END PGP SIGNATURE-----

--k9Jnbqt0PQC5h0Qc--