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:   Sat, 27 Jun 2020 14:17:48 -0400
From:   William Breathitt Gray <vilhelm.gray@gmail.com>
To:     David Lechner <david@lechnology.com>
Cc:     jic23@kernel.org, kamel.bouhara@bootlin.com, gwendal@chromium.org,
        alexandre.belloni@bootlin.com, linux-iio@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        linux-stm32@st-md-mailman.stormreply.com,
        linux-arm-kernel@lists.infradead.org, syednwaris@gmail.com,
        patrick.havelange@essensium.com, fabrice.gasnier@st.com,
        mcoquelin.stm32@gmail.com, alexandre.torgue@st.com
Subject: Re: [PATCH v3 3/4] counter: Add character device interface
Message-ID: <20200627181748.GA8254@shinobu>
References: <cover.1592341702.git.vilhelm.gray@gmail.com>
 <afe40ef2e24ecaca44fc229f7983cf4cde3374a8.1592341702.git.vilhelm.gray@gmail.com>
 <8fae0659-56df-c0b5-7c0d-220feefed2b4@lechnology.com>
 <20200621195347.GA59797@shinobu>
 <47ad15e7-05ce-d463-b6af-406365b3c3b4@lechnology.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe"
Content-Disposition: inline
In-Reply-To: <47ad15e7-05ce-d463-b6af-406365b3c3b4@lechnology.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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

On Mon, Jun 22, 2020 at 09:08:48AM -0500, David Lechner wrote:
> On 6/21/20 2:53 PM, William Breathitt Gray wrote:
> > For example, in the dual-axes positioning table scenario, a user
> > application would likely want to know the exact X and Y position at the
> > time of a given event -- that means an event should provide two Count
> > values (and possibly associated device flags) when it occurs. I'm not
> > sure yet how the struct counter_event should be defined in order to
> > support this; we will need to indicate the format of data as well as
> > provide the data itself. Perhaps, we can handle this by providing an
> > unique id field so that only a single datum (e.g. a single count value)
> > is provided via the value field, but subsequent struct counter_event
> > items share the same id so that the user knows that a particular datum
> > is part of a larger group of data for a specific event.
>=20
> The timestamp could act as the "id" to correlate multiple values of a
> single event.

Okay, I see how that can work. So the /dev/counterX character nodes
would return a stream of data structures that look something like this:

struct counter_event {
	/**
	 * Best approximation of when event occurred in nanoseconds.
	 * Same timestamp value indicates data is part of same event.
	 */
	struct timeval time;
	/**
	 * Type of event that triggered. This would correlate with the
	 * IRQ set up for the device.
	 */
	__u16 type;
	/**
	 * Type of data represented by the value member. This enables
	 * the user to extract the right datatype from the value field.
	 */
	__u16 code;
	/** The value recorded when the event fired. */
	__u64 value;
};

In fact, this data structure looks a lot like struct input_event; would
it make sense to use that for this? I suppose we can't because we need
to support 64-bit value for our use cases.

Userspace also requires a way to enable the events and configure them to
report the data it wants. So perhaps the following sysfs attributes
would accomplish such:

* /sys/bus/devices/counterX/eventY_enable:
  Users can enable/disable event Y.
* /sys/bus/devices/counterX/eventY_config:
  Data to get when event Y is triggered (e.g. Counts, extensions, etc.).

Here's another concern for latency-sensitive applications: should we
handle writing data to the devices? While we have real-life examples of
latency-sensitive read operations, I'm not sure if a user will ever need
to write to a counter device within some realtime critical deadline --
I think write operations are primarily done for the purpose of
configuring the device for operation rather than during it. So perhaps
we don't need to worry about this use case because users can write data
via the existing sysfs interface.

William Breathitt Gray

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

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

iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAl73jUQACgkQhvpINdm7
VJI+5Q/9F+iiZdKk+/Rbp7+DBs4MIahPcIfm80GiTAS9+CB5A6gewetdkCiG9NtJ
kFdOjw9wRUSdB+ah+o0t0zGLC1v4q069zwrbns6giE6KsbMHItihk/pEZ1A8mel2
+Mo56yo+7n5EkkQkmnYZLRwTm0P+bRpSHGN4p0JrTaiGfsZQYnZuJuyYDwFV3EoJ
QQQwlx+OmvpNXISugKy/t/BRJzcjWNKIIuxQC3ejk1y0LUqEkU5yh8g3z3foktWw
2vQJJtTVBQNpMncSbjCysK51oF9QE3W6merHqj8nzeMKBW336cqzySFD3pOagPe8
AolVMd7YnUQ1uylD5t1/ysYPiihGkvWNO+YED2JuU12Y8oldYjI7ELpjSNUBzvie
FeHu8v7w4fcQ1SY0xm1Y5XWdKJx0WOPjfqxmcSN2t9zb1Cc4Z4/7bpM4CvErusjR
PQEukMibjwj/T5BsfdutwhIX5GHT5SVYVUKoLhe0gI4n+y3lxn4jfS638lnDBhGg
NPwhHUVksRHEh/RXyleNz2Mopt/f3cUg48O1vQA8tLcZ7nxTU1GKDOvaZ8AevVa3
H+K8URgeKInEyhkt0px9H2x83aqEk921Czcxm15qE7RY4bfIU86lZEITRE4INnmy
Qd3Nf8tIjV6Pk5F7ZKjiFAUbhrcdFsCiXM5doYGkKcfLrZuVh1I=
=sQ+8
-----END PGP SIGNATURE-----

--G4iJoqBmSsgzjUCe--