* [PATCH v2 0/4] Introduce the Counter character device interface
@ 2020-05-16 19:19 William Breathitt Gray
2020-05-16 19:20 ` [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: William Breathitt Gray @ 2020-05-16 19:19 UTC (permalink / raw)
To: jic23
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue, William Breathitt Gray
Changes in v2:
- Use fixed-width data types to represent Counter data types
- Use union of function prototypes to store read/write callbacks
- Eliminate the counter-strings and counter-sysfs-callback files by
inlining relevant code
- Reimplement chrdev code to handle read/write calls instead of ioctl
- Remove struct counter_enum (I'm postponing this development until I
get the core functionality solid)
- Remove devm_counter_unregister as unnecessary
Over the past couple years we have noticed some shortcomings with the
Counter sysfs interface. Although useful in the majority of situations,
there are certain use-cases where interacting through sysfs attributes
can become cumbersome and inefficient. A desire to support more advanced
functionality such as timestamps, multi-axis positioning tables, and
other such latency-sensitive applications, has motivated a reevaluation
of the Counter subsystem. I believe a character device interface will be
helpful for this more niche area of counter device use.
To quell any concerns from the offset: this patchset makes no changes to
the existing Counter sysfs userspace interface -- existing userspace
applications will continue to work with no modifications necessary. I
request that driver maintainers please test their applications to verify
that this is true, and report any discrepancies if they arise.
However, this patchset does contain a major reimplementation of the
Counter subsystem core and driver API. A reimplementation was necessary
in order to separate the sysfs code from the counter device drivers and
internalize it as a dedicated component of the core Counter subsystem
module. A minor benefit from all of this is that the sysfs interface is
now ensured a certain amount of consistency because the translation is
performed outside of individual counter device drivers.
Essentially, the reimplementation has enabled counter device drivers to
pass and handle data as native C datatypes now rather than the sysfs
strings from before. A high-level view of how a count value is passed
down from a counter device driver can be exemplified by the following:
----------------------
/ Counter device \
+----------------------+
| Count register: 0x28 |
+----------------------+
|
-----------------
/ raw count data /
-----------------
|
V
+----------------------------+
| Counter device driver |----------+
+----------------------------+ |
| Processes data from device | -------------------
|----------------------------| / driver callbacks /
| Type: u64 | -------------------
| Value: 42 | |
+----------------------------+ |
| |
---------- |
/ u64 / |
---------- |
| |
| V
| +----------------------+
| | Counter core |
| +----------------------+
| | Routes device driver |
| | callbacks to the |
| | userspace interfaces |
| +----------------------+
| |
| -------------------
| / driver callbacks /
| -------------------
| |
+-------+---------------+ |
| | |
| +-------|-------+
| | |
V | V
+--------------------+ | +---------------------+
| Counter sysfs |<-+->| Counter chrdev |
+--------------------+ +---------------------+
| Translates to the | | Translates to the |
| standard Counter | | standard Counter |
| sysfs output | | character device |
|--------------------| |---------------------+
| Type: const char * | | Type: u64 |
| Value: "42" | | Value: 42 |
+--------------------+ +---------------------+
| |
--------------- ----------
/ const char * / / u64 /
--------------- ----------
| |
| V
| +-----------+
| | read |
| +-----------+
| \ Count: 42 /
| -----------
|
V
+--------------------------------------------------+
| `/sys/bus/counter/devices/counterX/countY/count` |
+--------------------------------------------------+
\ Count: "42" /
--------------------------------------------------
I am aware that an in-kernel API can simplify the data transfer between
counter device drivers and the userspace interfaces, but I want to
postpone that development until after the new Counter character device
interface is solidified. A userspace ABI is effectively immutable so I
want to make sure we get that right before working on an in-kernel API
that is more flexible to change. However, when we do develop an
in-kernel API, it will likely be housed as part of the Counter core
component, through which the userspace interfaces will then communicate.
Interaction with Counter character devices occurs via standard character
device read/write operations. This allows userspace applications to
access and set counter data using native C datatypes rather than working
through string translations.
The following are some questions I have about this patchset:
1. Should the data format of the character device be configured via a
sysfs attribute?
In this patchset, the first 196095 bytes of the character device are
dedicated as a selection area to choose which Counter components or
extensions should be exposed; the subsequent bytes are the actual
data for the Counter components and extensions that were selected.
Moving this selection to a sysfs attribute and dedicating the
character device to just data transfer might be a better design. If
such a design is chosen, should the selection attribute be
human-readable or binary?
2. How much space should allotted for strings?
Each Counter component and extension has a respective size allotted
for its data (u8 data is allotted 1 byte, u64 data is allotted 8
bytes, etc.); I have arbitrarily chosen to allot 64 bytes for
strings. Is this an apt size, or should string data be allotted more
or less space?
3. Should the owning component of an extension be handled by the device
driver or Counter subsystem?
The Counter subsystem figures out the owner (enum counter_owner_type)
for each component/extension in the counter-sysfs and counter-chrdev
code. When a callback must be executed, there are various switch
statements throughout the code to check whether the respective
Device, Signal, or Count version of the callback should be executed;
similarly, the appropriate owner type must match for the struct
counter_data macros such as COUNTER_DATA_DEVICE_U64,
COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.
All this complexity in the Counter subsystem code can be eliminated
if a single callback type with a `void *owner` parameter is defined
for use with all three owner types (Device, Signal, and Count). The
device driver would then be responsible for casting the callback
argument to the appropriate owner type; but in theory, this should
not be much of a problem since the device driver is responsible for
assigning the callbacks to the owning component anyway.
William Breathitt Gray (4):
counter: Internalize sysfs interface code
docs: counter: Update to reflect sysfs internalization
counter: Add character device interface
docs: counter: Document character device interface
Documentation/driver-api/generic-counter.rst | 275 +++-
MAINTAINERS | 3 +-
drivers/counter/104-quad-8.c | 547 +++----
drivers/counter/Makefile | 1 +
drivers/counter/counter-chrdev.c | 656 ++++++++
drivers/counter/counter-chrdev.h | 16 +
drivers/counter/counter-core.c | 187 +++
drivers/counter/counter-sysfs.c | 881 +++++++++++
drivers/counter/counter-sysfs.h | 14 +
drivers/counter/counter.c | 1496 ------------------
drivers/counter/ftm-quaddec.c | 89 +-
drivers/counter/stm32-lptimer-cnt.c | 161 +-
drivers/counter/stm32-timer-cnt.c | 139 +-
drivers/counter/ti-eqep.c | 211 +--
include/linux/counter.h | 626 ++++----
include/linux/counter_enum.h | 45 -
include/uapi/linux/counter-types.h | 45 +
17 files changed, 2826 insertions(+), 2566 deletions(-)
create mode 100644 drivers/counter/counter-chrdev.c
create mode 100644 drivers/counter/counter-chrdev.h
create mode 100644 drivers/counter/counter-core.c
create mode 100644 drivers/counter/counter-sysfs.c
create mode 100644 drivers/counter/counter-sysfs.h
delete mode 100644 drivers/counter/counter.c
delete mode 100644 include/linux/counter_enum.h
create mode 100644 include/uapi/linux/counter-types.h
--
2.26.2
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization
2020-05-16 19:19 [PATCH v2 0/4] Introduce the Counter character device interface William Breathitt Gray
@ 2020-05-16 19:20 ` William Breathitt Gray
2020-05-24 16:12 ` Jonathan Cameron
2020-05-16 19:20 ` [PATCH v2 3/4] counter: Add character device interface William Breathitt Gray
` (2 subsequent siblings)
3 siblings, 1 reply; 16+ messages in thread
From: William Breathitt Gray @ 2020-05-16 19:20 UTC (permalink / raw)
To: jic23
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue, William Breathitt Gray
The Counter subsystem architecture and driver implementations have
changed in order to handle Counter sysfs interactions in a more
consistent way. This patch updates the Generic Counter interface
documentation to reflect the changes.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Documentation/driver-api/generic-counter.rst | 215 +++++++++++++------
1 file changed, 149 insertions(+), 66 deletions(-)
diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
index e622f8f6e56a..8f85c30dea0b 100644
--- a/Documentation/driver-api/generic-counter.rst
+++ b/Documentation/driver-api/generic-counter.rst
@@ -250,8 +250,8 @@ for defining a counter device.
.. kernel-doc:: drivers/counter/counter.c
:export:
-Implementation
-==============
+Driver Implementation
+=====================
To support a counter device, a driver must first allocate the available
Counter Signals via counter_signal structures. These Signals should
@@ -267,25 +267,58 @@ respective counter_count structure. These counter_count structures are
set to the counts array member of an allocated counter_device structure
before the Counter is registered to the system.
-Driver callbacks should be provided to the counter_device structure via
-a constant counter_ops structure in order to communicate with the
-device: to read and write various Signals and Counts, and to set and get
-the "action mode" and "function mode" for various Synapses and Counts
-respectively.
+Driver callbacks must be provided to the counter_device structure in
+order to communicate with the device: to read and write various Signals
+and Counts, and to set and get the "action mode" and "function mode" for
+various Synapses and Counts respectively.
A defined counter_device structure may be registered to the system by
passing it to the counter_register function, and unregistered by passing
it to the counter_unregister function. Similarly, the
-devm_counter_register and devm_counter_unregister functions may be used
-if device memory-managed registration is desired.
-
-Extension sysfs attributes can be created for auxiliary functionality
-and data by passing in defined counter_device_ext, counter_count_ext,
-and counter_signal_ext structures. In these cases, the
-counter_device_ext structure is used for global/miscellaneous exposure
-and configuration of the respective Counter device, while the
-counter_count_ext and counter_signal_ext structures allow for auxiliary
-exposure and configuration of a specific Count or Signal respectively.
+devm_counter_register function may be used if device memory-managed
+registration is desired.
+
+The struct counter_data structure is used to define counter extensions
+for Signals, Synapses, and Counts.
+
+The "type" member specifies the type of data (e.g. unsigned long,
+boolean, etc.) handled by this extension. The "read" and "write" members
+can then be set by the counter device driver with callbacks to handle
+that data.
+
+Convenience macros such as `COUNTER_DATA_COUNT_U64` are provided for use
+by driver authors. In particular, driver authors are expected to use
+the provided macros for standard Counter subsystem attributes in order
+to maintain a consistent interface for userspace. For example, a counter
+device driver may define several standard attributes like so::
+
+ struct counter_data count_ext[] = {
+ COUNTER_DATA_DIRECTION(count_direction_read),
+ COUNTER_DATA_ENABLE(count_enable_read, count_enable_write),
+ COUNTER_DATA_CEILING(count_ceiling_read, count_ceiling_write),
+ };
+
+This makes it intuitive to see, add, and modify the attributes that are
+supported by this driver ("direction", "enable", and "ceiling") and to
+maintain this code without getting lost in a web of struct braces.
+
+Callbacks must match the function type expected for the respective
+component or extension. These function types are defined in the struct
+counter_data structure as the "`*_read`" and "`*_write`" union members.
+
+The corresponding callback prototypes for the extensions mentioned in
+the previous example above would be::
+
+ int count_direction_read(struct counter_device *counter,
+ struct counter_count *count, u8 *direction);
+ int count_enable_read(struct counter_device *counter,
+ struct counter_count *count, u8 *enable);
+ int count_enable_write(struct counter_device *counter,
+ struct counter_count *count, u8 enable);
+ int count_ceiling_read(struct counter_device *counter,
+ struct counter_count *count, u64 *ceiling);
+ int count_ceiling_write(struct counter_device *counter,
+ struct counter_count *count, u64 ceiling);
Determining the type of extension to create is a matter of scope.
@@ -313,52 +346,102 @@ Determining the type of extension to create is a matter of scope.
chip overheated via a device extension called "error_overtemp":
/sys/bus/counter/devices/counterX/error_overtemp
-Architecture
-============
-
-When the Generic Counter interface counter module is loaded, the
-counter_init function is called which registers a bus_type named
-"counter" to the system. Subsequently, when the module is unloaded, the
-counter_exit function is called which unregisters the bus_type named
-"counter" from the system.
-
-Counter devices are registered to the system via the counter_register
-function, and later removed via the counter_unregister function. The
-counter_register function establishes a unique ID for the Counter
-device and creates a respective sysfs directory, where X is the
-mentioned unique ID:
-
- /sys/bus/counter/devices/counterX
-
-Sysfs attributes are created within the counterX directory to expose
-functionality, configurations, and data relating to the Counts, Signals,
-and Synapses of the Counter device, as well as options and information
-for the Counter device itself.
-
-Each Signal has a directory created to house its relevant sysfs
-attributes, where Y is the unique ID of the respective Signal:
-
- /sys/bus/counter/devices/counterX/signalY
-
-Similarly, each Count has a directory created to house its relevant
-sysfs attributes, where Y is the unique ID of the respective Count:
-
- /sys/bus/counter/devices/counterX/countY
-
-For a more detailed breakdown of the available Generic Counter interface
-sysfs attributes, please refer to the
-Documentation/ABI/testing/sysfs-bus-counter file.
-
-The Signals and Counts associated with the Counter device are registered
-to the system as well by the counter_register function. The
-signal_read/signal_write driver callbacks are associated with their
-respective Signal attributes, while the count_read/count_write and
-function_get/function_set driver callbacks are associated with their
-respective Count attributes; similarly, the same is true for the
-action_get/action_set driver callbacks and their respective Synapse
-attributes. If a driver callback is left undefined, then the respective
-read/write permission is left disabled for the relevant attributes.
-
-Similarly, extension sysfs attributes are created for the defined
-counter_device_ext, counter_count_ext, and counter_signal_ext
-structures that are passed in.
+Subsystem Architecture
+======================
+
+Counter drivers pass and take data natively (i.e. `u8`, `u64`, `char *`,
+etc.) and the shared counter module handles the translation between the
+sysfs interface. This gurantees a standard userspace interface for all
+counter drivers, and helps generalize the Generic Counter driver ABI in
+order to support the Generic Counter chrdev interface without
+significant changes to the existing counter drivers.
+
+A high-level view of how a count value is passed down from a counter
+driver can be exemplified by the following::
+
+ Count data request:
+ ~~~~~~~~~~~~~~~~~~~
+ ----------------------
+ / Counter device \
+ +----------------------+
+ | Count register: 0x28 |
+ +----------------------+
+ |
+ -----------------
+ / raw count data /
+ -----------------
+ |
+ V
+ +----------------------------+
+ | Counter device driver |----------+
+ +----------------------------+ |
+ | Processes data from device | -------------------
+ |----------------------------| / driver callbacks /
+ | Type: unsigned long | -------------------
+ | Value: 42 | |
+ +----------------------------+ |
+ | |
+ ---------------- |
+ / unsigned long / |
+ ---------------- |
+ | |
+ | V
+ | +----------------------+
+ | | Counter core |
+ | +----------------------+
+ | | Routes device driver |
+ | | callbacks to the |
+ | | userspace interfaces |
+ | +----------------------+
+ | |
+ | -------------------
+ | / driver callbacks /
+ | -------------------
+ | |
+ +-------+ |
+ | |
+ | +---------------+
+ | |
+ V |
+ +--------------------+ |
+ | Counter sysfs |<-+
+ +--------------------+
+ | Translates to the |
+ | standard Counter |
+ | sysfs output |
+ |--------------------|
+ | Type: const char * |
+ | Value: "42" |
+ +--------------------+
+ |
+ ---------------
+ / const char * /
+ ---------------
+ |
+ V
+ +--------------------------------------------------+
+ | `/sys/bus/counter/devices/counterX/countY/count` |
+ +--------------------------------------------------+
+ \ Count: "42" /
+ --------------------------------------------------
+
+There are three primary components involved:
+
+Counter device driver
+---------------------
+Communicates with the hardware device to read/write data; e.g. counter
+drivers for quadrature encoders, timers, etc.
+
+Counter core
+------------
+Registers the counter device driver to the system so that the respective
+callbacks are called during userspace interaction.
+
+Counter sysfs
+-------------
+Translates counter data to the standard Counter sysfs interface format
+and vice versa.
+
+Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
+for a detailed breakdown of the available Generic Counter interface
+sysfs attributes.
--
2.26.2
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 3/4] counter: Add character device interface
2020-05-16 19:19 [PATCH v2 0/4] Introduce the Counter character device interface William Breathitt Gray
2020-05-16 19:20 ` [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
@ 2020-05-16 19:20 ` William Breathitt Gray
2020-05-20 15:07 ` kbuild test robot
2020-05-16 19:20 ` [PATCH v2 4/4] docs: counter: Document " William Breathitt Gray
2020-05-24 16:25 ` [PATCH v2 0/4] Introduce the Counter " Jonathan Cameron
3 siblings, 1 reply; 16+ messages in thread
From: William Breathitt Gray @ 2020-05-16 19:20 UTC (permalink / raw)
To: jic23
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue, William Breathitt Gray
This patch introduces a character device interface for the Counter
subsystem. Device control is exposed through standard character device
read and write operations.
The first 196095 bytes of the character device serve as a control
selection area where control exposure of desired Counter components and
extensions may be selected. Each byte serves as a boolean selection
indicator for a respective Counter component or extension. The format of
this area is as follows:
* For each device extension, a byte is required.
* For each Signal, a byte is reserved for the Signal component, and a
byte is reserved for each Signal extension.
* For each Count, a byte is reserved for the Count component, a byte is
reserved for the count function, a byte is reserved for each Synapse
action, and byte is reserved for each Count extension.
The selected Counter components and extensions may then be interfaced
after the first 196095 bytes via standard character device read/write
operations. The number of bytes available for each component or
extension is dependent on their respective data type: u8 will have 1
byte available, u64 will have 8 bytes available, strings will have 64
bytes available, etc.
A high-level view of how a count value is passed down from a counter
driver can be exemplified by the following:
----------------------
/ Counter device \
+----------------------+
| Count register: 0x28 |
+----------------------+
|
-----------------
/ raw count data /
-----------------
|
V
+----------------------------+
| Counter device driver |----------+
+----------------------------+ |
| Processes data from device | -------------------
|----------------------------| / driver callbacks /
| Type: u64 | -------------------
| Value: 42 | |
+----------------------------+ |
| |
---------- |
/ u64 / |
---------- |
| |
| V
| +----------------------+
| | Counter core |
| +----------------------+
| | Routes device driver |
| | callbacks to the |
| | userspace interfaces |
| +----------------------+
| |
| -------------------
| / driver callbacks /
| -------------------
| |
+-------+---------------+ |
| | |
| +-------|-------+
| | |
V | V
+--------------------+ | +---------------------+
| Counter sysfs |<-+->| Counter chrdev |
+--------------------+ +---------------------+
| Translates to the | | Translates to the |
| standard Counter | | standard Counter |
| sysfs output | | character device |
|--------------------| |---------------------+
| Type: const char * | | Type: u64 |
| Value: "42" | | Value: 42 |
+--------------------+ +---------------------+
| |
--------------- ----------
/ const char * / / u64 /
--------------- ----------
| |
| V
| +-----------+
| | read |
| +-----------+
| \ Count: 42 /
| -----------
|
V
+--------------------------------------------------+
| `/sys/bus/counter/devices/counterX/countY/count` |
+--------------------------------------------------+
\ Count: "42" /
--------------------------------------------------
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
MAINTAINERS | 1 +
drivers/counter/Makefile | 2 +-
drivers/counter/counter-chrdev.c | 656 +++++++++++++++++++++++++++++++
drivers/counter/counter-chrdev.h | 16 +
drivers/counter/counter-core.c | 34 +-
include/linux/counter.h | 16 +
6 files changed, 722 insertions(+), 3 deletions(-)
create mode 100644 drivers/counter/counter-chrdev.c
create mode 100644 drivers/counter/counter-chrdev.h
diff --git a/MAINTAINERS b/MAINTAINERS
index ef72b5755793..150ad8a9bb87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4365,6 +4365,7 @@ F: Documentation/ABI/testing/sysfs-bus-counter*
F: Documentation/driver-api/generic-counter.rst
F: drivers/counter/
F: include/linux/counter.h
+F: include/uapi/linux/counter.h
F: include/uapi/linux/counter-types.h
CPMAC ETHERNET DRIVER
diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
index f48e337cbd85..d219b9c058e7 100644
--- a/drivers/counter/Makefile
+++ b/drivers/counter/Makefile
@@ -4,7 +4,7 @@
#
obj-$(CONFIG_COUNTER) += counter.o
-counter-y := counter-core.o counter-sysfs.o
+counter-y := counter-core.o counter-sysfs.o counter-chrdev.o
obj-$(CONFIG_104_QUAD_8) += 104-quad-8.o
obj-$(CONFIG_STM32_TIMER_CNT) += stm32-timer-cnt.o
diff --git a/drivers/counter/counter-chrdev.c b/drivers/counter/counter-chrdev.c
new file mode 100644
index 000000000000..7fd55bf71e47
--- /dev/null
+++ b/drivers/counter/counter-chrdev.c
@@ -0,0 +1,656 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic Counter character device interface
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+
+#include <linux/cdev.h>
+#include <linux/counter.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/fs.h>
+#include <linux/kdev_t.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/uaccess.h>
+
+enum counter_owner_type {
+ COUNTER_OWNER_TYPE_DEVICE,
+ COUNTER_OWNER_TYPE_SIGNAL,
+ COUNTER_OWNER_TYPE_COUNT,
+};
+
+struct counter_control {
+ loff_t offset;
+ size_t size;
+ struct list_head l;
+
+ struct counter_data data;
+ enum counter_owner_type type;
+ void *owner;
+};
+
+static int counter_data_u8_read(struct counter_device *const counter,
+ const struct counter_control *const control,
+ u8 __user *const buf)
+{
+ const struct counter_data *const data = &control->data;
+ int err;
+ u8 val;
+
+ switch (control->type) {
+ case COUNTER_OWNER_TYPE_DEVICE:
+ err = data->device_u8_read(counter, &val);
+ break;
+ case COUNTER_OWNER_TYPE_SIGNAL:
+ err = data->signal_u8_read(counter, control->owner, &val);
+ break;
+ case COUNTER_OWNER_TYPE_COUNT:
+ if (data->type == COUNTER_DATA_TYPE_SYNAPSE_ACTION)
+ err = data->action_read(counter, control->owner,
+ data->priv, &val);
+ else
+ err = data->count_u8_read(counter, control->owner,
+ &val);
+ break;
+ default: return -EINVAL;
+ }
+ if (err)
+ return err;
+
+ return put_user(val, buf);
+}
+
+static int counter_data_u64_read(struct counter_device *const counter,
+ const struct counter_control *const control,
+ char __user *const buf, const size_t len,
+ const size_t offset)
+{
+ const struct counter_data *const data = &control->data;
+ int err;
+ u64 val;
+
+ switch (control->type) {
+ case COUNTER_OWNER_TYPE_DEVICE:
+ err = data->device_u64_read(counter, &val);
+ break;
+ case COUNTER_OWNER_TYPE_SIGNAL:
+ err = data->signal_u64_read(counter, control->owner, &val);
+ break;
+ case COUNTER_OWNER_TYPE_COUNT:
+ err = data->count_u64_read(counter, control->owner, &val);
+ break;
+ default: return -EINVAL;
+ }
+ if (err)
+ return err;
+
+ return copy_to_user(buf, (const char *)&val + offset, len);
+}
+
+static int counter_data_string_read(struct counter_device *const counter,
+ const struct counter_control *const control,
+ char __user *const buf, const size_t len,
+ const size_t offset)
+{
+ const struct counter_data *const data = &control->data;
+ int err;
+ char str[64] = "";
+
+ switch (control->type) {
+ case COUNTER_OWNER_TYPE_DEVICE:
+ err = data->device_string_read(counter, str, sizeof(str));
+ break;
+ case COUNTER_OWNER_TYPE_SIGNAL:
+ err = data->signal_string_read(counter, control->owner, str,
+ sizeof(str));
+ break;
+ case COUNTER_OWNER_TYPE_COUNT:
+ err = data->count_string_read(counter, control->owner, str,
+ sizeof(str));
+ break;
+ default: return -EINVAL;
+ }
+ if (err < 0)
+ return err;
+
+ return copy_to_user(buf, str + offset, len);
+}
+
+static int counter_control_read(struct counter_device *const counter,
+ const struct counter_control *const control,
+ char __user *const buf, const size_t len,
+ const size_t offset)
+{
+ /* Check if read operation is supported */
+ if (!control->data.device_u8_read)
+ return -EFAULT;
+
+ switch (control->data.type) {
+ case COUNTER_DATA_TYPE_U8:
+ case COUNTER_DATA_TYPE_BOOL:
+ case COUNTER_DATA_TYPE_SIGNAL:
+ case COUNTER_DATA_TYPE_COUNT_FUNCTION:
+ case COUNTER_DATA_TYPE_SYNAPSE_ACTION:
+ case COUNTER_DATA_TYPE_COUNT_DIRECTION:
+ case COUNTER_DATA_TYPE_COUNT_MODE:
+ return counter_data_u8_read(counter, control, buf);
+ case COUNTER_DATA_TYPE_U64:
+ return counter_data_u64_read(counter, control, buf, len,
+ offset);
+ case COUNTER_DATA_TYPE_STRING:
+ return counter_data_string_read(counter, control, buf, len,
+ offset);
+ }
+
+ return -EINVAL;
+}
+
+static ssize_t counter_chrdev_read(struct file *filp, char __user *buf,
+ size_t len, loff_t *f_ps)
+{
+ const loff_t start_ps = *f_ps;
+ struct counter_device *const counter = filp->private_data;
+ size_t read_size;
+ struct counter_control *control;
+ int err;
+ loff_t next_control_ps;
+
+ /* Handle Counter control selection */
+ if (*f_ps < COUNTER_SELECTION_SIZE) {
+ read_size = (*f_ps + len > COUNTER_SELECTION_SIZE) ?
+ COUNTER_SELECTION_SIZE - *f_ps : len;
+
+ if (copy_to_user(buf, counter->selection + *f_ps, read_size))
+ return -EFAULT;
+
+ *f_ps += read_size;
+ buf += read_size;
+ len -= read_size;
+ if (!len)
+ goto exit_chrdev_read;
+ }
+
+ /* Handle controls */
+ list_for_each_entry(control, &counter->control_list, l) {
+ next_control_ps = control->offset + control->size;
+
+ /* Find first control item */
+ if (*f_ps >= next_control_ps)
+ continue;
+
+ read_size = (*f_ps + len > next_control_ps) ?
+ next_control_ps - *f_ps : len;
+
+ err = counter_control_read(counter, control, buf, read_size,
+ control->offset - *f_ps);
+ if (err)
+ return err;
+
+ *f_ps += read_size;
+ buf += read_size;
+ len -= read_size;
+ if (!len)
+ goto exit_chrdev_read;
+ }
+
+exit_chrdev_read:
+ return *f_ps - start_ps;
+}
+
+static int counter_control_ext_add(const u8 *const selection,
+ const enum counter_owner_type type,
+ void *const owner, const size_t num_ext,
+ const struct counter_data *const ext,
+ struct list_head *const cntrl_list,
+ loff_t *const offset)
+{
+ struct counter_control *p = list_last_entry(cntrl_list, typeof(*p), l);
+ struct counter_control *n;
+ size_t i;
+ struct counter_control *control;
+ int err;
+
+ for (i = 0; i < num_ext; i++) {
+ /* Check if extension is selected */
+ if (!selection[i])
+ continue;
+
+ /* Generate control list item */
+ control = kzalloc(sizeof(*control), GFP_KERNEL);
+ if (!control) {
+ err = -ENOMEM;
+ goto err_control_ext_create;
+ }
+ list_add_tail(&control->l, cntrl_list);
+
+ /* Configure control list item */
+ control->data = ext[i],
+ control->type = type;
+ control->owner = owner;
+ control->offset = *offset;
+ switch (control->data.type) {
+ case COUNTER_DATA_TYPE_U8:
+ case COUNTER_DATA_TYPE_BOOL:
+ case COUNTER_DATA_TYPE_COUNT_DIRECTION:
+ case COUNTER_DATA_TYPE_COUNT_MODE:
+ control->size = sizeof(u8);
+ break;
+ case COUNTER_DATA_TYPE_U64:
+ control->size = sizeof(u64);
+ break;
+ case COUNTER_DATA_TYPE_STRING:
+ control->size = 64;
+ break;
+ default:
+ err = -EINVAL;
+ goto err_control_ext_create;
+ }
+ *offset += control->size;
+ }
+
+ return 0;
+
+err_control_ext_create:
+ list_for_each_entry_safe_continue(p, n, cntrl_list, l) {
+ list_del(&p->l);
+ kfree(p);
+ }
+ return err;
+}
+
+static void counter_control_list_free(struct list_head *const cntrl_list)
+{
+ struct counter_control *p, *n;
+
+ list_for_each_entry_safe(p, n, cntrl_list, l) {
+ list_del(&p->l);
+ kfree(p);
+ }
+}
+
+static int counter_control_list_create(struct counter_device *const counter)
+{
+ const u8 *selection = counter->selection;
+ loff_t offset = COUNTER_SELECTION_SIZE;
+ size_t i, j;
+ struct counter_signal *signal;
+ struct counter_count *count;
+ struct counter_control *control;
+ int err;
+
+ /* Clean up old list */
+ counter_control_list_free(&counter->control_list);
+
+ /* Handle device extensions */
+ err = counter_control_ext_add(selection, COUNTER_OWNER_TYPE_DEVICE,
+ NULL, counter->num_ext, counter->ext,
+ &counter->control_list, &offset);
+ if (err)
+ goto err_control_create;
+ selection += counter->num_ext;
+
+ /* Handle Signals */
+ for (i = 0; i < counter->num_signals; i++) {
+ signal = counter->signals + i;
+
+ /* Check if Signal is selected */
+ if (*selection++) {
+ /* Generate control list item */
+ control = kzalloc(sizeof(*control), GFP_KERNEL);
+ if (!control) {
+ err = -ENOMEM;
+ goto err_control_create;
+ }
+ list_add_tail(&control->l, &counter->control_list);
+
+ /* Configure control list item */
+ control->data.type = COUNTER_DATA_TYPE_SIGNAL,
+ control->data.signal_u8_read = counter->signal_read;
+ control->type = COUNTER_OWNER_TYPE_SIGNAL;
+ control->owner = signal;
+ control->offset = offset;
+ control->size = sizeof(u8);
+ offset += control->size;
+ }
+
+ /* Handle extensions */
+ err = counter_control_ext_add(selection,
+ COUNTER_OWNER_TYPE_SIGNAL, signal,
+ signal->num_ext, signal->ext,
+ &counter->control_list, &offset);
+ if (err)
+ goto err_control_create;
+ selection += signal->num_ext;
+ }
+
+ /* Handle Counts */
+ for (i = 0; i < counter->num_counts; i++) {
+ count = counter->counts + i;
+
+ /* Check if Count is selected */
+ if (*selection++) {
+ /* Generate control list item */
+ control = kzalloc(sizeof(*control), GFP_KERNEL);
+ if (!control) {
+ err = -ENOMEM;
+ goto err_control_create;
+ }
+ list_add_tail(&control->l, &counter->control_list);
+
+ /* Configure control list item */
+ control->data.type = COUNTER_DATA_TYPE_U64,
+ control->data.count_u64_read = counter->count_read;
+ control->data.count_u64_write = counter->count_write;
+ control->type = COUNTER_OWNER_TYPE_COUNT;
+ control->owner = count;
+ control->offset = offset;
+ control->size = sizeof(u64);
+ offset += control->size;
+ }
+
+ /* Handle count function */
+ if (*selection++) {
+ /* Generate control list item */
+ control = kzalloc(sizeof(*control), GFP_KERNEL);
+ if (!control) {
+ err = -ENOMEM;
+ goto err_control_create;
+ }
+ list_add_tail(&control->l, &counter->control_list);
+
+ /* Configure control list item */
+ control->data.type = COUNTER_DATA_TYPE_COUNT_FUNCTION,
+ control->data.count_u8_read = counter->function_read;
+ control->data.count_u8_write = counter->function_write;
+ control->type = COUNTER_OWNER_TYPE_COUNT;
+ control->owner = count;
+ control->offset = offset;
+ control->size = sizeof(u8);
+ offset += control->size;
+ }
+
+ /* Handle Synapses */
+ for (j = 0; j < count->num_synapses; j++) {
+ /* Check if extension is selected */
+ if (!*selection++)
+ continue;
+
+ /* Generate control list item */
+ control = kzalloc(sizeof(*control), GFP_KERNEL);
+ if (!control) {
+ err = -ENOMEM;
+ goto err_control_create;
+ }
+ list_add_tail(&control->l, &counter->control_list);
+
+ /* Configure control list item */
+ control->data.type = COUNTER_DATA_TYPE_SYNAPSE_ACTION;
+ control->data.action_read = counter->action_read;
+ control->data.action_write = counter->action_write;
+ control->data.priv = count->synapses + j;
+ control->type = COUNTER_OWNER_TYPE_COUNT;
+ control->owner = count;
+ control->offset = offset;
+ control->size = sizeof(u8);
+ offset += control->size;
+ }
+
+ /* Handle extensions */
+ err = counter_control_ext_add(selection,
+ COUNTER_OWNER_TYPE_COUNT, count,
+ count->num_ext, count->ext,
+ &counter->control_list, &offset);
+ if (err)
+ goto err_control_create;
+ selection += count->num_ext;
+ }
+
+ return 0;
+
+err_control_create:
+ counter_control_list_free(&counter->control_list);
+ return err;
+}
+
+static int counter_data_u8_write(struct counter_device *const counter,
+ const struct counter_control *const control,
+ const u8 __user *const buf)
+{
+ const struct counter_data *const data = &control->data;
+ int err;
+ u8 val;
+
+ err = get_user(val, buf);
+ if (err)
+ return err;
+
+ switch (control->type) {
+ case COUNTER_OWNER_TYPE_DEVICE:
+ err = data->device_u8_write(counter, val);
+ break;
+ case COUNTER_OWNER_TYPE_SIGNAL:
+ err = data->signal_u8_write(counter, control->owner, val);
+ break;
+ case COUNTER_OWNER_TYPE_COUNT:
+ if (data->type == COUNTER_DATA_TYPE_SYNAPSE_ACTION)
+ err = data->action_write(counter, control->owner,
+ data->priv, val);
+ else
+ err = data->count_u8_write(counter, control->owner,
+ val);
+ break;
+ default: return -EINVAL;
+ }
+
+ return err;
+}
+
+static int counter_data_u64_write(struct counter_device *const counter,
+ const struct counter_control *const control,
+ const char __user *const buf,
+ const size_t len, const size_t offset)
+{
+ const struct counter_data *const data = &control->data;
+ int err;
+ u64 val = 0;
+
+ err = copy_from_user((char *)&val + offset, buf, len);
+ if (err)
+ return err;
+
+ switch (control->type) {
+ case COUNTER_OWNER_TYPE_DEVICE:
+ err = data->device_u64_write(counter, val);
+ break;
+ case COUNTER_OWNER_TYPE_SIGNAL:
+ err = data->signal_u64_write(counter, control->owner, val);
+ break;
+ case COUNTER_OWNER_TYPE_COUNT:
+ err = data->count_u64_write(counter, control->owner, val);
+ break;
+ default: return -EINVAL;
+ }
+
+ return err;
+}
+
+static int counter_data_string_write(struct counter_device *const counter,
+ const struct counter_control *const control,
+ const char __user *const buf,
+ const size_t len, const size_t offset)
+{
+ const struct counter_data *const data = &control->data;
+ int err;
+ char str[64] = "";
+
+ err = copy_from_user(str + offset, buf, len);
+ if (err)
+ return err;
+
+ switch (control->type) {
+ case COUNTER_OWNER_TYPE_DEVICE:
+ err = data->device_string_write(counter, str, sizeof(str));
+ break;
+ case COUNTER_OWNER_TYPE_SIGNAL:
+ err = data->signal_string_write(counter, control->owner, str,
+ sizeof(str));
+ break;
+ case COUNTER_OWNER_TYPE_COUNT:
+ err = data->count_string_write(counter, control->owner, str,
+ sizeof(str));
+ break;
+ default: return -EINVAL;
+ }
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int counter_control_write(struct counter_device *const counter,
+ const struct counter_control *const control,
+ const char __user *const buf, const size_t len,
+ const size_t offset)
+{
+ /* Check if write operation is supported */
+ if (!control->data.device_u8_write)
+ return -EFAULT;
+
+ switch (control->data.type) {
+ case COUNTER_DATA_TYPE_U8:
+ case COUNTER_DATA_TYPE_BOOL:
+ case COUNTER_DATA_TYPE_SIGNAL:
+ case COUNTER_DATA_TYPE_COUNT_FUNCTION:
+ case COUNTER_DATA_TYPE_SYNAPSE_ACTION:
+ case COUNTER_DATA_TYPE_COUNT_DIRECTION:
+ case COUNTER_DATA_TYPE_COUNT_MODE:
+ return counter_data_u8_write(counter, control, buf);
+ case COUNTER_DATA_TYPE_U64:
+ return counter_data_u64_write(counter, control, buf, len,
+ offset);
+ case COUNTER_DATA_TYPE_STRING:
+ return counter_data_string_write(counter, control, buf, len,
+ offset);
+ }
+
+ return -EINVAL;
+}
+
+static ssize_t counter_chrdev_write(struct file *filp, const char __user *buf,
+ size_t len, loff_t *f_ps)
+{
+ const loff_t start_ps = *f_ps;
+ struct counter_device *const counter = filp->private_data;
+ size_t write_size;
+ struct counter_control *control;
+ int err;
+ loff_t next_control_ps;
+
+ /* Handle Counter control selection */
+ if (*f_ps < COUNTER_SELECTION_SIZE) {
+ write_size = (*f_ps + len > COUNTER_SELECTION_SIZE) ?
+ COUNTER_SELECTION_SIZE - *f_ps : len;
+ if (copy_from_user(counter->selection + *f_ps, buf, write_size))
+ return -EFAULT;
+
+ /* Create new list based on updated selection array */
+ err = counter_control_list_create(counter);
+ if (err)
+ return err;
+
+ *f_ps += write_size;
+ buf += write_size;
+ len -= write_size;
+ if (!len)
+ goto exit_chrdev_write;
+ }
+
+ /* Handle controls */
+ list_for_each_entry(control, &counter->control_list, l) {
+ next_control_ps = control->offset + control->size;
+
+ /* Find first control item */
+ if (*f_ps >= next_control_ps)
+ continue;
+
+ write_size = (*f_ps + len > next_control_ps) ?
+ next_control_ps - *f_ps : len;
+
+ err = counter_control_write(counter, control, buf, write_size,
+ control->offset - *f_ps);
+ if (err)
+ return err;
+
+ *f_ps += write_size;
+ buf += write_size;
+ len -= write_size;
+ if (!len)
+ goto exit_chrdev_write;
+ }
+
+ return -EFAULT;
+
+exit_chrdev_write:
+ return *f_ps - start_ps;
+}
+
+static int counter_chrdev_open(struct inode *inode, struct file *filp)
+{
+ struct counter_device *const counter = container_of(inode->i_cdev,
+ typeof(*counter),
+ chrdev);
+
+ get_device(&counter->dev);
+ filp->private_data = counter;
+
+ return generic_file_open(inode, filp);
+}
+
+static int counter_chrdev_release(struct inode *inode, struct file *filp)
+{
+ struct counter_device *const counter = container_of(inode->i_cdev,
+ typeof(*counter),
+ chrdev);
+
+ put_device(&counter->dev);
+
+ return 0;
+}
+
+static const struct file_operations counter_fops = {
+ .llseek = generic_file_llseek,
+ .read = counter_chrdev_read,
+ .write = counter_chrdev_write,
+ .open = counter_chrdev_open,
+ .release = counter_chrdev_release,
+};
+
+int counter_chrdev_add(struct counter_device *const counter,
+ const dev_t counter_devt)
+{
+ struct device *const dev = &counter->dev;
+ struct cdev *const chrdev = &counter->chrdev;
+
+ /* Initialize Counter character device control selection */
+ memset(counter->selection, 0, sizeof(counter->selection));
+
+ /* Initialize Counter character device selected controls list */
+ INIT_LIST_HEAD(&counter->control_list);
+
+ /* Initialize character device */
+ cdev_init(chrdev, &counter_fops);
+ dev->devt = MKDEV(MAJOR(counter_devt), counter->id);
+ cdev_set_parent(chrdev, &dev->kobj);
+
+ return cdev_add(chrdev, dev->devt, 1);
+}
+
+void counter_chrdev_free(struct counter_device *const counter)
+{
+ cdev_del(&counter->chrdev);
+ counter_control_list_free(&counter->control_list);
+}
diff --git a/drivers/counter/counter-chrdev.h b/drivers/counter/counter-chrdev.h
new file mode 100644
index 000000000000..7ab0797d3857
--- /dev/null
+++ b/drivers/counter/counter-chrdev.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Counter character device interface
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#ifndef _COUNTER_CHRDEV_H_
+#define _COUNTER_CHRDEV_H_
+
+#include <linux/counter.h>
+#include <linux/types.h>
+
+int counter_chrdev_add(struct counter_device *const counter,
+ const dev_t counter_devt);
+void counter_chrdev_free(struct counter_device *const counter);
+
+#endif /* _COUNTER_CHRDEV_H_ */
diff --git a/drivers/counter/counter-core.c b/drivers/counter/counter-core.c
index 499664809c75..2d0886648201 100644
--- a/drivers/counter/counter-core.c
+++ b/drivers/counter/counter-core.c
@@ -6,11 +6,14 @@
#include <linux/counter.h>
#include <linux/device.h>
#include <linux/export.h>
+#include <linux/fs.h>
#include <linux/gfp.h>
#include <linux/idr.h>
#include <linux/init.h>
#include <linux/module.h>
+#include <linux/types.h>
+#include "counter-chrdev.h"
#include "counter-sysfs.h"
/* Provides a unique ID for each counter device */
@@ -33,6 +36,8 @@ static struct bus_type counter_bus_type = {
.name = "counter"
};
+static dev_t counter_devt;
+
/**
* counter_register - register Counter to the system
* @counter: pointer to Counter to register
@@ -62,10 +67,15 @@ int counter_register(struct counter_device *const counter)
device_initialize(dev);
dev_set_drvdata(dev, counter);
+ /* Add Counter character device */
+ err = counter_chrdev_add(counter, counter_devt);
+ if (err)
+ goto err_free_id;
+
/* Add Counter sysfs attributes */
err = counter_sysfs_add(counter);
if (err)
- goto err_free_id;
+ goto err_free_chrdev;
/* Add device to system */
err = device_add(dev);
@@ -76,6 +86,8 @@ int counter_register(struct counter_device *const counter)
err_free_sysfs:
counter_sysfs_free(counter);
+err_free_chrdev:
+ counter_chrdev_free(counter);
err_free_id:
ida_simple_remove(&counter_ida, counter->id);
return err;
@@ -93,6 +105,7 @@ void counter_unregister(struct counter_device *const counter)
if (counter) {
device_del(&counter->dev);
counter_sysfs_free(counter);
+ counter_chrdev_free(counter);
}
}
EXPORT_SYMBOL_GPL(counter_unregister);
@@ -139,13 +152,30 @@ int devm_counter_register(struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_counter_register);
+#define COUNTER_DEV_MAX 256
+
static int __init counter_init(void)
{
- return bus_register(&counter_bus_type);
+ int err;
+
+ err = bus_register(&counter_bus_type);
+ if (err < 0)
+ return err;
+
+ err = alloc_chrdev_region(&counter_devt, 0, COUNTER_DEV_MAX, "counter");
+ if (err < 0)
+ goto err_unregister_bus;
+
+ return 0;
+
+err_unregister_bus:
+ bus_unregister(&counter_bus_type);
+ return err;
}
static void __exit counter_exit(void)
{
+ unregister_chrdev_region(counter_devt, COUNTER_DEV_MAX);
bus_unregister(&counter_bus_type);
}
diff --git a/include/linux/counter.h b/include/linux/counter.h
index e8abbaf47a4b..22e91d00a880 100644
--- a/include/linux/counter.h
+++ b/include/linux/counter.h
@@ -6,6 +6,7 @@
#ifndef _COUNTER_H_
#define _COUNTER_H_
+#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/list.h>
@@ -170,6 +171,9 @@ struct counter_attribute_group {
* @priv: optional private data supplied by driver
* @id: unique ID used to identify the Counter
* @dev: internal device structure
+ * @chrdev: internal character device structure
+ * @selection: Counter character device control selection
+ * @control_list: Counter character device selected controls
* @dynamic_names_list: List for dynamic names
* @groups_list: attribute groups list (for Signals, Counts, and ext)
* @num_groups: number of attribute groups containers
@@ -208,6 +212,18 @@ struct counter_device {
int id;
struct device dev;
+ struct cdev chrdev;
+
+#define MAX_EXT 255
+#define MAX_SIGNALS 255
+#define MAX_SYNAPSES 255
+#define MAX_COUNTS 255
+#define SIGNALS_SELECTION_SIZE ((1 + MAX_EXT) * MAX_SIGNALS)
+#define COUNTS_SELECTION_SIZE ((1 + 1 + MAX_SYNAPSES + MAX_EXT) * MAX_COUNTS)
+#define COUNTER_SELECTION_SIZE (MAX_EXT + SIGNALS_SELECTION_SIZE + COUNTS_SELECTION_SIZE)
+ u8 selection[COUNTER_SELECTION_SIZE];
+ struct list_head control_list;
+
struct list_head dynamic_names_list;
struct counter_attribute_group *groups_list;
size_t num_groups;
--
2.26.2
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2 4/4] docs: counter: Document character device interface
2020-05-16 19:19 [PATCH v2 0/4] Introduce the Counter character device interface William Breathitt Gray
2020-05-16 19:20 ` [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
2020-05-16 19:20 ` [PATCH v2 3/4] counter: Add character device interface William Breathitt Gray
@ 2020-05-16 19:20 ` William Breathitt Gray
2020-05-24 16:19 ` Jonathan Cameron
2020-05-29 13:26 ` Pavel Machek
2020-05-24 16:25 ` [PATCH v2 0/4] Introduce the Counter " Jonathan Cameron
3 siblings, 2 replies; 16+ messages in thread
From: William Breathitt Gray @ 2020-05-16 19:20 UTC (permalink / raw)
To: jic23
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue, William Breathitt Gray
This patch adds high-level documentation about the Counter subsystem
character device interface.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
1 file changed, 76 insertions(+), 36 deletions(-)
diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
index 8f85c30dea0b..58045b33b576 100644
--- a/Documentation/driver-api/generic-counter.rst
+++ b/Documentation/driver-api/generic-counter.rst
@@ -223,19 +223,6 @@ whether an input line is differential or single-ended) and instead focus
on the core idea of what the data and process represent (e.g. position
as interpreted from quadrature encoding data).
-Userspace Interface
-===================
-
-Several sysfs attributes are generated by the Generic Counter interface,
-and reside under the /sys/bus/counter/devices/counterX directory, where
-counterX refers to the respective counter device. Please see
-Documentation/ABI/testing/sysfs-bus-counter for detailed
-information on each Generic Counter interface sysfs attribute.
-
-Through these sysfs attributes, programs and scripts may interact with
-the Generic Counter paradigm Counts, Signals, and Synapses of respective
-counter devices.
-
Driver API
==========
@@ -377,13 +364,13 @@ driver can be exemplified by the following::
+----------------------------+ |
| Processes data from device | -------------------
|----------------------------| / driver callbacks /
- | Type: unsigned long | -------------------
+ | Type: u64 | -------------------
| Value: 42 | |
+----------------------------+ |
| |
- ---------------- |
- / unsigned long / |
- ---------------- |
+ ---------- |
+ / u64 / |
+ ---------- |
| |
| V
| +----------------------+
@@ -398,25 +385,32 @@ driver can be exemplified by the following::
| / driver callbacks /
| -------------------
| |
- +-------+ |
+ +-------+---------------+ |
+ | | |
+ | +-------|-------+
+ | | |
+ V | V
+ +--------------------+ | +---------------------+
+ | Counter sysfs |<-+->| Counter chrdev |
+ +--------------------+ +---------------------+
+ | Translates to the | | Translates to the |
+ | standard Counter | | standard Counter |
+ | sysfs output | | character device |
+ |--------------------| |---------------------+
+ | Type: const char * | | Type: u64 |
+ | Value: "42" | | Value: 42 |
+ +--------------------+ +---------------------+
| |
- | +---------------+
- | |
- V |
- +--------------------+ |
- | Counter sysfs |<-+
- +--------------------+
- | Translates to the |
- | standard Counter |
- | sysfs output |
- |--------------------|
- | Type: const char * |
- | Value: "42" |
- +--------------------+
- |
- ---------------
- / const char * /
- ---------------
+ --------------- ----------
+ / const char * / / u64 /
+ --------------- ----------
+ | |
+ | V
+ | +-----------+
+ | | read |
+ | +-----------+
+ | \ Count: 42 /
+ | -----------
|
V
+--------------------------------------------------+
@@ -425,7 +419,7 @@ driver can be exemplified by the following::
\ Count: "42" /
--------------------------------------------------
-There are three primary components involved:
+There are four primary components involved:
Counter device driver
---------------------
@@ -445,3 +439,49 @@ and vice versa.
Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
for a detailed breakdown of the available Generic Counter interface
sysfs attributes.
+
+Counter chrdev
+--------------
+Translates counter data to the standard Counter character device; data
+is transferred via standard character device read/write calls.
+
+Sysfs Interface
+===============
+
+Several sysfs attributes are generated by the Generic Counter interface,
+and reside under the `/sys/bus/counter/devices/counterX` directory,
+where `X` is to the respective counter device id. Please see
+Documentation/ABI/testing/sysfs-bus-counter for detailed information on
+each Generic Counter interface sysfs attribute.
+
+Through these sysfs attributes, programs and scripts may interact with
+the Generic Counter paradigm Counts, Signals, and Synapses of respective
+counter devices.
+
+Counter Character Device
+========================
+
+Counter character device nodes are created under the `/dev` directory as
+`counterX`, where `X` is the respective counter device id. Defines for
+the standard Counter data types are exposed via the userspace
+`include/uapi/linux/counter-types.h` file.
+
+The first 196095 bytes of the character device serve as a control
+selection area where control exposure of desired Counter components and
+extensions may be selected. Each byte serves as a boolean selection
+indicator for a respective Counter component or extension. The format of
+this area is as follows:
+
+* For each device extension, a byte is required.
+* For each Signal, a byte is reserved for the Signal component, and a
+ byte is reserved for each Signal extension.
+* For each Count, a byte is reserved for the Count component, a byte is
+ reserved for the count function, a byte is reserved for each Synapse
+ action, and byte is reserved for each Count extension.
+
+The selected Counter components and extensions may then be interfaced
+after the first 196095 bytes via standard character device read/write
+operations. The number of bytes available for each component or
+extension is dependent on their respective data type: u8 will have 1
+byte available, u64 will have 8 bytes available, strings will have 64
+bytes available, etc.
--
2.26.2
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2 3/4] counter: Add character device interface
2020-05-16 19:20 ` [PATCH v2 3/4] counter: Add character device interface William Breathitt Gray
@ 2020-05-20 15:07 ` kbuild test robot
0 siblings, 0 replies; 16+ messages in thread
From: kbuild test robot @ 2020-05-20 15:07 UTC (permalink / raw)
To: William Breathitt Gray, jic23
Cc: kbuild-all, clang-built-linux, kamel.bouhara, gwendal,
alexandre.belloni, david, linux-iio, linux-kernel, linux-stm32,
linux-arm-kernel, syednwaris
[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]
Hi William,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.7-rc6 next-20200519]
[cannot apply to stm32/stm32-next linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-character-device-interface/20200517-032530
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 12bf0b632ed090358cbf03e323e5342212d0b2e4
config: arm64-randconfig-r026-20200519 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 135b877874fae96b4372c8a3fbfaa8ff44ff86e3)
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/counter/counter-chrdev.c:632:5: warning: no previous prototype for function 'counter_chrdev_add' [-Wmissing-prototypes]
int counter_chrdev_add(struct counter_device *const counter,
^
drivers/counter/counter-chrdev.c:632:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int counter_chrdev_add(struct counter_device *const counter,
^
static
>> drivers/counter/counter-chrdev.c:652:6: warning: no previous prototype for function 'counter_chrdev_free' [-Wmissing-prototypes]
void counter_chrdev_free(struct counter_device *const counter)
^
drivers/counter/counter-chrdev.c:652:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void counter_chrdev_free(struct counter_device *const counter)
^
static
2 warnings generated.
vim +/counter_chrdev_add +632 drivers/counter/counter-chrdev.c
631
> 632 int counter_chrdev_add(struct counter_device *const counter,
633 const dev_t counter_devt)
634 {
635 struct device *const dev = &counter->dev;
636 struct cdev *const chrdev = &counter->chrdev;
637
638 /* Initialize Counter character device control selection */
639 memset(counter->selection, 0, sizeof(counter->selection));
640
641 /* Initialize Counter character device selected controls list */
642 INIT_LIST_HEAD(&counter->control_list);
643
644 /* Initialize character device */
645 cdev_init(chrdev, &counter_fops);
646 dev->devt = MKDEV(MAJOR(counter_devt), counter->id);
647 cdev_set_parent(chrdev, &dev->kobj);
648
649 return cdev_add(chrdev, dev->devt, 1);
650 }
651
> 652 void counter_chrdev_free(struct counter_device *const counter)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38774 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization
2020-05-16 19:20 ` [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
@ 2020-05-24 16:12 ` Jonathan Cameron
0 siblings, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2020-05-24 16:12 UTC (permalink / raw)
To: William Breathitt Gray
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
On Sat, 16 May 2020 15:20:00 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> The Counter subsystem architecture and driver implementations have
> changed in order to handle Counter sysfs interactions in a more
> consistent way. This patch updates the Generic Counter interface
> documentation to reflect the changes.
>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Looks good to me.
Jonathan
> ---
> Documentation/driver-api/generic-counter.rst | 215 +++++++++++++------
> 1 file changed, 149 insertions(+), 66 deletions(-)
>
> diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
> index e622f8f6e56a..8f85c30dea0b 100644
> --- a/Documentation/driver-api/generic-counter.rst
> +++ b/Documentation/driver-api/generic-counter.rst
> @@ -250,8 +250,8 @@ for defining a counter device.
> .. kernel-doc:: drivers/counter/counter.c
> :export:
>
> -Implementation
> -==============
> +Driver Implementation
> +=====================
>
> To support a counter device, a driver must first allocate the available
> Counter Signals via counter_signal structures. These Signals should
> @@ -267,25 +267,58 @@ respective counter_count structure. These counter_count structures are
> set to the counts array member of an allocated counter_device structure
> before the Counter is registered to the system.
>
> -Driver callbacks should be provided to the counter_device structure via
> -a constant counter_ops structure in order to communicate with the
> -device: to read and write various Signals and Counts, and to set and get
> -the "action mode" and "function mode" for various Synapses and Counts
> -respectively.
> +Driver callbacks must be provided to the counter_device structure in
> +order to communicate with the device: to read and write various Signals
> +and Counts, and to set and get the "action mode" and "function mode" for
> +various Synapses and Counts respectively.
>
> A defined counter_device structure may be registered to the system by
> passing it to the counter_register function, and unregistered by passing
> it to the counter_unregister function. Similarly, the
> -devm_counter_register and devm_counter_unregister functions may be used
> -if device memory-managed registration is desired.
> -
> -Extension sysfs attributes can be created for auxiliary functionality
> -and data by passing in defined counter_device_ext, counter_count_ext,
> -and counter_signal_ext structures. In these cases, the
> -counter_device_ext structure is used for global/miscellaneous exposure
> -and configuration of the respective Counter device, while the
> -counter_count_ext and counter_signal_ext structures allow for auxiliary
> -exposure and configuration of a specific Count or Signal respectively.
> +devm_counter_register function may be used if device memory-managed
> +registration is desired.
> +
> +The struct counter_data structure is used to define counter extensions
> +for Signals, Synapses, and Counts.
> +
> +The "type" member specifies the type of data (e.g. unsigned long,
> +boolean, etc.) handled by this extension. The "read" and "write" members
> +can then be set by the counter device driver with callbacks to handle
> +that data.
> +
> +Convenience macros such as `COUNTER_DATA_COUNT_U64` are provided for use
> +by driver authors. In particular, driver authors are expected to use
> +the provided macros for standard Counter subsystem attributes in order
> +to maintain a consistent interface for userspace. For example, a counter
> +device driver may define several standard attributes like so::
> +
> + struct counter_data count_ext[] = {
> + COUNTER_DATA_DIRECTION(count_direction_read),
> + COUNTER_DATA_ENABLE(count_enable_read, count_enable_write),
> + COUNTER_DATA_CEILING(count_ceiling_read, count_ceiling_write),
> + };
> +
> +This makes it intuitive to see, add, and modify the attributes that are
> +supported by this driver ("direction", "enable", and "ceiling") and to
> +maintain this code without getting lost in a web of struct braces.
> +
> +Callbacks must match the function type expected for the respective
> +component or extension. These function types are defined in the struct
> +counter_data structure as the "`*_read`" and "`*_write`" union members.
> +
> +The corresponding callback prototypes for the extensions mentioned in
> +the previous example above would be::
> +
> + int count_direction_read(struct counter_device *counter,
> + struct counter_count *count, u8 *direction);
> + int count_enable_read(struct counter_device *counter,
> + struct counter_count *count, u8 *enable);
> + int count_enable_write(struct counter_device *counter,
> + struct counter_count *count, u8 enable);
> + int count_ceiling_read(struct counter_device *counter,
> + struct counter_count *count, u64 *ceiling);
> + int count_ceiling_write(struct counter_device *counter,
> + struct counter_count *count, u64 ceiling);
>
> Determining the type of extension to create is a matter of scope.
>
> @@ -313,52 +346,102 @@ Determining the type of extension to create is a matter of scope.
> chip overheated via a device extension called "error_overtemp":
> /sys/bus/counter/devices/counterX/error_overtemp
>
> -Architecture
> -============
> -
> -When the Generic Counter interface counter module is loaded, the
> -counter_init function is called which registers a bus_type named
> -"counter" to the system. Subsequently, when the module is unloaded, the
> -counter_exit function is called which unregisters the bus_type named
> -"counter" from the system.
> -
> -Counter devices are registered to the system via the counter_register
> -function, and later removed via the counter_unregister function. The
> -counter_register function establishes a unique ID for the Counter
> -device and creates a respective sysfs directory, where X is the
> -mentioned unique ID:
> -
> - /sys/bus/counter/devices/counterX
> -
> -Sysfs attributes are created within the counterX directory to expose
> -functionality, configurations, and data relating to the Counts, Signals,
> -and Synapses of the Counter device, as well as options and information
> -for the Counter device itself.
> -
> -Each Signal has a directory created to house its relevant sysfs
> -attributes, where Y is the unique ID of the respective Signal:
> -
> - /sys/bus/counter/devices/counterX/signalY
> -
> -Similarly, each Count has a directory created to house its relevant
> -sysfs attributes, where Y is the unique ID of the respective Count:
> -
> - /sys/bus/counter/devices/counterX/countY
> -
> -For a more detailed breakdown of the available Generic Counter interface
> -sysfs attributes, please refer to the
> -Documentation/ABI/testing/sysfs-bus-counter file.
> -
> -The Signals and Counts associated with the Counter device are registered
> -to the system as well by the counter_register function. The
> -signal_read/signal_write driver callbacks are associated with their
> -respective Signal attributes, while the count_read/count_write and
> -function_get/function_set driver callbacks are associated with their
> -respective Count attributes; similarly, the same is true for the
> -action_get/action_set driver callbacks and their respective Synapse
> -attributes. If a driver callback is left undefined, then the respective
> -read/write permission is left disabled for the relevant attributes.
> -
> -Similarly, extension sysfs attributes are created for the defined
> -counter_device_ext, counter_count_ext, and counter_signal_ext
> -structures that are passed in.
> +Subsystem Architecture
> +======================
> +
> +Counter drivers pass and take data natively (i.e. `u8`, `u64`, `char *`,
> +etc.) and the shared counter module handles the translation between the
> +sysfs interface. This gurantees a standard userspace interface for all
> +counter drivers, and helps generalize the Generic Counter driver ABI in
> +order to support the Generic Counter chrdev interface without
> +significant changes to the existing counter drivers.
> +
> +A high-level view of how a count value is passed down from a counter
> +driver can be exemplified by the following::
> +
> + Count data request:
> + ~~~~~~~~~~~~~~~~~~~
> + ----------------------
> + / Counter device \
> + +----------------------+
> + | Count register: 0x28 |
> + +----------------------+
> + |
> + -----------------
> + / raw count data /
> + -----------------
> + |
> + V
> + +----------------------------+
> + | Counter device driver |----------+
> + +----------------------------+ |
> + | Processes data from device | -------------------
> + |----------------------------| / driver callbacks /
> + | Type: unsigned long | -------------------
> + | Value: 42 | |
> + +----------------------------+ |
> + | |
> + ---------------- |
> + / unsigned long / |
> + ---------------- |
> + | |
> + | V
> + | +----------------------+
> + | | Counter core |
> + | +----------------------+
> + | | Routes device driver |
> + | | callbacks to the |
> + | | userspace interfaces |
> + | +----------------------+
> + | |
> + | -------------------
> + | / driver callbacks /
> + | -------------------
> + | |
> + +-------+ |
> + | |
> + | +---------------+
> + | |
> + V |
> + +--------------------+ |
> + | Counter sysfs |<-+
> + +--------------------+
> + | Translates to the |
> + | standard Counter |
> + | sysfs output |
> + |--------------------|
> + | Type: const char * |
> + | Value: "42" |
> + +--------------------+
> + |
> + ---------------
> + / const char * /
> + ---------------
> + |
> + V
> + +--------------------------------------------------+
> + | `/sys/bus/counter/devices/counterX/countY/count` |
> + +--------------------------------------------------+
> + \ Count: "42" /
> + --------------------------------------------------
> +
> +There are three primary components involved:
> +
> +Counter device driver
> +---------------------
> +Communicates with the hardware device to read/write data; e.g. counter
> +drivers for quadrature encoders, timers, etc.
> +
> +Counter core
> +------------
> +Registers the counter device driver to the system so that the respective
> +callbacks are called during userspace interaction.
> +
> +Counter sysfs
> +-------------
> +Translates counter data to the standard Counter sysfs interface format
> +and vice versa.
> +
> +Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
> +for a detailed breakdown of the available Generic Counter interface
> +sysfs attributes.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 4/4] docs: counter: Document character device interface
2020-05-16 19:20 ` [PATCH v2 4/4] docs: counter: Document " William Breathitt Gray
@ 2020-05-24 16:19 ` Jonathan Cameron
2020-05-29 13:26 ` Pavel Machek
1 sibling, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2020-05-24 16:19 UTC (permalink / raw)
To: William Breathitt Gray
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
On Sat, 16 May 2020 15:20:02 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> This patch adds high-level documentation about the Counter subsystem
> character device interface.
>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
> Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
> 1 file changed, 76 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
> index 8f85c30dea0b..58045b33b576 100644
> --- a/Documentation/driver-api/generic-counter.rst
> +++ b/Documentation/driver-api/generic-counter.rst
> @@ -223,19 +223,6 @@ whether an input line is differential or single-ended) and instead focus
> on the core idea of what the data and process represent (e.g. position
> as interpreted from quadrature encoding data).
>
> -Userspace Interface
> -===================
> -
> -Several sysfs attributes are generated by the Generic Counter interface,
> -and reside under the /sys/bus/counter/devices/counterX directory, where
> -counterX refers to the respective counter device. Please see
> -Documentation/ABI/testing/sysfs-bus-counter for detailed
> -information on each Generic Counter interface sysfs attribute.
> -
> -Through these sysfs attributes, programs and scripts may interact with
> -the Generic Counter paradigm Counts, Signals, and Synapses of respective
> -counter devices.
> -
> Driver API
> ==========
>
> @@ -377,13 +364,13 @@ driver can be exemplified by the following::
> +----------------------------+ |
> | Processes data from device | -------------------
> |----------------------------| / driver callbacks /
> - | Type: unsigned long | -------------------
> + | Type: u64 | -------------------
> | Value: 42 | |
> +----------------------------+ |
> | |
> - ---------------- |
> - / unsigned long / |
> - ---------------- |
> + ---------- |
> + / u64 / |
> + ---------- |
> | |
> | V
> | +----------------------+
> @@ -398,25 +385,32 @@ driver can be exemplified by the following::
> | / driver callbacks /
> | -------------------
> | |
> - +-------+ |
> + +-------+---------------+ |
> + | | |
> + | +-------|-------+
> + | | |
> + V | V
> + +--------------------+ | +---------------------+
> + | Counter sysfs |<-+->| Counter chrdev |
> + +--------------------+ +---------------------+
> + | Translates to the | | Translates to the |
> + | standard Counter | | standard Counter |
> + | sysfs output | | character device |
> + |--------------------| |---------------------+
> + | Type: const char * | | Type: u64 |
> + | Value: "42" | | Value: 42 |
> + +--------------------+ +---------------------+
> | |
> - | +---------------+
> - | |
> - V |
> - +--------------------+ |
> - | Counter sysfs |<-+
> - +--------------------+
> - | Translates to the |
> - | standard Counter |
> - | sysfs output |
> - |--------------------|
> - | Type: const char * |
> - | Value: "42" |
> - +--------------------+
> - |
> - ---------------
> - / const char * /
> - ---------------
> + --------------- ----------
> + / const char * / / u64 /
> + --------------- ----------
> + | |
> + | V
> + | +-----------+
> + | | read |
> + | +-----------+
> + | \ Count: 42 /
> + | -----------
> |
> V
> +--------------------------------------------------+
> @@ -425,7 +419,7 @@ driver can be exemplified by the following::
> \ Count: "42" /
> --------------------------------------------------
>
> -There are three primary components involved:
> +There are four primary components involved:
>
> Counter device driver
> ---------------------
> @@ -445,3 +439,49 @@ and vice versa.
> Please refer to the `Documentation/ABI/testing/sysfs-bus-counter` file
> for a detailed breakdown of the available Generic Counter interface
> sysfs attributes.
> +
> +Counter chrdev
> +--------------
> +Translates counter data to the standard Counter character device; data
> +is transferred via standard character device read/write calls.
> +
> +Sysfs Interface
> +===============
> +
> +Several sysfs attributes are generated by the Generic Counter interface,
> +and reside under the `/sys/bus/counter/devices/counterX` directory,
> +where `X` is to the respective counter device id. Please see
> +Documentation/ABI/testing/sysfs-bus-counter for detailed information on
> +each Generic Counter interface sysfs attribute.
> +
> +Through these sysfs attributes, programs and scripts may interact with
> +the Generic Counter paradigm Counts, Signals, and Synapses of respective
> +counter devices.
> +
> +Counter Character Device
> +========================
> +
> +Counter character device nodes are created under the `/dev` directory as
> +`counterX`, where `X` is the respective counter device id. Defines for
> +the standard Counter data types are exposed via the userspace
> +`include/uapi/linux/counter-types.h` file.
> +
> +The first 196095 bytes of the character device serve as a control
> +selection area where control exposure of desired Counter components and
> +extensions may be selected. Each byte serves as a boolean selection
> +indicator for a respective Counter component or extension. The format of
> +this area is as follows:
> +
> +* For each device extension, a byte is required.
> +* For each Signal, a byte is reserved for the Signal component, and a
> + byte is reserved for each Signal extension.
> +* For each Count, a byte is reserved for the Count component, a byte is
> + reserved for the count function, a byte is reserved for each Synapse
> + action, and byte is reserved for each Count extension.
> +
> +The selected Counter components and extensions may then be interfaced
> +after the first 196095 bytes via standard character device read/write
> +operations. The number of bytes available for each component or
> +extension is dependent on their respective data type: u8 will have 1
> +byte available, u64 will have 8 bytes available, strings will have 64
> +bytes available, etc.
From what I recall of the earlier conversation, I'm not sure this is what
was being suggested. I 'think' what people were after was a simple
read interface for just the counters (+ timestamps). This would also
include the option to use select / poll on the counter.
Simply moving over to a read / write really doesn't help for ease of use.
I'm not sure what the right control approach is, or perhaps if we even
need one (could just output all counts provided by hardware once the
chrdev is opened).
Jonathan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
2020-05-16 19:19 [PATCH v2 0/4] Introduce the Counter character device interface William Breathitt Gray
` (2 preceding siblings ...)
2020-05-16 19:20 ` [PATCH v2 4/4] docs: counter: Document " William Breathitt Gray
@ 2020-05-24 16:25 ` Jonathan Cameron
2020-05-24 17:54 ` William Breathitt Gray
3 siblings, 1 reply; 16+ messages in thread
From: Jonathan Cameron @ 2020-05-24 16:25 UTC (permalink / raw)
To: William Breathitt Gray
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
...
> The following are some questions I have about this patchset:
>
> 1. Should the data format of the character device be configured via a
> sysfs attribute?
>
> In this patchset, the first 196095 bytes of the character device are
> dedicated as a selection area to choose which Counter components or
> extensions should be exposed; the subsequent bytes are the actual
> data for the Counter components and extensions that were selected.
That sounds like the worst of all possible worlds. Reality is you need
to do some magic library so at that point you might as well have ioctl
options to configure it. I wonder if you can keep the data flow
to be a simple 'read' from the chardev but move the control away from
that. Either control via some chrdevs but keep them to the 'set / get'
if this element is going to turn up in the read or not. You rapidly
run into problems though, such as now to see how large a given element
is going to be etc. Plus ioctls are rather messier to extend than
simply adding a new sysfs file. Various subsystems do complex
'descriptor' type approaches to get around this, or you could do
self describing records rather than raw data - like an input
ev_dev event.
>
> Moving this selection to a sysfs attribute and dedicating the
> character device to just data transfer might be a better design. If
> such a design is chosen, should the selection attribute be
> human-readable or binary?
Sysfs basically requires things are more or less human readable.
So if you go that way I think it needs to be.
>
> 2. How much space should allotted for strings?
>
> Each Counter component and extension has a respective size allotted
> for its data (u8 data is allotted 1 byte, u64 data is allotted 8
> bytes, etc.); I have arbitrarily chosen to allot 64 bytes for
> strings. Is this an apt size, or should string data be allotted more
> or less space?
I'd go with that being big enough, but try to keep the expose interface
such that the size can change it it needs to the in the future.
>
> 3. Should the owning component of an extension be handled by the device
> driver or Counter subsystem?
>
> The Counter subsystem figures out the owner (enum counter_owner_type)
> for each component/extension in the counter-sysfs and counter-chrdev
> code. When a callback must be executed, there are various switch
> statements throughout the code to check whether the respective
> Device, Signal, or Count version of the callback should be executed;
> similarly, the appropriate owner type must match for the struct
> counter_data macros such as COUNTER_DATA_DEVICE_U64,
> COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.
>
> All this complexity in the Counter subsystem code can be eliminated
> if a single callback type with a `void *owner` parameter is defined
> for use with all three owner types (Device, Signal, and Count). The
> device driver would then be responsible for casting the callback
> argument to the appropriate owner type; but in theory, this should
> not be much of a problem since the device driver is responsible for
> assigning the callbacks to the owning component anyway.
Whilst its more complex for subsytem I think it's better to keep everything
typed if we possibly can. Always a trade off though, so use your discretion.
Jonathan
>
> William Breathitt Gray (4):
> counter: Internalize sysfs interface code
> docs: counter: Update to reflect sysfs internalization
> counter: Add character device interface
> docs: counter: Document character device interface
>
> Documentation/driver-api/generic-counter.rst | 275 +++-
> MAINTAINERS | 3 +-
> drivers/counter/104-quad-8.c | 547 +++----
> drivers/counter/Makefile | 1 +
> drivers/counter/counter-chrdev.c | 656 ++++++++
> drivers/counter/counter-chrdev.h | 16 +
> drivers/counter/counter-core.c | 187 +++
> drivers/counter/counter-sysfs.c | 881 +++++++++++
> drivers/counter/counter-sysfs.h | 14 +
> drivers/counter/counter.c | 1496 ------------------
> drivers/counter/ftm-quaddec.c | 89 +-
> drivers/counter/stm32-lptimer-cnt.c | 161 +-
> drivers/counter/stm32-timer-cnt.c | 139 +-
> drivers/counter/ti-eqep.c | 211 +--
> include/linux/counter.h | 626 ++++----
> include/linux/counter_enum.h | 45 -
> include/uapi/linux/counter-types.h | 45 +
> 17 files changed, 2826 insertions(+), 2566 deletions(-)
> create mode 100644 drivers/counter/counter-chrdev.c
> create mode 100644 drivers/counter/counter-chrdev.h
> create mode 100644 drivers/counter/counter-core.c
> create mode 100644 drivers/counter/counter-sysfs.c
> create mode 100644 drivers/counter/counter-sysfs.h
> delete mode 100644 drivers/counter/counter.c
> delete mode 100644 include/linux/counter_enum.h
> create mode 100644 include/uapi/linux/counter-types.h
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
2020-05-24 16:25 ` [PATCH v2 0/4] Introduce the Counter " Jonathan Cameron
@ 2020-05-24 17:54 ` William Breathitt Gray
2020-05-31 15:18 ` Jonathan Cameron
0 siblings, 1 reply; 16+ messages in thread
From: William Breathitt Gray @ 2020-05-24 17:54 UTC (permalink / raw)
To: Jonathan Cameron
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
[-- Attachment #1: Type: text/plain, Size: 9099 bytes --]
On Sun, May 24, 2020 at 05:25:42PM +0100, Jonathan Cameron wrote:
>
> ...
>
> > The following are some questions I have about this patchset:
> >
> > 1. Should the data format of the character device be configured via a
> > sysfs attribute?
> >
> > In this patchset, the first 196095 bytes of the character device are
> > dedicated as a selection area to choose which Counter components or
> > extensions should be exposed; the subsequent bytes are the actual
> > data for the Counter components and extensions that were selected.
>
> That sounds like the worst of all possible worlds. Reality is you need
> to do some magic library so at that point you might as well have ioctl
> options to configure it. I wonder if you can keep the data flow
> to be a simple 'read' from the chardev but move the control away from
> that. Either control via some chrdevs but keep them to the 'set / get'
> if this element is going to turn up in the read or not. You rapidly
> run into problems though, such as now to see how large a given element
> is going to be etc. Plus ioctls are rather messier to extend than
> simply adding a new sysfs file. Various subsystems do complex
> 'descriptor' type approaches to get around this, or you could do
> self describing records rather than raw data - like an input
> ev_dev event.
Yes I agree, I don't think combining nondata with data is good design --
it's better if users are able to simply perform read/write on the
character device without having to keep track of valid offsets and
controls.
After giving this some more thought, I believe human-readable sysfs
attributes are the way to go to support configuration of the character
device. I am thinking of a system like this:
* Users configure the counter character device via a sysfs attribute
such as /sys/bus/counter/devices/counterX/chrdev_format or similar.
* Users may write to this sysfs attribute to select the components they
want to interface -- the layout can be determined as well from the
order. For example:
# echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format
This would select Counts 0, 3, and 2 (in that order) to be available
in the /dev/counter0 node as a contiguous memory region.
You can select extensions in a similar fashion:
# echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format
This would select extension 2 from Count 4, and extension 0 from
Signal 1.
* Users may read from this chrdev_format sysfs attribute in order to see
the currently configured format of the character device.
* Users may perform read/write operations on the /dev/counterX node
directly; the layout of the data is what they user has configured via
the chrdev_format sysfs attribute. For example:
# echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format
Yields the following /dev/counter0 memory layout:
+-----------------+------------------+----------+----------+
| Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16 | Byte 17 |
+-----------------+------------------+----------+----------+
| Count 0 | Count 1 | Signal 0 | Signal 2 |
+-----------------+------------------+----------+----------+
* Users may perform select/poll operations on the /dev/counterX node.
Users can be notified if data is available or events have occurred.
The benefit of this design is that the format is robust so users can
choose the components they want to interface and in the layout they
want. For example, if I am writing a userspace application to control a
dual-axis positioning table, I can select the two counts I care about
for the position axes. This allows me to read just those two values
directly from /dev/counterX with a simple read() call, without having to
fumble around seeking to an offset and parsing the layout.
Similarly, support for future extensions is simple to implement. When
timestamp support is implemented, users can just select the desired
timestamp extension and read it directly from the /dev/counterX node;
they should also be able to perform a select()/poll() call to be
notified on new timestamps.
So what do you think of this sort of design? I think there is a useful
robustness to the simplicity of performing a single read/write call on
/dev/counterX.
> >
> > Moving this selection to a sysfs attribute and dedicating the
> > character device to just data transfer might be a better design. If
> > such a design is chosen, should the selection attribute be
> > human-readable or binary?
>
> Sysfs basically requires things are more or less human readable.
> So if you go that way I think it needs to be.
>
> >
> > 2. How much space should allotted for strings?
> >
> > Each Counter component and extension has a respective size allotted
> > for its data (u8 data is allotted 1 byte, u64 data is allotted 8
> > bytes, etc.); I have arbitrarily chosen to allot 64 bytes for
> > strings. Is this an apt size, or should string data be allotted more
> > or less space?
>
> I'd go with that being big enough, but try to keep the expose interface
> such that the size can change it it needs to the in the future.
Following along with the separation of control vs data as discussed
above, we could support a more variable size by exposing it through a
sysfs attribute (maybe a chrdev_string_size attribute or similar).
>
> >
> > 3. Should the owning component of an extension be handled by the device
> > driver or Counter subsystem?
> >
> > The Counter subsystem figures out the owner (enum counter_owner_type)
> > for each component/extension in the counter-sysfs and counter-chrdev
> > code. When a callback must be executed, there are various switch
> > statements throughout the code to check whether the respective
> > Device, Signal, or Count version of the callback should be executed;
> > similarly, the appropriate owner type must match for the struct
> > counter_data macros such as COUNTER_DATA_DEVICE_U64,
> > COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.
> >
> > All this complexity in the Counter subsystem code can be eliminated
> > if a single callback type with a `void *owner` parameter is defined
> > for use with all three owner types (Device, Signal, and Count). The
> > device driver would then be responsible for casting the callback
> > argument to the appropriate owner type; but in theory, this should
> > not be much of a problem since the device driver is responsible for
> > assigning the callbacks to the owning component anyway.
>
> Whilst its more complex for subsytem I think it's better to keep everything
> typed if we possibly can. Always a trade off though, so use your discretion.
>
> Jonathan
I'm going to keep it all typed for now since I don't want to make too
many changes at once. Since this is somewhat unrelated to the purpose of
introducing Counter character devices, I'll postpone the discussion to a
later date after the Counter character device interface is merged.
William Breathitt Gray
>
>
> >
> > William Breathitt Gray (4):
> > counter: Internalize sysfs interface code
> > docs: counter: Update to reflect sysfs internalization
> > counter: Add character device interface
> > docs: counter: Document character device interface
> >
> > Documentation/driver-api/generic-counter.rst | 275 +++-
> > MAINTAINERS | 3 +-
> > drivers/counter/104-quad-8.c | 547 +++----
> > drivers/counter/Makefile | 1 +
> > drivers/counter/counter-chrdev.c | 656 ++++++++
> > drivers/counter/counter-chrdev.h | 16 +
> > drivers/counter/counter-core.c | 187 +++
> > drivers/counter/counter-sysfs.c | 881 +++++++++++
> > drivers/counter/counter-sysfs.h | 14 +
> > drivers/counter/counter.c | 1496 ------------------
> > drivers/counter/ftm-quaddec.c | 89 +-
> > drivers/counter/stm32-lptimer-cnt.c | 161 +-
> > drivers/counter/stm32-timer-cnt.c | 139 +-
> > drivers/counter/ti-eqep.c | 211 +--
> > include/linux/counter.h | 626 ++++----
> > include/linux/counter_enum.h | 45 -
> > include/uapi/linux/counter-types.h | 45 +
> > 17 files changed, 2826 insertions(+), 2566 deletions(-)
> > create mode 100644 drivers/counter/counter-chrdev.c
> > create mode 100644 drivers/counter/counter-chrdev.h
> > create mode 100644 drivers/counter/counter-core.c
> > create mode 100644 drivers/counter/counter-sysfs.c
> > create mode 100644 drivers/counter/counter-sysfs.h
> > delete mode 100644 drivers/counter/counter.c
> > delete mode 100644 include/linux/counter_enum.h
> > create mode 100644 include/uapi/linux/counter-types.h
> >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 4/4] docs: counter: Document character device interface
2020-05-16 19:20 ` [PATCH v2 4/4] docs: counter: Document " William Breathitt Gray
2020-05-24 16:19 ` Jonathan Cameron
@ 2020-05-29 13:26 ` Pavel Machek
2020-05-31 13:31 ` William Breathitt Gray
1 sibling, 1 reply; 16+ messages in thread
From: Pavel Machek @ 2020-05-29 13:26 UTC (permalink / raw)
To: William Breathitt Gray
Cc: jic23, kamel.bouhara, gwendal, alexandre.belloni, david,
linux-iio, linux-kernel, linux-stm32, linux-arm-kernel,
syednwaris, patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
On Sat 2020-05-16 15:20:02, William Breathitt Gray wrote:
> This patch adds high-level documentation about the Counter subsystem
> character device interface.
>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
> Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
> 1 file changed, 76 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
> index 8f85c30dea0b..58045b33b576 100644
> --- a/Documentation/driver-api/generic-counter.rst
> +++ b/Documentation/driver-api/generic-counter.rst
> +
> +Counter chrdev
> +--------------
> +Translates counter data to the standard Counter character device; data
> +is transferred via standard character device read/write calls.
> +
> +Sysfs Interface
> +===============
> +
> +Several sysfs attributes are generated by the Generic Counter interface,
> +and reside under the `/sys/bus/counter/devices/counterX` directory,
> +where `X` is to the respective counter device id. Please see
> +Documentation/ABI/testing/sysfs-bus-counter for detailed information on
> +each Generic Counter interface sysfs attribute.
> +
> +Through these sysfs attributes, programs and scripts may interact with
> +the Generic Counter paradigm Counts, Signals, and Synapses of respective
> +counter devices.
> +
> +Counter Character Device
> +========================
> +
> +Counter character device nodes are created under the `/dev` directory as
> +`counterX`, where `X` is the respective counter device id. Defines for
> +the standard Counter data types are exposed via the userspace
> +`include/uapi/linux/counter-types.h` file.
> +
> +The first 196095 bytes of the character device serve as a control
> +selection area where control exposure of desired Counter components and
> +extensions may be selected. Each byte serves as a boolean selection
> +indicator for a respective Counter component or extension. The format of
> +this area is as follows:
> +
> +* For each device extension, a byte is required.
> +* For each Signal, a byte is reserved for the Signal component, and a
> + byte is reserved for each Signal extension.
> +* For each Count, a byte is reserved for the Count component, a byte is
> + reserved for the count function, a byte is reserved for each Synapse
> + action, and byte is reserved for each Count extension.
> +
> +The selected Counter components and extensions may then be interfaced
> +after the first 196095 bytes via standard character device read/write
> +operations. The number of bytes available for each component or
> +extension is dependent on their respective data type: u8 will have 1
> +byte available, u64 will have 8 bytes available, strings will have 64
> +bytes available, etc.
This looks like very, very strange interface, and not described in detail
required to understand it.
Could you take a look at input subsystem, /dev/input/event0? Perhaps it is
directly usable, and if not something similar should probably be acceptable.
Best regards,
Pavel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 4/4] docs: counter: Document character device interface
2020-05-29 13:26 ` Pavel Machek
@ 2020-05-31 13:31 ` William Breathitt Gray
0 siblings, 0 replies; 16+ messages in thread
From: William Breathitt Gray @ 2020-05-31 13:31 UTC (permalink / raw)
To: Pavel Machek
Cc: jic23, kamel.bouhara, gwendal, alexandre.belloni, david,
linux-iio, linux-kernel, linux-stm32, linux-arm-kernel,
syednwaris, patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
[-- Attachment #1: Type: text/plain, Size: 3654 bytes --]
On Fri, May 29, 2020 at 03:26:04PM +0200, Pavel Machek wrote:
> On Sat 2020-05-16 15:20:02, William Breathitt Gray wrote:
> > This patch adds high-level documentation about the Counter subsystem
> > character device interface.
> >
> > Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> > ---
> > Documentation/driver-api/generic-counter.rst | 112 +++++++++++++------
> > 1 file changed, 76 insertions(+), 36 deletions(-)
> >
> > diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
> > index 8f85c30dea0b..58045b33b576 100644
> > --- a/Documentation/driver-api/generic-counter.rst
> > +++ b/Documentation/driver-api/generic-counter.rst
>
> > +
> > +Counter chrdev
> > +--------------
> > +Translates counter data to the standard Counter character device; data
> > +is transferred via standard character device read/write calls.
> > +
> > +Sysfs Interface
> > +===============
> > +
> > +Several sysfs attributes are generated by the Generic Counter interface,
> > +and reside under the `/sys/bus/counter/devices/counterX` directory,
> > +where `X` is to the respective counter device id. Please see
> > +Documentation/ABI/testing/sysfs-bus-counter for detailed information on
> > +each Generic Counter interface sysfs attribute.
> > +
> > +Through these sysfs attributes, programs and scripts may interact with
> > +the Generic Counter paradigm Counts, Signals, and Synapses of respective
> > +counter devices.
> > +
> > +Counter Character Device
> > +========================
> > +
> > +Counter character device nodes are created under the `/dev` directory as
> > +`counterX`, where `X` is the respective counter device id. Defines for
> > +the standard Counter data types are exposed via the userspace
> > +`include/uapi/linux/counter-types.h` file.
> > +
> > +The first 196095 bytes of the character device serve as a control
> > +selection area where control exposure of desired Counter components and
> > +extensions may be selected. Each byte serves as a boolean selection
> > +indicator for a respective Counter component or extension. The format of
> > +this area is as follows:
> > +
> > +* For each device extension, a byte is required.
> > +* For each Signal, a byte is reserved for the Signal component, and a
> > + byte is reserved for each Signal extension.
> > +* For each Count, a byte is reserved for the Count component, a byte is
> > + reserved for the count function, a byte is reserved for each Synapse
> > + action, and byte is reserved for each Count extension.
> > +
> > +The selected Counter components and extensions may then be interfaced
> > +after the first 196095 bytes via standard character device read/write
> > +operations. The number of bytes available for each component or
> > +extension is dependent on their respective data type: u8 will have 1
> > +byte available, u64 will have 8 bytes available, strings will have 64
> > +bytes available, etc.
>
> This looks like very, very strange interface, and not described in detail
> required to understand it.
>
> Could you take a look at input subsystem, /dev/input/event0? Perhaps it is
> directly usable, and if not something similar should probably be acceptable.
>
> Best regards,
> Pavel
Yes, I don't think this is a good interface afterall. I'm implementing a
different design for v3 that should be more intuitive. The input
subsystem could be useful for streams of events such as timestamps, so
I'll take a look at it as well in case something similar to it could be
used.
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
2020-05-24 17:54 ` William Breathitt Gray
@ 2020-05-31 15:18 ` Jonathan Cameron
2020-05-31 17:14 ` William Breathitt Gray
0 siblings, 1 reply; 16+ messages in thread
From: Jonathan Cameron @ 2020-05-31 15:18 UTC (permalink / raw)
To: William Breathitt Gray
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
On Sun, 24 May 2020 13:54:39 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> On Sun, May 24, 2020 at 05:25:42PM +0100, Jonathan Cameron wrote:
> >
> > ...
> >
> > > The following are some questions I have about this patchset:
> > >
> > > 1. Should the data format of the character device be configured via a
> > > sysfs attribute?
> > >
> > > In this patchset, the first 196095 bytes of the character device are
> > > dedicated as a selection area to choose which Counter components or
> > > extensions should be exposed; the subsequent bytes are the actual
> > > data for the Counter components and extensions that were selected.
> >
> > That sounds like the worst of all possible worlds. Reality is you need
> > to do some magic library so at that point you might as well have ioctl
> > options to configure it. I wonder if you can keep the data flow
> > to be a simple 'read' from the chardev but move the control away from
> > that. Either control via some chrdevs but keep them to the 'set / get'
> > if this element is going to turn up in the read or not. You rapidly
> > run into problems though, such as now to see how large a given element
> > is going to be etc. Plus ioctls are rather messier to extend than
> > simply adding a new sysfs file. Various subsystems do complex
> > 'descriptor' type approaches to get around this, or you could do
> > self describing records rather than raw data - like an input
> > ev_dev event.
>
> Yes I agree, I don't think combining nondata with data is good design --
> it's better if users are able to simply perform read/write on the
> character device without having to keep track of valid offsets and
> controls.
>
> After giving this some more thought, I believe human-readable sysfs
> attributes are the way to go to support configuration of the character
> device. I am thinking of a system like this:
>
> * Users configure the counter character device via a sysfs attribute
> such as /sys/bus/counter/devices/counterX/chrdev_format or similar.
>
> * Users may write to this sysfs attribute to select the components they
> want to interface -- the layout can be determined as well from the
> order. For example:
>
> # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format
I guess that 'just' meets the sysfs requirement of one file => one thing.
>
> This would select Counts 0, 3, and 2 (in that order) to be available
> in the /dev/counter0 node as a contiguous memory region.
>
> You can select extensions in a similar fashion:
>
> # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format
>
> This would select extension 2 from Count 4, and extension 0 from
> Signal 1.
I'm not totally clear why we'd want to have a chrdev access to extensions.
To be honest I'm not totally sure what an extension is today as it's been
a week ;)
Perhaps an example? I see timestamp below. What is that attached to?
If we gave multiple counters, do they each have a timestamp?
>
> * Users may read from this chrdev_format sysfs attribute in order to see
> the currently configured format of the character device.
>
> * Users may perform read/write operations on the /dev/counterX node
> directly; the layout of the data is what they user has configured via
> the chrdev_format sysfs attribute. For example:
>
> # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format
>
> Yields the following /dev/counter0 memory layout:
>
> +-----------------+------------------+----------+----------+
> | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16 | Byte 17 |
> +-----------------+------------------+----------+----------+
> | Count 0 | Count 1 | Signal 0 | Signal 2 |
> +-----------------+------------------+----------+----------+
>
> * Users may perform select/poll operations on the /dev/counterX node.
> Users can be notified if data is available or events have occurred.
One thing to think about early if watermarks. We bolted them on
late in IIO and maybe we could have done it better from the start.
I'd almost guarantee someone will want one fairly soon - particularly
as it's more than possible you'll have a counter device with a
hardware fifo. I have some vague recollection that ti-ecap
stuff could be presented as a short fifo for starters.
>
> The benefit of this design is that the format is robust so users can
> choose the components they want to interface and in the layout they
> want. For example, if I am writing a userspace application to control a
> dual-axis positioning table, I can select the two counts I care about
> for the position axes. This allows me to read just those two values
> directly from /dev/counterX with a simple read() call, without having to
> fumble around seeking to an offset and parsing the layout.
I wonder if I'm over thinking things for counters, but you may run into
the complexity of different counters having different sampling frequencies.
Here you are suggesting a scheme that I think ends up closer to IIO than
input. That makes this case a pain. Input takes the view that it's
fine to have data coming in any order and frequency because every
record is self describing. I'm not sure it matters here, but it is
a nice layer of flexibility, but you do loose the efficiency of
the description being external to the data flow.
>
> Similarly, support for future extensions is simple to implement. When
> timestamp support is implemented, users can just select the desired
> timestamp extension and read it directly from the /dev/counterX node;
> they should also be able to perform a select()/poll() call to be
> notified on new timestamps.
>
> So what do you think of this sort of design? I think there is a useful
> robustness to the simplicity of performing a single read/write call on
> /dev/counterX.
It seems like a reasonable solution to me. The only blurry
boundary to my mind is what level of buffering is behind this.
The things you can do are open, non blocking read, blocking read and select.
If we have a counter that is sampled on demand, then
1) Non blocking read - makes not sense, fair enough I guess, could make it
the same as a blocking read.
2) Blocking read - reads from the sensor.
3) Select, meaningless as all reads are done on demand - so I guess you
hardwire it to return immediately.
4) open. Nothing special
If you have a counter that is self clocking then data gets pushed into some
software structure (probably kfifo)
1) Blocking read, question of semantics to resolve
a) Return when 'some' data is available (like a socket)
b) Return when 'requested amount of data is available'?
2) Non blocking read. Return whatever happens to be available.
3) Select. Semantics to be defined.
a) Some data?
b) Watermark based (default watermark is 0 so any data triggers it)
4) Open. Starts up sampling of configured set - (typically turns on the
device, enables interrupt output etc.)
So some corners to resolve but should all work.
>
> > >
> > > Moving this selection to a sysfs attribute and dedicating the
> > > character device to just data transfer might be a better design. If
> > > such a design is chosen, should the selection attribute be
> > > human-readable or binary?
> >
> > Sysfs basically requires things are more or less human readable.
> > So if you go that way I think it needs to be.
> >
> > >
> > > 2. How much space should allotted for strings?
> > >
> > > Each Counter component and extension has a respective size allotted
> > > for its data (u8 data is allotted 1 byte, u64 data is allotted 8
> > > bytes, etc.); I have arbitrarily chosen to allot 64 bytes for
> > > strings. Is this an apt size, or should string data be allotted more
> > > or less space?
> >
> > I'd go with that being big enough, but try to keep the expose interface
> > such that the size can change it it needs to the in the future.
>
> Following along with the separation of control vs data as discussed
> above, we could support a more variable size by exposing it through a
> sysfs attribute (maybe a chrdev_string_size attribute or similar).
I'm unconvinced you'd ever want to return a string via the chardev.
People are using the chrdev to get efficiency. String based data flows
are rarely that!
>
> >
> > >
> > > 3. Should the owning component of an extension be handled by the device
> > > driver or Counter subsystem?
> > >
> > > The Counter subsystem figures out the owner (enum counter_owner_type)
> > > for each component/extension in the counter-sysfs and counter-chrdev
> > > code. When a callback must be executed, there are various switch
> > > statements throughout the code to check whether the respective
> > > Device, Signal, or Count version of the callback should be executed;
> > > similarly, the appropriate owner type must match for the struct
> > > counter_data macros such as COUNTER_DATA_DEVICE_U64,
> > > COUNTER_DATA_SIGNAL_U64, COUNTER_DATA_COUNT_U64, etc.
> > >
> > > All this complexity in the Counter subsystem code can be eliminated
> > > if a single callback type with a `void *owner` parameter is defined
> > > for use with all three owner types (Device, Signal, and Count). The
> > > device driver would then be responsible for casting the callback
> > > argument to the appropriate owner type; but in theory, this should
> > > not be much of a problem since the device driver is responsible for
> > > assigning the callbacks to the owning component anyway.
> >
> > Whilst its more complex for subsytem I think it's better to keep everything
> > typed if we possibly can. Always a trade off though, so use your discretion.
> >
> > Jonathan
>
> I'm going to keep it all typed for now since I don't want to make too
> many changes at once. Since this is somewhat unrelated to the purpose of
> introducing Counter character devices, I'll postpone the discussion to a
> later date after the Counter character device interface is merged.
Makes sense.
Jonathan
>
> William Breathitt Gray
>
> >
> >
> > >
> > > William Breathitt Gray (4):
> > > counter: Internalize sysfs interface code
> > > docs: counter: Update to reflect sysfs internalization
> > > counter: Add character device interface
> > > docs: counter: Document character device interface
> > >
> > > Documentation/driver-api/generic-counter.rst | 275 +++-
> > > MAINTAINERS | 3 +-
> > > drivers/counter/104-quad-8.c | 547 +++----
> > > drivers/counter/Makefile | 1 +
> > > drivers/counter/counter-chrdev.c | 656 ++++++++
> > > drivers/counter/counter-chrdev.h | 16 +
> > > drivers/counter/counter-core.c | 187 +++
> > > drivers/counter/counter-sysfs.c | 881 +++++++++++
> > > drivers/counter/counter-sysfs.h | 14 +
> > > drivers/counter/counter.c | 1496 ------------------
> > > drivers/counter/ftm-quaddec.c | 89 +-
> > > drivers/counter/stm32-lptimer-cnt.c | 161 +-
> > > drivers/counter/stm32-timer-cnt.c | 139 +-
> > > drivers/counter/ti-eqep.c | 211 +--
> > > include/linux/counter.h | 626 ++++----
> > > include/linux/counter_enum.h | 45 -
> > > include/uapi/linux/counter-types.h | 45 +
> > > 17 files changed, 2826 insertions(+), 2566 deletions(-)
> > > create mode 100644 drivers/counter/counter-chrdev.c
> > > create mode 100644 drivers/counter/counter-chrdev.h
> > > create mode 100644 drivers/counter/counter-core.c
> > > create mode 100644 drivers/counter/counter-sysfs.c
> > > create mode 100644 drivers/counter/counter-sysfs.h
> > > delete mode 100644 drivers/counter/counter.c
> > > delete mode 100644 include/linux/counter_enum.h
> > > create mode 100644 include/uapi/linux/counter-types.h
> > >
> >
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
2020-05-31 15:18 ` Jonathan Cameron
@ 2020-05-31 17:14 ` William Breathitt Gray
2020-06-01 10:31 ` Jonathan Cameron
2020-06-02 15:18 ` David Lechner
0 siblings, 2 replies; 16+ messages in thread
From: William Breathitt Gray @ 2020-05-31 17:14 UTC (permalink / raw)
To: Jonathan Cameron
Cc: kamel.bouhara, gwendal, alexandre.belloni, david, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
[-- Attachment #1: Type: text/plain, Size: 13367 bytes --]
On Sun, May 31, 2020 at 04:18:13PM +0100, Jonathan Cameron wrote:
> On Sun, 24 May 2020 13:54:39 -0400
> William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> > After giving this some more thought, I believe human-readable sysfs
> > attributes are the way to go to support configuration of the character
> > device. I am thinking of a system like this:
> >
> > * Users configure the counter character device via a sysfs attribute
> > such as /sys/bus/counter/devices/counterX/chrdev_format or similar.
> >
> > * Users may write to this sysfs attribute to select the components they
> > want to interface -- the layout can be determined as well from the
> > order. For example:
> >
> > # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format
>
> I guess that 'just' meets the sysfs requirement of one file => one thing.
We can massage this further to make it more apt, but the main idea here
is that configuration should be separate from our data; and that
configuration should be performed via sysfs.
> > This would select Counts 0, 3, and 2 (in that order) to be available
> > in the /dev/counter0 node as a contiguous memory region.
> >
> > You can select extensions in a similar fashion:
> >
> > # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format
> >
> > This would select extension 2 from Count 4, and extension 0 from
> > Signal 1.
>
> I'm not totally clear why we'd want to have a chrdev access to extensions.
> To be honest I'm not totally sure what an extension is today as it's been
> a week ;)
In the context of the Counter subsystem, an extension is data/control
that is not one of the core components of the Counter paradigm (i.e. not
a Counter, Signal, nor Synapse). Extensions essentially represent
configuration options for the counter device and auxiliary
functionality.
The "Implementation" section of the Generic Counter documentation
Documentation/driver-api/generic-counter.rst file gives some good
examples of extensions, but I'll provide an example here for the sake of
this new character device interface.
Suppose we have a robot controlling a laser on a dual-axes positioning
table. A counter device is used to track the position of the laser:
Count 0 represents position on the X axis, while Count 1 represents
position on the Y axis. Because this machine is moving across two axes
at the same time, we want to grab both counts together via the
character device subsystem (grabbing them separately via sysfs would be
imprecise due to the inherent latency).
The motors are physically able the robot out of the work area, which is
not something we want to happen. A common setup in systems like this is
to set soft boundaries on the counter device to represent the edge of
the work area; when the boundary is passed, a flag is set high on the
device to indicate the position is out-of-bounds.
On the Counter subsystem side, this counter device would appear as
having four sysfs attributes: count0/count, count0/boundary,
count1/count, and count1/boundary. In terms of the character device
interface, we could perform a setup like this:
# echo "C0E0 C0 C1E1 C1" > counter0/chrdev_format
Yielding the following /dev/counter0 memory layout:
+------------+-----------------+------------+-------------------+
| Byte 0 | Byte 1 - Byte 8 | Byte 9 | Byte 10 - Byte 17 |
+------------+-----------------+------------+-------------------+
| Boundary 0 | Count 0 | Boundary 1 | Count 1 |
+------------+-----------------+------------+-------------------+
Now a single read() operation can grab the counts together as well as
their respective boundary flags to verify whether the current counts are
valid. This is a scenario where using sysfs wouldn't be viable to use:
we could check the count0/boundary sysfs attribute first, but by the
time we read the count0/count sysfs attribute second, the robot has
already moved to a new (possibly invalid) position.
> Perhaps an example? I see timestamp below. What is that attached to?
> If we gave multiple counters, do they each have a timestamp?
Some counter devices feature "timestamp" functionality. I haven't yet
implemented this in the Counter subsystem because it's new functionality
and I want to keep this patchset limited to the existing Counter
subsystem functionality support.
However, to briefly go into the topic (we'll need to discuss this more
in-depth before committing to a Counter subsystem design), some counter
devices can keep track of historic counts based on various events; we
call these "timestamps", although they may not necessary be tied to a
wall-clock time.
For example, quadrature encoders often have an "index" signal in
addition to the quadrature A and B lines. This index signal may be used
to home a positioning device, or perhaps to indicate that a full
revolution -- or some other event -- has occurred. It's common for
quadrature counter devices to provide a FIFO buffer that logs these
"index" events by saving the current count when that respective index
signal goes high. Thus we have a timestamp buffer.
In the context of the Counter subsystem, I believe we will end up
implementing these timestamps as Count extensions (or Device extensions
if it's a single buffer for the entire device). I'm not sure yet what
the sysfs attribute will display, but I'm guessing we'll have a
respective /sys/bus/counter/devices/counterX/countX/timestamps sysfs
attribute or similar.
The character device implementation should be more straight forward I
would imagine. Since it's a memory buffer, I think we can provide access
to that buffer directly in the chrdev:
# echo "C0E0 C1E1" > /sys/bus/counter/devices/counter0/chrdev_format
Yielding the following /dev/counter0 memory layout for 32-byte
timestamps:
+---------------------+---------------------+
| Byte 0 - Byte 31 | Byte 32 - Byte 63 |
+---------------------+---------------------+
| Timestamps Buffer 0 | Timestamps Buffer 1 |
+---------------------+---------------------+
> > * Users may read from this chrdev_format sysfs attribute in order to see
> > the currently configured format of the character device.
> >
> > * Users may perform read/write operations on the /dev/counterX node
> > directly; the layout of the data is what they user has configured via
> > the chrdev_format sysfs attribute. For example:
> >
> > # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format
> >
> > Yields the following /dev/counter0 memory layout:
> >
> > +-----------------+------------------+----------+----------+
> > | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16 | Byte 17 |
> > +-----------------+------------------+----------+----------+
> > | Count 0 | Count 1 | Signal 0 | Signal 2 |
> > +-----------------+------------------+----------+----------+
> >
> > * Users may perform select/poll operations on the /dev/counterX node.
> > Users can be notified if data is available or events have occurred.
>
> One thing to think about early if watermarks. We bolted them on
> late in IIO and maybe we could have done it better from the start.
> I'd almost guarantee someone will want one fairly soon - particularly
> as it's more than possible you'll have a counter device with a
> hardware fifo. I have some vague recollection that ti-ecap
> stuff could be presented as a short fifo for starters.
>
> >
> > The benefit of this design is that the format is robust so users can
> > choose the components they want to interface and in the layout they
> > want. For example, if I am writing a userspace application to control a
> > dual-axis positioning table, I can select the two counts I care about
> > for the position axes. This allows me to read just those two values
> > directly from /dev/counterX with a simple read() call, without having to
> > fumble around seeking to an offset and parsing the layout.
>
> I wonder if I'm over thinking things for counters, but you may run into
> the complexity of different counters having different sampling frequencies.
> Here you are suggesting a scheme that I think ends up closer to IIO than
> input. That makes this case a pain. Input takes the view that it's
> fine to have data coming in any order and frequency because every
> record is self describing. I'm not sure it matters here, but it is
> a nice layer of flexibility, but you do loose the efficiency of
> the description being external to the data flow.
I think one of the downsides to using a single a single character device
node to represent the entire counter device is that the frequency of two
individual counts may differ from each other. For example, using the
dual-axes positioning scenario from earlier, one axis might change more
frequently than the other (e.g. a conveyor belt situation where X is
always moving forward, while Y only changes when a part appears within
the work area).
In these cases, I think the Input subsystem approach might be better
because the user can just wait for events at large and handle each event
as it comes in, rather than try to coordinate between them all in a
shared memory space. The shortcoming with this approach is that we lose
the ability to grab Counts together at the same time, such as we require
in the constantly moving robot example earlier.
Perhaps what might work is to implement Counter events (perhaps even
timestamps) using the Input subsystem, and leave the Counter character
device interface to simple read/write operations. But we'll need to
investigate this further because we lack a concept of "events" right now
in the Counter subsystem.
> > Similarly, support for future extensions is simple to implement. When
> > timestamp support is implemented, users can just select the desired
> > timestamp extension and read it directly from the /dev/counterX node;
> > they should also be able to perform a select()/poll() call to be
> > notified on new timestamps.
> >
> > So what do you think of this sort of design? I think there is a useful
> > robustness to the simplicity of performing a single read/write call on
> > /dev/counterX.
>
> It seems like a reasonable solution to me. The only blurry
> boundary to my mind is what level of buffering is behind this.
> The things you can do are open, non blocking read, blocking read and select.
>
> If we have a counter that is sampled on demand, then
> 1) Non blocking read - makes not sense, fair enough I guess, could make it
> the same as a blocking read.
> 2) Blocking read - reads from the sensor.
> 3) Select, meaningless as all reads are done on demand - so I guess you
> hardwire it to return immediately.
> 4) open. Nothing special
>
> If you have a counter that is self clocking then data gets pushed into some
> software structure (probably kfifo)
> 1) Blocking read, question of semantics to resolve
> a) Return when 'some' data is available (like a socket)
> b) Return when 'requested amount of data is available'?
> 2) Non blocking read. Return whatever happens to be available.
> 3) Select. Semantics to be defined.
> a) Some data?
> b) Watermark based (default watermark is 0 so any data triggers it)
> 4) Open. Starts up sampling of configured set - (typically turns on the
> device, enables interrupt output etc.)
>
> So some corners to resolve but should all work.
I'm not familiar with the "watermark" terminology. Would you be able to
explain it bit more for me. Is this simply a flag that indicates if data
has changed from the last time it was checked?
> > > > Moving this selection to a sysfs attribute and dedicating the
> > > > character device to just data transfer might be a better design. If
> > > > such a design is chosen, should the selection attribute be
> > > > human-readable or binary?
> > >
> > > Sysfs basically requires things are more or less human readable.
> > > So if you go that way I think it needs to be.
> > >
> > > >
> > > > 2. How much space should allotted for strings?
> > > >
> > > > Each Counter component and extension has a respective size allotted
> > > > for its data (u8 data is allotted 1 byte, u64 data is allotted 8
> > > > bytes, etc.); I have arbitrarily chosen to allot 64 bytes for
> > > > strings. Is this an apt size, or should string data be allotted more
> > > > or less space?
> > >
> > > I'd go with that being big enough, but try to keep the expose interface
> > > such that the size can change it it needs to the in the future.
> >
> > Following along with the separation of control vs data as discussed
> > above, we could support a more variable size by exposing it through a
> > sysfs attribute (maybe a chrdev_string_size attribute or similar).
>
> I'm unconvinced you'd ever want to return a string via the chardev.
> People are using the chrdev to get efficiency. String based data flows
> are rarely that!
That's a good point. I don't think there is a situation right now where
we need to deliver strings via the character device interface, so I
think I'll remove that in v3.
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
2020-05-31 17:14 ` William Breathitt Gray
@ 2020-06-01 10:31 ` Jonathan Cameron
2020-06-02 15:18 ` David Lechner
1 sibling, 0 replies; 16+ messages in thread
From: Jonathan Cameron @ 2020-06-01 10:31 UTC (permalink / raw)
To: William Breathitt Gray
Cc: Jonathan Cameron, kamel.bouhara, gwendal, alexandre.belloni,
david, linux-iio, linux-kernel, linux-stm32, linux-arm-kernel,
syednwaris, patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
On Sun, 31 May 2020 13:14:06 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> On Sun, May 31, 2020 at 04:18:13PM +0100, Jonathan Cameron wrote:
> > On Sun, 24 May 2020 13:54:39 -0400
> > William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> > > After giving this some more thought, I believe human-readable sysfs
> > > attributes are the way to go to support configuration of the character
> > > device. I am thinking of a system like this:
> > >
> > > * Users configure the counter character device via a sysfs attribute
> > > such as /sys/bus/counter/devices/counterX/chrdev_format or similar.
> > >
> > > * Users may write to this sysfs attribute to select the components they
> > > want to interface -- the layout can be determined as well from the
> > > order. For example:
> > >
> > > # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format
> >
> > I guess that 'just' meets the sysfs requirement of one file => one thing.
>
> We can massage this further to make it more apt, but the main idea here
> is that configuration should be separate from our data; and that
> configuration should be performed via sysfs.
>
> > > This would select Counts 0, 3, and 2 (in that order) to be available
> > > in the /dev/counter0 node as a contiguous memory region.
> > >
> > > You can select extensions in a similar fashion:
> > >
> > > # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format
> > >
> > > This would select extension 2 from Count 4, and extension 0 from
> > > Signal 1.
> >
> > I'm not totally clear why we'd want to have a chrdev access to extensions.
> > To be honest I'm not totally sure what an extension is today as it's been
> > a week ;)
>
> In the context of the Counter subsystem, an extension is data/control
> that is not one of the core components of the Counter paradigm (i.e. not
> a Counter, Signal, nor Synapse). Extensions essentially represent
> configuration options for the counter device and auxiliary
> functionality.
>
> The "Implementation" section of the Generic Counter documentation
> Documentation/driver-api/generic-counter.rst file gives some good
> examples of extensions, but I'll provide an example here for the sake of
> this new character device interface.
>
> Suppose we have a robot controlling a laser on a dual-axes positioning
> table. A counter device is used to track the position of the laser:
> Count 0 represents position on the X axis, while Count 1 represents
> position on the Y axis. Because this machine is moving across two axes
> at the same time, we want to grab both counts together via the
> character device subsystem (grabbing them separately via sysfs would be
> imprecise due to the inherent latency).
>
> The motors are physically able the robot out of the work area, which is
> not something we want to happen. A common setup in systems like this is
> to set soft boundaries on the counter device to represent the edge of
> the work area; when the boundary is passed, a flag is set high on the
> device to indicate the position is out-of-bounds.
>
> On the Counter subsystem side, this counter device would appear as
> having four sysfs attributes: count0/count, count0/boundary,
> count1/count, and count1/boundary. In terms of the character device
> interface, we could perform a setup like this:
>
> # echo "C0E0 C0 C1E1 C1" > counter0/chrdev_format
>
> Yielding the following /dev/counter0 memory layout:
>
> +------------+-----------------+------------+-------------------+
> | Byte 0 | Byte 1 - Byte 8 | Byte 9 | Byte 10 - Byte 17 |
> +------------+-----------------+------------+-------------------+
> | Boundary 0 | Count 0 | Boundary 1 | Count 1 |
> +------------+-----------------+------------+-------------------+
>
> Now a single read() operation can grab the counts together as well as
> their respective boundary flags to verify whether the current counts are
> valid. This is a scenario where using sysfs wouldn't be viable to use:
> we could check the count0/boundary sysfs attribute first, but by the
> time we read the count0/count sysfs attribute second, the robot has
> already moved to a new (possibly invalid) position.
Ok. So typically something like a condition flag. Data that indeed makes
sense to be associated with a set of counter values.
>
> > Perhaps an example? I see timestamp below. What is that attached to?
> > If we gave multiple counters, do they each have a timestamp?
>
> Some counter devices feature "timestamp" functionality. I haven't yet
> implemented this in the Counter subsystem because it's new functionality
> and I want to keep this patchset limited to the existing Counter
> subsystem functionality support.
>
> However, to briefly go into the topic (we'll need to discuss this more
> in-depth before committing to a Counter subsystem design), some counter
> devices can keep track of historic counts based on various events; we
> call these "timestamps", although they may not necessary be tied to a
> wall-clock time.
>
> For example, quadrature encoders often have an "index" signal in
> addition to the quadrature A and B lines. This index signal may be used
> to home a positioning device, or perhaps to indicate that a full
> revolution -- or some other event -- has occurred. It's common for
> quadrature counter devices to provide a FIFO buffer that logs these
> "index" events by saving the current count when that respective index
> signal goes high. Thus we have a timestamp buffer.
That doesn't sound like a timestamp buffer. You are logging counts,
not the current time. If they are going through a FIFO you might also
capture a freerunning timer though.
>
> In the context of the Counter subsystem, I believe we will end up
> implementing these timestamps as Count extensions (or Device extensions
> if it's a single buffer for the entire device). I'm not sure yet what
> the sysfs attribute will display, but I'm guessing we'll have a
> respective /sys/bus/counter/devices/counterX/countX/timestamps sysfs
> attribute or similar.
>
> The character device implementation should be more straight forward I
> would imagine. Since it's a memory buffer, I think we can provide access
> to that buffer directly in the chrdev:
>
> # echo "C0E0 C1E1" > /sys/bus/counter/devices/counter0/chrdev_format
>
> Yielding the following /dev/counter0 memory layout for 32-byte
> timestamps:
>
> +---------------------+---------------------+
> | Byte 0 - Byte 31 | Byte 32 - Byte 63 |
> +---------------------+---------------------+
> | Timestamps Buffer 0 | Timestamps Buffer 1 |
> +---------------------+---------------------+
As you say, will need more discussion. Lots of fun questions around timestamps
such as what the timebase is, how to relate it to system time etc.
>
> > > * Users may read from this chrdev_format sysfs attribute in order to see
> > > the currently configured format of the character device.
> > >
> > > * Users may perform read/write operations on the /dev/counterX node
> > > directly; the layout of the data is what they user has configured via
> > > the chrdev_format sysfs attribute. For example:
> > >
> > > # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format
> > >
> > > Yields the following /dev/counter0 memory layout:
> > >
> > > +-----------------+------------------+----------+----------+
> > > | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16 | Byte 17 |
> > > +-----------------+------------------+----------+----------+
> > > | Count 0 | Count 1 | Signal 0 | Signal 2 |
> > > +-----------------+------------------+----------+----------+
> > >
> > > * Users may perform select/poll operations on the /dev/counterX node.
> > > Users can be notified if data is available or events have occurred.
> >
> > One thing to think about early if watermarks. We bolted them on
> > late in IIO and maybe we could have done it better from the start.
> > I'd almost guarantee someone will want one fairly soon - particularly
> > as it's more than possible you'll have a counter device with a
> > hardware fifo. I have some vague recollection that ti-ecap
> > stuff could be presented as a short fifo for starters.
> >
> > >
> > > The benefit of this design is that the format is robust so users can
> > > choose the components they want to interface and in the layout they
> > > want. For example, if I am writing a userspace application to control a
> > > dual-axis positioning table, I can select the two counts I care about
> > > for the position axes. This allows me to read just those two values
> > > directly from /dev/counterX with a simple read() call, without having to
> > > fumble around seeking to an offset and parsing the layout.
> >
> > I wonder if I'm over thinking things for counters, but you may run into
> > the complexity of different counters having different sampling frequencies.
> > Here you are suggesting a scheme that I think ends up closer to IIO than
> > input. That makes this case a pain. Input takes the view that it's
> > fine to have data coming in any order and frequency because every
> > record is self describing. I'm not sure it matters here, but it is
> > a nice layer of flexibility, but you do loose the efficiency of
> > the description being external to the data flow.
>
> I think one of the downsides to using a single a single character device
> node to represent the entire counter device is that the frequency of two
> individual counts may differ from each other. For example, using the
> dual-axes positioning scenario from earlier, one axis might change more
> frequently than the other (e.g. a conveyor belt situation where X is
> always moving forward, while Y only changes when a part appears within
> the work area).
One option is to allow for either multiple opening of the chardev, or
creation of anon file handles via an IOCTL (like we do for events in IIO).
Makes the sysfs interface more complex, but would allow you to handle multiple
independent raw data streams.
>
> In these cases, I think the Input subsystem approach might be better
> because the user can just wait for events at large and handle each event
> as it comes in, rather than try to coordinate between them all in a
> shared memory space. The shortcoming with this approach is that we lose
> the ability to grab Counts together at the same time, such as we require
> in the constantly moving robot example earlier.
There are approaches like adding a sequence number to allow multiple self
describing records to be associated.
>
> Perhaps what might work is to implement Counter events (perhaps even
> timestamps) using the Input subsystem, and leave the Counter character
> device interface to simple read/write operations. But we'll need to
> investigate this further because we lack a concept of "events" right now
> in the Counter subsystem.
>
> > > Similarly, support for future extensions is simple to implement. When
> > > timestamp support is implemented, users can just select the desired
> > > timestamp extension and read it directly from the /dev/counterX node;
> > > they should also be able to perform a select()/poll() call to be
> > > notified on new timestamps.
> > >
> > > So what do you think of this sort of design? I think there is a useful
> > > robustness to the simplicity of performing a single read/write call on
> > > /dev/counterX.
> >
> > It seems like a reasonable solution to me. The only blurry
> > boundary to my mind is what level of buffering is behind this.
> > The things you can do are open, non blocking read, blocking read and select.
> >
> > If we have a counter that is sampled on demand, then
> > 1) Non blocking read - makes not sense, fair enough I guess, could make it
> > the same as a blocking read.
> > 2) Blocking read - reads from the sensor.
> > 3) Select, meaningless as all reads are done on demand - so I guess you
> > hardwire it to return immediately.
> > 4) open. Nothing special
> >
> > If you have a counter that is self clocking then data gets pushed into some
> > software structure (probably kfifo)
> > 1) Blocking read, question of semantics to resolve
> > a) Return when 'some' data is available (like a socket)
> > b) Return when 'requested amount of data is available'?
> > 2) Non blocking read. Return whatever happens to be available.
> > 3) Select. Semantics to be defined.
> > a) Some data?
> > b) Watermark based (default watermark is 0 so any data triggers it)
> > 4) Open. Starts up sampling of configured set - (typically turns on the
> > device, enables interrupt output etc.)
> >
> > So some corners to resolve but should all work.
>
> I'm not familiar with the "watermark" terminology. Would you be able to
> explain it bit more for me. Is this simply a flag that indicates if data
> has changed from the last time it was checked?
If you have a FIFO, watermark is the fill level at which you indicate you
have data. For a HW FIFO this is usually an interrupt at say 10 elements
queued up. The software is then expected to drain at least 10 elements.
For software fifo the concept is the same, but you are expecting userspace
to drain N elements on each event.
If you are going to deal with remotely high sampling rates you'll need to
support this for both software and hardware FIFOs.
>
> > > > > Moving this selection to a sysfs attribute and dedicating the
> > > > > character device to just data transfer might be a better design. If
> > > > > such a design is chosen, should the selection attribute be
> > > > > human-readable or binary?
> > > >
> > > > Sysfs basically requires things are more or less human readable.
> > > > So if you go that way I think it needs to be.
> > > >
> > > > >
> > > > > 2. How much space should allotted for strings?
> > > > >
> > > > > Each Counter component and extension has a respective size allotted
> > > > > for its data (u8 data is allotted 1 byte, u64 data is allotted 8
> > > > > bytes, etc.); I have arbitrarily chosen to allot 64 bytes for
> > > > > strings. Is this an apt size, or should string data be allotted more
> > > > > or less space?
> > > >
> > > > I'd go with that being big enough, but try to keep the expose interface
> > > > such that the size can change it it needs to the in the future.
> > >
> > > Following along with the separation of control vs data as discussed
> > > above, we could support a more variable size by exposing it through a
> > > sysfs attribute (maybe a chrdev_string_size attribute or similar).
> >
> > I'm unconvinced you'd ever want to return a string via the chardev.
> > People are using the chrdev to get efficiency. String based data flows
> > are rarely that!
>
> That's a good point. I don't think there is a situation right now where
> we need to deliver strings via the character device interface, so I
> think I'll remove that in v3.
Cool. This all seems to be heading in a sensible direction, but as you say
lots still to consider.
Jonathan
>
> William Breathitt Gray
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
2020-05-31 17:14 ` William Breathitt Gray
2020-06-01 10:31 ` Jonathan Cameron
@ 2020-06-02 15:18 ` David Lechner
2020-06-02 15:46 ` William Breathitt Gray
1 sibling, 1 reply; 16+ messages in thread
From: David Lechner @ 2020-06-02 15:18 UTC (permalink / raw)
To: William Breathitt Gray, Jonathan Cameron
Cc: kamel.bouhara, gwendal, alexandre.belloni, linux-iio,
linux-kernel, linux-stm32, linux-arm-kernel, syednwaris,
patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
On 5/31/20 12:14 PM, William Breathitt Gray wrote:
> Yielding the following /dev/counter0 memory layout:
>
> +------------+-----------------+------------+-------------------+
> | Byte 0 | Byte 1 - Byte 8 | Byte 9 | Byte 10 - Byte 17 |
> +------------+-----------------+------------+-------------------+
> | Boundary 0 | Count 0 | Boundary 1 | Count 1 |
> +------------+-----------------+------------+-------------------+
A potential pitfall with this sort of packing is that some platforms
do not support unaligned access, so data would have to be "unpacked"
before it could be used.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 0/4] Introduce the Counter character device interface
2020-06-02 15:18 ` David Lechner
@ 2020-06-02 15:46 ` William Breathitt Gray
0 siblings, 0 replies; 16+ messages in thread
From: William Breathitt Gray @ 2020-06-02 15:46 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, kamel.bouhara, gwendal, alexandre.belloni,
linux-iio, linux-kernel, linux-stm32, linux-arm-kernel,
syednwaris, patrick.havelange, fabrice.gasnier, mcoquelin.stm32,
alexandre.torgue
[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]
On Tue, Jun 02, 2020 at 10:18:07AM -0500, David Lechner wrote:
> On 5/31/20 12:14 PM, William Breathitt Gray wrote:
> > Yielding the following /dev/counter0 memory layout:
> >
> > +------------+-----------------+------------+-------------------+
> > | Byte 0 | Byte 1 - Byte 8 | Byte 9 | Byte 10 - Byte 17 |
> > +------------+-----------------+------------+-------------------+
> > | Boundary 0 | Count 0 | Boundary 1 | Count 1 |
> > +------------+-----------------+------------+-------------------+
>
> A potential pitfall with this sort of packing is that some platforms
> do not support unaligned access, so data would have to be "unpacked"
> before it could be used.
Since the user defines the format of this data, they could reorganize it
to a more streamline alignment; for example:
# echo "C0 C1 C0E0 C1E0" > counter0/chrdev_format
Yielding the following /dev/counter0 memory layout instead:
+-----------------+------------------+------------+------------+
| Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16 | Byte 17 |
+-----------------+------------------+------------+------------+
| Count 0 | Count 1 | Boundary 0 | Boundary 1 |
+-----------------+------------------+------------+------------+
In the future, we could also define a padding argument to give users
more control over the exact offsets:
# echo "C0E0 P7 C0 C1E0 P7 C1" > counter0/chrdev_format
Yielding the following /dev/counter0 memory layout instead:
+------------+-----------------+------------------+------------+
| Byte 0 | Byte 1 - Byte 7 | Byte 8 - Byte 15 | Byte 16 |
+------------+-----------------+------------------+------------+
| Boundary 0 | Padding | Count 0 | Boundary 1 |
+------------+-----------------+------------------+------------+
+-------------------+-------------------+
| Byte 17 - Byte 23 | Byte 24 - Byte 31 |
+-------------------+-------------------+
| Padding | Count 1 |
+-------------------+-------------------+
I not sure it's best to introduce padding support with this patchset
given how much is already changing, but I don't anticipate packing
alignment to be something difficult to support in the future with this
interface.
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-06-02 15:46 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-16 19:19 [PATCH v2 0/4] Introduce the Counter character device interface William Breathitt Gray
2020-05-16 19:20 ` [PATCH v2 2/4] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
2020-05-24 16:12 ` Jonathan Cameron
2020-05-16 19:20 ` [PATCH v2 3/4] counter: Add character device interface William Breathitt Gray
2020-05-20 15:07 ` kbuild test robot
2020-05-16 19:20 ` [PATCH v2 4/4] docs: counter: Document " William Breathitt Gray
2020-05-24 16:19 ` Jonathan Cameron
2020-05-29 13:26 ` Pavel Machek
2020-05-31 13:31 ` William Breathitt Gray
2020-05-24 16:25 ` [PATCH v2 0/4] Introduce the Counter " Jonathan Cameron
2020-05-24 17:54 ` William Breathitt Gray
2020-05-31 15:18 ` Jonathan Cameron
2020-05-31 17:14 ` William Breathitt Gray
2020-06-01 10:31 ` Jonathan Cameron
2020-06-02 15:18 ` David Lechner
2020-06-02 15:46 ` William Breathitt Gray
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).