Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Fri, 13 Oct 2023 18:57:15 -0400
From:   William Breathitt Gray <william.gray@linaro.org>
To:     Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Cc:     lee@kernel.org, alexandre.torgue@foss.st.com,
        linux-iio@vger.kernel.org,
        linux-stm32@st-md-mailman.stormreply.com,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/6] counter: fix, improvements and stm32 timer events
 support
Message-ID: <ZSnLSwsr7RxLdPie@fedora>
References: <20230922143920.3144249-1-fabrice.gasnier@foss.st.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="fFNMSGoF3fO7Sh+E"
Content-Disposition: inline
In-Reply-To: <20230922143920.3144249-1-fabrice.gasnier@foss.st.com>
Precedence: bulk


--fFNMSGoF3fO7Sh+E
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 22, 2023 at 04:39:14PM +0200, Fabrice Gasnier wrote:
> This series combines some fix and improvements to the counter interface,
> found while stm32 timer counter driver developements.
> It also introduces a new tool that can be used for testing.
>=20
> Then, it improves the stm32 timer counter driver by introducing new signa=
ls,
> e.g. counting frequency, and missing channels.
> It also adds support for interrupt based events using the chrdev interfac=
e.
> Two event types are added in this series: overflows and capture.
>=20
> Up to now, stm32 timer counter driver focused mainly on quadrature
> encoder feature. With this series, all timer instances can be enabled
> for simple counting (with overflow and capture events).

Hi Fabrice,

Would you give a brief summary of the possible configurations we can
have for these devices. For example, the existing driver supports a
quadrature counting mode where Channel 1 and Channel 2 serve as A and B
inputs; I also see that another mode is a simple tally counter with the
internal clock serving as the input. How do Channel 3 and Channel 4 fit
in here?

If you list out all the possible arrangements, I think it'll help me
understand how the signals match up with each particular mode.

Thanks,

William Breathitt Gray

>=20
> Changes in v2:
> - counter fix and improvement patch applied, hence dropped in v2 series
> - mfd patch applied, hence dropped in v2 series
> - revisit watch events tool (mainly command line interface)
> - add one patch to rename STM32 Timer counter
> - various review comments from v1
>=20
> Fabrice Gasnier (6):
>   tools/counter: add a flexible watch events tool
>   counter: stm32-timer-cnt: rename quadrature signal
>   counter: stm32-timer-cnt: rename counter
>   counter: stm32-timer-cnt: introduce clock signal
>   counter: stm32-timer-cnt: populate capture channels and check encoder
>   counter: stm32-timer-cnt: add support for events
>=20
>  drivers/counter/stm32-timer-cnt.c    | 558 ++++++++++++++++++++++++++-
>  include/linux/mfd/stm32-timers.h     |  15 +
>  tools/counter/Build                  |   1 +
>  tools/counter/Makefile               |  12 +-
>  tools/counter/counter_watch_events.c | 368 ++++++++++++++++++
>  5 files changed, 934 insertions(+), 20 deletions(-)
>  create mode 100644 tools/counter/counter_watch_events.c
>=20
> --=20
> 2.25.1
>=20

--fFNMSGoF3fO7Sh+E
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEARYKAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCZSnLSwAKCRC1SFbKvhIj
KzirAQDCyH9zW+B+KquLIfRNSk5vcmFjucDHtM60OcOVpFTebgEAxPZD+Cu+RmK1
WYaD1a0bSMAQ1xu3JYrlOIxW+sxb5QM=
=QW5W
-----END PGP SIGNATURE-----

--fFNMSGoF3fO7Sh+E--