Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1535896ybt; Sat, 27 Jun 2020 11:19:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/4obkmqV+BrsBWk8nNDu4O4mxfGLhX2TkBtpLRHCAcFl1kGX0MVowHOUWCJFaj6MPB6jF X-Received: by 2002:a17:906:f2c1:: with SMTP id gz1mr7807304ejb.88.1593281977102; Sat, 27 Jun 2020 11:19:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593281977; cv=none; d=google.com; s=arc-20160816; b=Jzfx7kSFg3lRjH2lF4dS8S1Pedkm+oBs8TuHSCx0mBVNnNlimzUmp0xu2135Ae4xi1 jL+95Jcm6vM74hREJUlXxnDiokHi9oksvcv9sg+kFqBCrbZC8Zc0mDwENb7QQ3/w6E8k o8g/+XBtvwkeFNaF1XvjUB82heygs4399piDrf4CAajt8V9Q42hETCIHNMUwm55GDk8X IgDsvwn1MvkV2UauisxXmpiAZxrwZPtfFQySs07fovbB7TcKXUJxBeVWNQJNYOS73CuS YFC3xbLvxgb7nd10u6beokRLnDmKZ/VPvW2V4jOq0511JV6drH1zFtarRC9MDOF/wrve vFVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=ZfS1zQEXxVr5pDKOKLlkhLbHYnS+buWmBwUy/Xrx/Oc=; b=GWD3XqKkyuFVDC8V8B98MZS5NdjcDiLB+n9l3RRKyQzjBl4odBaPmiieodWAp7lfAB ZIsMfAgXxAaMTH3qe6aPEquuY03AuUokX6H98NreRJXdaM7nP/BKP3U0/YGOmjWG2VVp +u4bMJmmIwkFGgO8hGmiwwwHnqmFevdamWL7C9DEQl8f4oXdprBDYMWEuwf7iZTpZ7bS uc4NPtIyPgbEFi1i8rpfeUeygCMgCBP6NvbEAoVMRQJOXyrKk7NdSFRM3x3vETms+8QM 2+bCD6/Wj3vf54gh1E0iABITKWZKgMcoLuSQ5NUU/yc7rlh1D2s7klEpYhwI0dQkjy56 wHIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qu6vSC1j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o23si12487280ejx.620.2020.06.27.11.18.59; Sat, 27 Jun 2020 11:19:37 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qu6vSC1j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726207AbgF0SSH (ORCPT + 99 others); Sat, 27 Jun 2020 14:18:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725932AbgF0SSG (ORCPT ); Sat, 27 Jun 2020 14:18:06 -0400 Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F401CC061794; Sat, 27 Jun 2020 11:18:04 -0700 (PDT) Received: by mail-qv1-xf41.google.com with SMTP id m9so5958054qvx.5; Sat, 27 Jun 2020 11:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZfS1zQEXxVr5pDKOKLlkhLbHYnS+buWmBwUy/Xrx/Oc=; b=qu6vSC1jPfgHL/kV3nJFd5+olf7eZKNmjbYU0fJa1IPH8AxS/ZUX/2wraYWI9Kb2ms 9Z4+5PDUboqbXOUl4wIJFt2wIEw0lAKftDi58QttIO7NhJb9VvpG36vh2DpAb17mLCen oSWct2KXoEYkp7FODSeUDpNfg42A01s37GDHJmkCPyXHnVVCM4ftSqFala09wf1llGrG 1sglbZr7hbHa4jayiLzxcCan3DdTmZdBUbI3knR3Xs4AmJg+x4qR9KNQqqnEiV7+cK89 b0IRVHbDtZ0mGk0OfGYi4VS/kvdp15b+dsGQDVdbKd9MO3aqZt9d0GQk58BLaeG5oMNX H0Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZfS1zQEXxVr5pDKOKLlkhLbHYnS+buWmBwUy/Xrx/Oc=; b=NX7hE/sj1cca9l9fB2gqe/mtdkOFA5v59reWFv5lBbr5jUQ+k1OSV8Ndg9ZCb2hkKb wYY781wWz6LN4NZf6E6P20mvx4+TCmWzFT4RP23oilXD4JbnC8RSK7l08JbYvaV8nSKv 7WsiDXATv4it3bUU1hOpMh3BA/JvjYkaheaHgIeyI/8jGKzCmufHiD5jxYmMGlY2Jjs1 Anav3irTz0Ttd6SiZJOQ6qxEP23RtEmOXK9OKMmHOKJfNEqiHch0fMLt8fJ24+SheB4Z mmBq9sYMDIhmT6yqhKtTICmRAmX69kojWESYHgcRdff6NgqsnyY/sz3sOsSMUnYrMeyS cGxw== X-Gm-Message-State: AOAM530TofCic/j81Y9gqdZpA6iq7Q876DKC19mfH4DnZ31VAdchCvfs J5Hw9lgqZU255TY013f3EK8= X-Received: by 2002:ad4:57b2:: with SMTP id g18mr8452730qvx.207.1593281883789; Sat, 27 Jun 2020 11:18:03 -0700 (PDT) Received: from shinobu (072-189-064-225.res.spectrum.com. [72.189.64.225]) by smtp.gmail.com with ESMTPSA id q47sm13053073qta.16.2020.06.27.11.18.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jun 2020 11:18:02 -0700 (PDT) Date: Sat, 27 Jun 2020 14:17:48 -0400 From: William Breathitt Gray To: David Lechner 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: <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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --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--