From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB1D1C433DF for ; Sat, 27 Jun 2020 19:26:20 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B08A2206BE for ; Sat, 27 Jun 2020 19:26:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rotngRqE"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="uHRvC8C1"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lechnology.com header.i=@lechnology.com header.b="K5yW/T7a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B08A2206BE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lechnology.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XQOEJJzMqoSG9Uc0MEqI9BnylnfGM33dOycNZr+Wvag=; b=rotngRqEIrVv4mNYhIipPtV1T M+vBNntH5+0Grop9i7JwVYQbohF0yZO0wBPa2UKUC0r3dWoUulAS09friQWhkL+qwYjjC3F9oQ/e0 98Gwaf/YotPR7ZWjaIz+sRPUuFLLp3NMDCldMD2E3H1A8BqRSKu0M31/QWSjcroX6EOWKJ4ZByODU t32vXOGDinPTzz766pNMx0A7u18nmbuBgSsxmm0PT0NXJ/jNGISnLB/XjXWNhZ3IO6sOKmUkYIesf UeLrfRsrd7WdeXYQ85cxpEtcCOlAz/EMQDhcmBmyXFFYftBrtlQAFcEyaHxHPpbgRvt8Si0JjuLWm aSmlfxIew==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jpGQ4-000076-4U; Sat, 27 Jun 2020 19:23:20 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jpGPv-00006p-CU for linux-arm-kernel@merlin.infradead.org; Sat, 27 Jun 2020 19:23:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description; bh=oFxURIxj9myDfJcM8l9lS1bZv4B4c/d/WWg4QVvvxCg=; b=uHRvC8C1KzRhZQRIIGoTBmjxST rXAgJZCglwVXwI0zqiAKskIOaIGveYjVSHAg/DF9J9daJEoW87bcYJFgmtOqBbYDwTwc97Pf3p9Hz 9WeBQuhVJSrMogegXfrFnt4GA+1kNxY8zaK6eDmLElYc+doO72ublIIsE9OVlfQYERouGvuOyYkyT uH8Z+VcpLesGIIMYlBaWZw9yoXeW/gnUNViO2nGcWoE8vrUe8smUhApwhg+CMbn04VznGrir4pgU9 PuqdMr+yQ0nQbghPGm4EWMMo4mxEqlfA9qGJwqgZ91rijzCzHj/E6GPX+K+rm8TvuYfHR2i2xaf3M avBi4Z0g==; Received: from vern.gendns.com ([98.142.107.122]) by casper.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jpGPL-0006ME-CH for linux-arm-kernel@lists.infradead.org; Sat, 27 Jun 2020 19:23:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lechnology.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oFxURIxj9myDfJcM8l9lS1bZv4B4c/d/WWg4QVvvxCg=; b=K5yW/T7aiN3k8SM7hUdIzsp2Ex vpB+NQsAapYuDACPwbG06es4XZ/yGb3quQ96XDPO+Z08ch2uFEaLN9DWfRDrXunOpHRs7lN18k7fp Xk7E4DJy+XK0GrlhioDBZno3Vvcw1gKP6poO5PEqDuu/0OCUGgtTRlUxCNEoahyfT2bTQjGUuB5aP Ov/uHspQt3ij42IEvPf8PeVCB6OIAqjEih+igZTiC2mjhTMs3cbrqeWPZnwAlhQp4Rrngah+huLiL kfGGjQ3mfM8t7XUfmq8d8Ps4ztnEQhZicAwply/QXg9VRPq5Eo878dYd125RGO+m6ANLCbDYt5CAZ Uunzhtsg==; Received: from 108-198-5-147.lightspeed.okcbok.sbcglobal.net ([108.198.5.147]:48498 helo=[192.168.0.134]) by vern.gendns.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jpGNj-0005ES-0L; Sat, 27 Jun 2020 15:20:55 -0400 Subject: Re: [PATCH v3 3/4] counter: Add character device interface To: William Breathitt Gray References: <8fae0659-56df-c0b5-7c0d-220feefed2b4@lechnology.com> <20200621195347.GA59797@shinobu> <47ad15e7-05ce-d463-b6af-406365b3c3b4@lechnology.com> <20200627181748.GA8254@shinobu> From: David Lechner Message-ID: Date: Sat, 27 Jun 2020 14:20:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200627181748.GA8254@shinobu> Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - lists.infradead.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200627_202258_550720_70870038 X-CRM114-Status: GOOD ( 31.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kamel.bouhara@bootlin.com, gwendal@chromium.org, alexandre.torgue@st.com, linux-iio@vger.kernel.org, patrick.havelange@essensium.com, alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mcoquelin.stm32@gmail.com, fabrice.gasnier@st.com, syednwaris@gmail.com, linux-stm32@st-md-mailman.stormreply.com, jic23@kernel.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 6/27/20 1:17 PM, William Breathitt Gray wrote: > 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. >> >> 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. Yes, since counter is its own subsystem, it makes sense to have its own data types. > > 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.). This is one of the questions I had too that I don't have a good answer to. If we want to allow the use case of multiple "consumers" for a single chardev where each consumer wants different events (e.g program X opens /dev/counter0 and wants only events A and B while program Y opens the same /dev/counter0 and wants only events A and C) then it would make sense to use an ioctl for configuration of events so that each open file descriptor could be configured differently. But if we only want to allow one user of a counter, then configuring via sysfs as you have suggested is probably fine. I think I might make sense to us an ioctl in any case though if we are going to use the same code values to configure the event. > > 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. Agreed. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel