linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v7 00/10] Introduce the Counter subsystem
@ 2018-06-21 21:06 William Breathitt Gray
  2018-06-21 21:07 ` [PATCH v7 01/10] counter: Introduce the Generic Counter interface William Breathitt Gray
                   ` (11 more replies)
  0 siblings, 12 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:06 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

Changes in v7:
 - Use git-format-patch "-M" switch option to format renames properly
   (apologies to Jonathan for reviewing delete/add pairs in past revs)
 - Remove superfluous license boilerplate in favor of SPDX lines
 - Rename functions to match <noun>_<action> naming convention; e.g.
   signal_read_value_set, count_read_value_set, etc.
 - Rename COUNT_POSITION_UNSIGNED to COUNT_POSITION, and remove
   COUNT_POSITION_SIGNED
 - Inline local variables that are only used once
 - Remove COUNT_FUNCTION_QUADRATURE_X2_RISING and
   COUNT_FUNCTION_QUADRATURE_X2_FALLING; these can be reintroduced when
   a practical use-case is determined
 - Explicitly free allocated attribute pointers on error in
   counter_device_groups_prepare
 - Remove pretty tab alignment for symbol declarations in counter.h
 - Fix kernel-doc syntax typos ("groups_list" and "groups" missing ':')
 - Clarify in kernel-doc comments the use of "val" parameter for the
   signal_read, count_read, and count_write callbacks
 - Cleanup Generic Counter attributes documentation (explain preset
   registers, remove superfluous text, etc.)
 - Cleanup Generic Counter driver API documentation (improve formatting
   by reorganizing options into intended sections, fix typos, etc.)
 - Utilize register defines to remove dependence on magic numbers in
   104-QUAD-8 counter driver
 - Update Kconfig description for the 104-QUAD-8 counter driver to
   describe its Generic Counter interface
 - Remove "mode" wording from STM32 Timer dt-bindings documentation;
   STM32 Timer features a proper quadrature encoder counter device
 - Fix typo in STM32 Timer documentation: IN1/IN2 pins are CH1/CH2 pins

Hi Greg,

This patchset is stabilizing so I hope you can take a look over it and
advise. This patchset introduces the Counter subsystem and the Generic
Counter driver API.

Last year, the STM32 LPTimer IIO driver authored by Fabrice Gasnier
opened up a discussion about the architecture of the IIO Counter
interface. The IIO Counter interface was developed to provide support
for the 104-QUAD-8 IIO driver -- several new IIO attributes were
implemented to support the functionality of the 104-QUAD-8 device. When
the STM32 LPTimer IIO driver was introduced, it too attempted to utilize
the IIO Counter interface to support the counter functionality of the
STM32 LPTimer device.

However, there were some difficulties with the IIO Counter interface.
For example, the 104-QUAD-8 device features a pulse-direction counter
and quadrature encoder counter (which can be toggled via the
quadrature_mode attribute), as well as three quadrature encoder modes
(x1, x2, and x4) which are set via the existing IIO scale attribute.
While this method works for the 104-QUAD-8, the STM32 LPTimer featured a
slightly different Quadrature x2 mode with different state machine
behavior -- as such there is ambiguity over what behavior "quadrature
x2" represents in the IIO Counter interface.

I decided to strip down these devices to arrive at the core essence of
what constitutes a "counter device" and therefore design a "generic
counter" abstraction to better represent these devices and prevent the
ambiguity we discovered with the existing IIO Counter interface. This
abstraction became the Generic Counter paradigm, which is explained in
detail within the Documentation/driver-api/generic-counter.rst file
introduced by this patchset.

Initially we attempted to further extend the IIO Counter interface in
order to integrate the Generic Counter API as part of the IIO subsystem,
but the outcome wasn't as clean as we desired. The results of our
efforts proved to grow increasingly complicated, sparsed with hacks, and
more often than not fought with the IIO subsystem rather than
complemented it. I decided to separate the Generic Counter API from the
IIO subsystem, and give it its own Counter subsystem in which to reside.
This allowed us to streamline development and avoid jeopardizing the
integrity of the IIO subsystem (we no longer have to bend the IIO API to
support our needs, but can instead implement the necessary
functionalities in the Counter subsystem as required).

The Counter subsystem has three consuming drivers thus far: two ported
from the IIO subsystem (104-QUAD-8 and STM32 LPTimer counter) and one
unique to the Counter subsystem (STM32 Timer counter). In userspace, the
Generic Counter interface is rather intuitive:

    * /sys/bus/counter/devices/
      - enumerated directories for counter devices
    * /sys/bus/counter/devices/counterX/
      - attributes for counterX where X is the enumeration ID
    * /sys/bus/counter/devices/counterX/signalY
      - attributes for signal Y where Y is the enumeration ID
    * /sys/bus/counter/devices/counterX/countY
      - attributes for count Y where Y is the enumeration ID

Although at this point the Counter subsystem is functionally separate
from the IIO subsystem, I believe it would be prudent to merge this
introduction patchset via the IIO tree due to the historical context of
these counter drivers and the development of this patchset. Are there
any additions or changes you believe I should make to this patchset
going forward?

Sincerely,

William Breathitt Gray

Benjamin Gaignard (2):
  counter: Add STM32 Timer quadrature encoder
  dt-bindings: counter: Document stm32 quadrature encoder

Fabrice Gasnier (2):
  counter: stm32-lptimer: add counter device
  dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move

William Breathitt Gray (6):
  counter: Introduce the Generic Counter interface
  counter: Documentation: Add Generic Counter sysfs documentation
  docs: Add Generic Counter interface documentation
  counter: 104-quad-8: Add Generic Counter interface support
  counter: 104-quad-8: Documentation: Add Generic Counter sysfs
    documentation
  iio: counter: Add deprecation markings for IIO Counter attributes

 Documentation/ABI/testing/sysfs-bus-counter   |  230 +++
 .../ABI/testing/sysfs-bus-counter-104-quad-8  |   36 +
 Documentation/ABI/testing/sysfs-bus-iio       |    8 +
 .../testing/sysfs-bus-iio-counter-104-quad-8  |   16 +
 .../{iio => }/counter/stm32-lptimer-cnt.txt   |    0
 .../bindings/counter/stm32-timer-cnt.txt      |   31 +
 .../devicetree/bindings/mfd/stm32-lptimer.txt |    2 +-
 .../devicetree/bindings/mfd/stm32-timers.txt  |    7 +
 Documentation/driver-api/generic-counter.rst  |  342 ++++
 Documentation/driver-api/index.rst            |    1 +
 MAINTAINERS                                   |   14 +-
 drivers/Kconfig                               |    2 +
 drivers/Makefile                              |    1 +
 drivers/{iio => }/counter/104-quad-8.c        |  782 ++++++++-
 drivers/counter/Kconfig                       |   59 +
 drivers/{iio => }/counter/Makefile            |    6 +-
 drivers/counter/generic-counter.c             | 1519 +++++++++++++++++
 drivers/{iio => }/counter/stm32-lptimer-cnt.c |  361 +++-
 drivers/counter/stm32-timer-cnt.c             |  390 +++++
 drivers/iio/Kconfig                           |    1 -
 drivers/iio/Makefile                          |    1 -
 drivers/iio/counter/Kconfig                   |   34 -
 include/linux/counter.h                       |  534 ++++++
 23 files changed, 4292 insertions(+), 85 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-counter
 create mode 100644 Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
 rename Documentation/devicetree/bindings/{iio => }/counter/stm32-lptimer-cnt.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
 create mode 100644 Documentation/driver-api/generic-counter.rst
 rename drivers/{iio => }/counter/104-quad-8.c (44%)
 create mode 100644 drivers/counter/Kconfig
 rename drivers/{iio => }/counter/Makefile (52%)
 create mode 100644 drivers/counter/generic-counter.c
 rename drivers/{iio => }/counter/stm32-lptimer-cnt.c (48%)
 create mode 100644 drivers/counter/stm32-timer-cnt.c
 delete mode 100644 drivers/iio/counter/Kconfig
 create mode 100644 include/linux/counter.h

-- 
2.17.1


^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
@ 2018-06-21 21:07 ` William Breathitt Gray
  2018-07-07 15:16   ` Greg KH
  2018-07-18  3:49   ` Andrew Morton
  2018-06-21 21:07 ` [PATCH v7 02/10] counter: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
                   ` (10 subsequent siblings)
  11 siblings, 2 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:07 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

This patch introduces the Generic Counter interface for supporting
counter devices.

In the context of the Generic Counter interface, a counter is defined as
a device that reports one or more "counts" based on the state changes of
one or more "signals" as evaluated by a defined "count function."

Driver callbacks should be provided to communicate with the device: to
read and write various Signals and Counts, and to set and get the
"action mode" and "count function" for various Synapses and Counts
respectively.

To support a counter device, a driver must first allocate the available
Counter Signals via counter_signal structures. These Signals should
be stored as an array and set to the signals array member of an
allocated counter_device structure before the Counter is registered to
the system.

Counter Counts may be allocated via counter_count structures, and
respective Counter Signal associations (Synapses) made via
counter_synapse structures. Associated counter_synapse structures are
stored as an array and set to the the synapses array member of the
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.

A counter device is registered to the system by passing the respective
initialized counter_device structure to the counter_register function;
similarly, the counter_unregister function unregisters the respective
Counter. The devm_counter_register and devm_counter_unregister functions
serve as device memory-managed versions of the counter_register and
counter_unregister functions respectively.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 MAINTAINERS                       |    7 +
 drivers/Kconfig                   |    2 +
 drivers/Makefile                  |    1 +
 drivers/counter/Kconfig           |   18 +
 drivers/counter/Makefile          |    8 +
 drivers/counter/generic-counter.c | 1519 +++++++++++++++++++++++++++++
 include/linux/counter.h           |  534 ++++++++++
 7 files changed, 2089 insertions(+)
 create mode 100644 drivers/counter/Kconfig
 create mode 100644 drivers/counter/Makefile
 create mode 100644 drivers/counter/generic-counter.c
 create mode 100644 include/linux/counter.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8db4875b1fa9..f6e995c142ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3688,6 +3688,13 @@ W:	http://www.fi.muni.cz/~kas/cosa/
 S:	Maintained
 F:	drivers/net/wan/cosa*
 
+COUNTER SUBSYSTEM
+M:	William Breathitt Gray <vilhelm.gray@gmail.com>
+L:	linux-iio@vger.kernel.org
+S:	Maintained
+F:	drivers/counter/
+F:	include/linux/counter.h
+
 CPMAC ETHERNET DRIVER
 M:	Florian Fainelli <f.fainelli@gmail.com>
 L:	netdev@vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 95b9ccc08165..6932ac9316e0 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -217,4 +217,6 @@ source "drivers/siox/Kconfig"
 
 source "drivers/slimbus/Kconfig"
 
+source "drivers/counter/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 24cd47014657..ae9596976372 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -185,3 +185,4 @@ obj-$(CONFIG_TEE)		+= tee/
 obj-$(CONFIG_MULTIPLEXER)	+= mux/
 obj-$(CONFIG_UNISYS_VISORBUS)	+= visorbus/
 obj-$(CONFIG_SIOX)		+= siox/
+obj-$(CONFIG_COUNTER)		+= counter/
diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
new file mode 100644
index 000000000000..65fa92abd5a4
--- /dev/null
+++ b/drivers/counter/Kconfig
@@ -0,0 +1,18 @@
+#
+# Counter devices
+#
+# When adding new entries keep the list in alphabetical order
+
+menuconfig COUNTER
+	tristate "Counter support"
+	help
+	  Provides Generic Counter interface support for counter devices.
+
+	  Counter devices are prevalent within a diverse spectrum of industries.
+	  The ubiquitous presence of these devices necessitates a common
+	  interface and standard of interaction and exposure. This driver API
+	  attempts to resolve the issue of duplicate code found among existing
+	  counter device drivers by providing a generic counter interface for
+	  consumption. The Generic Counter interface enables drivers to support
+	  and expose a common set of components and functionality present in
+	  counter devices.
diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
new file mode 100644
index 000000000000..ad1ba7109cdc
--- /dev/null
+++ b/drivers/counter/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for Counter devices
+#
+
+# When adding new entries keep the list in alphabetical order
+
+obj-$(CONFIG_COUNTER) += counter.o
+counter-y := generic-counter.o
diff --git a/drivers/counter/generic-counter.c b/drivers/counter/generic-counter.c
new file mode 100644
index 000000000000..483826c8ce01
--- /dev/null
+++ b/drivers/counter/generic-counter.c
@@ -0,0 +1,1519 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generic Counter interface
+ * Copyright (C) 2017 William Breathitt Gray
+ */
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/fs.h>
+#include <linux/gfp.h>
+#include <linux/idr.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/printk.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/types.h>
+
+#include <linux/counter.h>
+
+const char *const count_direction_str[2] = {
+	[COUNT_DIRECTION_FORWARD] = "forward",
+	[COUNT_DIRECTION_BACKWARD] = "backward"
+};
+EXPORT_SYMBOL(count_direction_str);
+
+const char *const count_mode_str[4] = {
+	[COUNT_MODE_NORMAL] = "normal",
+	[COUNT_MODE_RANGE_LIMIT] = "range limit",
+	[COUNT_MODE_NON_RECYCLE] = "non-recycle",
+	[COUNT_MODE_MODULO_N] = "modulo-n"
+};
+EXPORT_SYMBOL(count_mode_str);
+
+ssize_t counter_signal_enum_read(struct counter_device *counter,
+				 struct counter_signal *signal, void *priv,
+				 char *buf)
+{
+	const struct counter_signal_enum_ext *const e = priv;
+	int err;
+	size_t index;
+
+	if (!e->get)
+		return -EINVAL;
+
+	err = e->get(counter, signal, &index);
+	if (err)
+		return err;
+
+	if (index >= e->num_items)
+		return -EINVAL;
+
+	return scnprintf(buf, PAGE_SIZE, "%s\n", e->items[index]);
+}
+EXPORT_SYMBOL(counter_signal_enum_read);
+
+ssize_t counter_signal_enum_write(struct counter_device *counter,
+				  struct counter_signal *signal, void *priv,
+				  const char *buf, size_t len)
+{
+	const struct counter_signal_enum_ext *const e = priv;
+	ssize_t index;
+	int err;
+
+	if (!e->set)
+		return -EINVAL;
+
+	index = __sysfs_match_string(e->items, e->num_items, buf);
+	if (index < 0)
+		return index;
+
+	err = e->set(counter, signal, index);
+	if (err)
+		return err;
+
+	return len;
+}
+EXPORT_SYMBOL(counter_signal_enum_write);
+
+ssize_t counter_signal_enum_available_read(struct counter_device *counter,
+					   struct counter_signal *signal,
+					   void *priv, char *buf)
+{
+	const struct counter_signal_enum_ext *const e = priv;
+	size_t i;
+	size_t len = 0;
+
+	if (!e->num_items)
+		return 0;
+
+	for (i = 0; i < e->num_items; i++)
+		len += scnprintf(buf + len, PAGE_SIZE - len, "%s\n",
+			e->items[i]);
+
+	return len;
+}
+EXPORT_SYMBOL(counter_signal_enum_available_read);
+
+ssize_t counter_count_enum_read(struct counter_device *counter,
+				struct counter_count *count, void *priv,
+				char *buf)
+{
+	const struct counter_count_enum_ext *const e = priv;
+	int err;
+	size_t index;
+
+	if (!e->get)
+		return -EINVAL;
+
+	err = e->get(counter, count, &index);
+	if (err)
+		return err;
+
+	if (index >= e->num_items)
+		return -EINVAL;
+
+	return scnprintf(buf, PAGE_SIZE, "%s\n", e->items[index]);
+}
+EXPORT_SYMBOL(counter_count_enum_read);
+
+ssize_t counter_count_enum_write(struct counter_device *counter,
+				 struct counter_count *count, void *priv,
+				 const char *buf, size_t len)
+{
+	const struct counter_count_enum_ext *const e = priv;
+	ssize_t index;
+	int err;
+
+	if (!e->set)
+		return -EINVAL;
+
+	index = __sysfs_match_string(e->items, e->num_items, buf);
+	if (index < 0)
+		return index;
+
+	err = e->set(counter, count, index);
+	if (err)
+		return err;
+
+	return len;
+}
+EXPORT_SYMBOL(counter_count_enum_write);
+
+ssize_t counter_count_enum_available_read(struct counter_device *counter,
+					  struct counter_count *count,
+					  void *priv, char *buf)
+{
+	const struct counter_count_enum_ext *const e = priv;
+	size_t i;
+	size_t len = 0;
+
+	if (!e->num_items)
+		return 0;
+
+	for (i = 0; i < e->num_items; i++)
+		len += scnprintf(buf + len, PAGE_SIZE - len, "%s\n",
+			e->items[i]);
+
+	return len;
+}
+EXPORT_SYMBOL(counter_count_enum_available_read);
+
+ssize_t counter_device_enum_read(struct counter_device *counter, void *priv,
+				 char *buf)
+{
+	const struct counter_device_enum_ext *const e = priv;
+	int err;
+	size_t index;
+
+	if (!e->get)
+		return -EINVAL;
+
+	err = e->get(counter, &index);
+	if (err)
+		return err;
+
+	if (index >= e->num_items)
+		return -EINVAL;
+
+	return scnprintf(buf, PAGE_SIZE, "%s\n", e->items[index]);
+}
+EXPORT_SYMBOL(counter_device_enum_read);
+
+ssize_t counter_device_enum_write(struct counter_device *counter, void *priv,
+				  const char *buf, size_t len)
+{
+	const struct counter_device_enum_ext *const e = priv;
+	ssize_t index;
+	int err;
+
+	if (!e->set)
+		return -EINVAL;
+
+	index = __sysfs_match_string(e->items, e->num_items, buf);
+	if (index < 0)
+		return index;
+
+	err = e->set(counter, index);
+	if (err)
+		return err;
+
+	return len;
+}
+EXPORT_SYMBOL(counter_device_enum_write);
+
+ssize_t counter_device_enum_available_read(struct counter_device *counter,
+					   void *priv, char *buf)
+{
+	const struct counter_device_enum_ext *const e = priv;
+	size_t i;
+	size_t len = 0;
+
+	if (!e->num_items)
+		return 0;
+
+	for (i = 0; i < e->num_items; i++)
+		len += scnprintf(buf + len, PAGE_SIZE - len, "%s\n",
+			e->items[i]);
+
+	return len;
+}
+EXPORT_SYMBOL(counter_device_enum_available_read);
+
+static const char *const signal_level_str[] = {
+	[SIGNAL_LEVEL_LOW] = "low",
+	[SIGNAL_LEVEL_HIGH] = "high"
+};
+
+/**
+ * signal_read_value_set - set signal_read_value data
+ * @val:	signal_read_value structure to set
+ * @type:	property Signal data represents
+ * @data:	Signal data
+ *
+ * This function sets an opaque signal_read_value structure with the provided
+ * Signal data.
+ */
+void signal_read_value_set(struct signal_read_value *const val,
+			   const enum signal_value_type type, void *const data)
+{
+	if (type == SIGNAL_LEVEL)
+		val->len = scnprintf(val->buf, PAGE_SIZE, "%s\n",
+			signal_level_str[*(enum signal_level *)data]);
+	else
+		val->len = 0;
+}
+EXPORT_SYMBOL(signal_read_value_set);
+
+/**
+ * count_read_value_set - set count_read_value data
+ * @val:	count_read_value structure to set
+ * @type:	property Count data represents
+ * @data:	Count data
+ *
+ * This function sets an opaque count_read_value structure with the provided
+ * Count data.
+ */
+void count_read_value_set(struct count_read_value *const val,
+			  const enum count_value_type type, void *const data)
+{
+	switch (type) {
+	case COUNT_POSITION:
+		val->len = scnprintf(val->buf, PAGE_SIZE, "%lu\n",
+				     *(unsigned long *)data);
+		break;
+	default:
+		val->len = 0;
+	}
+}
+EXPORT_SYMBOL(count_read_value_set);
+
+/**
+ * count_write_value_get - get count_write_value data
+ * @data:	Count data
+ * @type:	property Count data represents
+ * @val:	count_write_value structure containing data
+ *
+ * This function extracts Count data from the provided opaque count_write_value
+ * structure and stores it at the address provided by @data.
+ *
+ * RETURNS:
+ * 0 on success, negative error number on failure.
+ */
+int count_write_value_get(void *const data, const enum count_value_type type,
+			  const struct count_write_value *const val)
+{
+	int err;
+
+	switch (type) {
+	case COUNT_POSITION:
+		err = kstrtoul(val->buf, 0, data);
+		if (err)
+			return err;
+		break;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(count_write_value_get);
+
+struct counter_device_attr {
+	struct device_attribute		dev_attr;
+	struct list_head		l;
+	void				*component;
+};
+
+static int counter_attribute_create(
+	struct counter_device_attr_group *const group,
+	const char *const prefix,
+	const char *const name,
+	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+			char *buf),
+	ssize_t (*store)(struct device *dev, struct device_attribute *attr,
+			 const char *buf, size_t len),
+	void *const component)
+{
+	struct counter_device_attr *counter_attr;
+	struct device_attribute *dev_attr;
+	int err;
+	struct list_head *const attr_list = &group->attr_list;
+
+	/* Allocate a Counter device attribute */
+	counter_attr = kzalloc(sizeof(*counter_attr), GFP_KERNEL);
+	if (!counter_attr)
+		return -ENOMEM;
+	dev_attr = &counter_attr->dev_attr;
+
+	sysfs_attr_init(&dev_attr->attr);
+
+	/* Configure device attribute */
+	dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, name);
+	if (!dev_attr->attr.name) {
+		err = -ENOMEM;
+		goto err_free_counter_attr;
+	}
+	if (show) {
+		dev_attr->attr.mode |= 0444;
+		dev_attr->show = show;
+	}
+	if (store) {
+		dev_attr->attr.mode |= 0200;
+		dev_attr->store = store;
+	}
+
+	/* Store associated Counter component with attribute */
+	counter_attr->component = component;
+
+	/* Keep track of the attribute for later cleanup */
+	list_add(&counter_attr->l, attr_list);
+	group->num_attr++;
+
+	return 0;
+
+err_free_counter_attr:
+	kfree(counter_attr);
+	return err;
+}
+
+#define to_counter_attr(_dev_attr) \
+	container_of(_dev_attr, struct counter_device_attr, dev_attr)
+
+struct signal_comp_t {
+	struct counter_signal	*signal;
+};
+
+static ssize_t counter_signal_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct signal_comp_t *const component = devattr->component;
+	struct counter_signal *const signal = component->signal;
+	int err;
+	struct signal_read_value val = { .buf = buf };
+
+	err = counter->ops->signal_read(counter, signal, &val);
+	if (err)
+		return err;
+
+	return val.len;
+}
+
+struct name_comp_t {
+	const char	*name;
+};
+
+static ssize_t counter_device_attr_name_show(struct device *dev,
+					     struct device_attribute *attr,
+					     char *buf)
+{
+	const struct name_comp_t *const comp = to_counter_attr(attr)->component;
+
+	return scnprintf(buf, PAGE_SIZE, "%s\n", comp->name);
+}
+
+static int counter_name_attribute_create(
+	struct counter_device_attr_group *const group,
+	const char *const name)
+{
+	struct name_comp_t *name_comp;
+	int err;
+
+	/* Skip if no name */
+	if (!name)
+		return 0;
+
+	/* Allocate name attribute component */
+	name_comp = kmalloc(sizeof(*name_comp), GFP_KERNEL);
+	if (!name_comp)
+		return -ENOMEM;
+	name_comp->name = name;
+
+	/* Allocate Signal name attribute */
+	err = counter_attribute_create(group, "", "name",
+				       counter_device_attr_name_show, NULL,
+				       name_comp);
+	if (err)
+		goto err_free_name_comp;
+
+	return 0;
+
+err_free_name_comp:
+	kfree(name_comp);
+	return err;
+}
+
+struct signal_ext_comp_t {
+	struct counter_signal		*signal;
+	const struct counter_signal_ext	*ext;
+};
+
+static ssize_t counter_signal_ext_show(struct device *dev,
+				       struct device_attribute *attr, char *buf)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct signal_ext_comp_t *const comp = devattr->component;
+	const struct counter_signal_ext *const ext = comp->ext;
+
+	return ext->read(dev_get_drvdata(dev), comp->signal, ext->priv, buf);
+}
+
+static ssize_t counter_signal_ext_store(struct device *dev,
+					struct device_attribute *attr,
+					const char *buf, size_t len)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct signal_ext_comp_t *const comp = devattr->component;
+	const struct counter_signal_ext *const ext = comp->ext;
+
+	return ext->write(dev_get_drvdata(dev), comp->signal, ext->priv, buf,
+		len);
+}
+
+static void counter_device_attr_list_free(struct list_head *attr_list)
+{
+	struct counter_device_attr *p, *n;
+
+	list_for_each_entry_safe(p, n, attr_list, l) {
+		/* free attribute name and associated component memory */
+		kfree(p->dev_attr.attr.name);
+		kfree(p->component);
+		list_del(&p->l);
+		kfree(p);
+	}
+}
+
+static int counter_signal_ext_register(
+	struct counter_device_attr_group *const group,
+	struct counter_signal *const signal)
+{
+	const size_t num_ext = signal->num_ext;
+	size_t i;
+	const struct counter_signal_ext *ext;
+	struct signal_ext_comp_t *signal_ext_comp;
+	int err;
+
+	/* Create an attribute for each extension */
+	for (i = 0 ; i < num_ext; i++) {
+		ext = signal->ext + i;
+
+		/* Allocate signal_ext attribute component */
+		signal_ext_comp = kmalloc(sizeof(*signal_ext_comp), GFP_KERNEL);
+		if (!signal_ext_comp) {
+			err = -ENOMEM;
+			goto err_free_attr_list;
+		}
+		signal_ext_comp->signal = signal;
+		signal_ext_comp->ext = ext;
+
+		/* Allocate a Counter device attribute */
+		err = counter_attribute_create(group, "", ext->name,
+			(ext->read) ? counter_signal_ext_show : NULL,
+			(ext->write) ? counter_signal_ext_store : NULL,
+			signal_ext_comp);
+		if (err) {
+			kfree(signal_ext_comp);
+			goto err_free_attr_list;
+		}
+	}
+
+	return 0;
+
+err_free_attr_list:
+	counter_device_attr_list_free(&group->attr_list);
+	return err;
+}
+
+static int counter_signal_attributes_create(
+	struct counter_device_attr_group *const group,
+	const struct counter_device *const counter,
+	struct counter_signal *const signal)
+{
+	struct signal_comp_t *signal_comp;
+	int err;
+
+	/* Allocate Signal attribute component */
+	signal_comp = kmalloc(sizeof(*signal_comp), GFP_KERNEL);
+	if (!signal_comp)
+		return -ENOMEM;
+	signal_comp->signal = signal;
+
+	/* Create main Signal attribute */
+	err = counter_attribute_create(group, "", "signal",
+		(counter->ops->signal_read) ? counter_signal_show : NULL, NULL,
+		signal_comp);
+	if (err) {
+		kfree(signal_comp);
+		return err;
+	}
+
+	/* Create Signal name attribute */
+	err = counter_name_attribute_create(group, signal->name);
+	if (err)
+		goto err_free_attr_list;
+
+	/* Register Signal extension attributes */
+	err = counter_signal_ext_register(group, signal);
+	if (err)
+		goto err_free_attr_list;
+
+	return 0;
+
+err_free_attr_list:
+	counter_device_attr_list_free(&group->attr_list);
+	return err;
+}
+
+static int counter_signals_register(
+	struct counter_device_attr_group *const groups_list,
+	const struct counter_device *const counter)
+{
+	const size_t num_signals = counter->num_signals;
+	size_t i;
+	struct counter_signal *signal;
+	const char *name;
+	int err;
+
+	/* Register each Signal */
+	for (i = 0; i < num_signals; i++) {
+		signal = counter->signals + i;
+
+		/* Generate Signal attribute directory name */
+		name = kasprintf(GFP_KERNEL, "signal%d", signal->id);
+		if (!name) {
+			err = -ENOMEM;
+			goto err_free_attr_groups;
+		}
+		groups_list[i].attr_group.name = name;
+
+		/* Create all attributes associated with Signal */
+		err = counter_signal_attributes_create(groups_list + i, counter,
+						       signal);
+		if (err)
+			goto err_free_attr_groups;
+	}
+
+	return 0;
+
+err_free_attr_groups:
+	do {
+		kfree(groups_list[i].attr_group.name);
+		counter_device_attr_list_free(&groups_list[i].attr_list);
+	} while (i--);
+	return err;
+}
+
+static const char *const synapse_action_str[] = {
+	[SYNAPSE_ACTION_NONE] = "none",
+	[SYNAPSE_ACTION_RISING_EDGE] = "rising edge",
+	[SYNAPSE_ACTION_FALLING_EDGE] = "falling edge",
+	[SYNAPSE_ACTION_BOTH_EDGES] = "both edges"
+};
+
+struct action_comp_t {
+	struct counter_synapse	*synapse;
+	struct counter_count	*count;
+};
+
+static ssize_t counter_action_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	int err;
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	const struct action_comp_t *const component = devattr->component;
+	struct counter_count *const count = component->count;
+	struct counter_synapse *const synapse = component->synapse;
+	size_t action_index;
+	enum synapse_action action;
+
+	err = counter->ops->action_get(counter, count, synapse, &action_index);
+	if (err)
+		return err;
+
+	synapse->action = action_index;
+
+	action = synapse->actions_list[action_index];
+	return scnprintf(buf, PAGE_SIZE, "%s\n", synapse_action_str[action]);
+}
+
+static ssize_t counter_action_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t len)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct action_comp_t *const component = devattr->component;
+	struct counter_synapse *const synapse = component->synapse;
+	size_t action_index;
+	const size_t num_actions = synapse->num_actions;
+	enum synapse_action action;
+	int err;
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	struct counter_count *const count = component->count;
+
+	/* Find requested action mode */
+	for (action_index = 0; action_index < num_actions; action_index++) {
+		action = synapse->actions_list[action_index];
+		if (sysfs_streq(buf, synapse_action_str[action]))
+			break;
+	}
+	/* If requested action mode not found */
+	if (action_index >= num_actions)
+		return -EINVAL;
+
+	err = counter->ops->action_set(counter, count, synapse, action_index);
+	if (err)
+		return err;
+
+	synapse->action = action_index;
+
+	return len;
+}
+
+struct action_avail_comp_t {
+	const enum synapse_action	*actions_list;
+	size_t				num_actions;
+};
+
+static ssize_t counter_synapse_action_available_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct action_avail_comp_t *const component = devattr->component;
+	size_t i;
+	enum synapse_action action;
+	ssize_t len = 0;
+
+	for (i = 0; i < component->num_actions; i++) {
+		action = component->actions_list[i];
+		len += scnprintf(buf + len, PAGE_SIZE - len, "%s\n",
+			synapse_action_str[action]);
+	}
+
+	return len;
+}
+
+static int counter_synapses_register(
+	struct counter_device_attr_group *const group,
+	const struct counter_device *const counter,
+	struct counter_count *const count, const char *const count_attr_name)
+{
+	size_t i;
+	struct counter_synapse *synapse;
+	const char *prefix;
+	struct action_comp_t *action_comp;
+	int err;
+	struct action_avail_comp_t *avail_comp;
+
+	/* Register each Synapse */
+	for (i = 0; i < count->num_synapses; i++) {
+		synapse = count->synapses + i;
+
+		/* Generate attribute prefix */
+		prefix = kasprintf(GFP_KERNEL, "signal%d_",
+				   synapse->signal->id);
+		if (!prefix) {
+			err = -ENOMEM;
+			goto err_free_attr_list;
+		}
+
+		/* Allocate action attribute component */
+		action_comp = kmalloc(sizeof(*action_comp), GFP_KERNEL);
+		if (!action_comp) {
+			err = -ENOMEM;
+			goto err_free_prefix;
+		}
+		action_comp->synapse = synapse;
+		action_comp->count = count;
+
+		/* Create action attribute */
+		err = counter_attribute_create(group, prefix, "action",
+			(counter->ops->action_get) ? counter_action_show : NULL,
+			(counter->ops->action_set) ? counter_action_store : NULL,
+			action_comp);
+		if (err) {
+			kfree(action_comp);
+			goto err_free_prefix;
+		}
+
+		/* Allocate action available attribute component */
+		avail_comp = kmalloc(sizeof(*avail_comp), GFP_KERNEL);
+		if (!avail_comp) {
+			err = -ENOMEM;
+			goto err_free_prefix;
+		}
+		avail_comp->actions_list = synapse->actions_list;
+		avail_comp->num_actions = synapse->num_actions;
+
+		/* Create action_available attribute */
+		err = counter_attribute_create(group, prefix,
+			"action_available",
+			counter_synapse_action_available_show, NULL,
+			avail_comp);
+		if (err) {
+			kfree(avail_comp);
+			goto err_free_prefix;
+		}
+
+		kfree(prefix);
+	}
+
+	return 0;
+
+err_free_prefix:
+	kfree(prefix);
+err_free_attr_list:
+	counter_device_attr_list_free(&group->attr_list);
+	return err;
+}
+
+struct count_comp_t {
+	struct counter_count	*count;
+};
+
+static ssize_t counter_count_show(struct device *dev,
+				  struct device_attribute *attr,
+				  char *buf)
+{
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct count_comp_t *const component = devattr->component;
+	struct counter_count *const count = component->count;
+	int err;
+	struct count_read_value val = { .buf = buf };
+
+	err = counter->ops->count_read(counter, count, &val);
+	if (err)
+		return err;
+
+	return val.len;
+}
+
+static ssize_t counter_count_store(struct device *dev,
+				   struct device_attribute *attr,
+				   const char *buf, size_t len)
+{
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct count_comp_t *const component = devattr->component;
+	struct counter_count *const count = component->count;
+	int err;
+	struct count_write_value val = { .buf = buf };
+
+	err = counter->ops->count_write(counter, count, &val);
+	if (err)
+		return err;
+
+	return len;
+}
+
+static const char *const count_function_str[] = {
+	[COUNT_FUNCTION_INCREASE] = "increase",
+	[COUNT_FUNCTION_DECREASE] = "decrease",
+	[COUNT_FUNCTION_PULSE_DIRECTION] = "pulse-direction",
+	[COUNT_FUNCTION_QUADRATURE_X1_A] = "quadrature x1 a",
+	[COUNT_FUNCTION_QUADRATURE_X1_B] = "quadrature x1 b",
+	[COUNT_FUNCTION_QUADRATURE_X2_A] = "quadrature x2 a",
+	[COUNT_FUNCTION_QUADRATURE_X2_B] = "quadrature x2 b",
+	[COUNT_FUNCTION_QUADRATURE_X4] = "quadrature x4"
+};
+
+static ssize_t counter_function_show(struct device *dev,
+				     struct device_attribute *attr, char *buf)
+{
+	int err;
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct count_comp_t *const component = devattr->component;
+	struct counter_count *const count = component->count;
+	size_t func_index;
+	enum count_function function;
+
+	err = counter->ops->function_get(counter, count, &func_index);
+	if (err)
+		return err;
+
+	count->function = func_index;
+
+	function = count->functions_list[func_index];
+	return scnprintf(buf, PAGE_SIZE, "%s\n", count_function_str[function]);
+}
+
+static ssize_t counter_function_store(struct device *dev,
+				      struct device_attribute *attr,
+				      const char *buf, size_t len)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct count_comp_t *const component = devattr->component;
+	struct counter_count *const count = component->count;
+	const size_t num_functions = count->num_functions;
+	size_t func_index;
+	enum count_function function;
+	int err;
+	struct counter_device *const counter = dev_get_drvdata(dev);
+
+	/* Find requested Count function mode */
+	for (func_index = 0; func_index < num_functions; func_index++) {
+		function = count->functions_list[func_index];
+		if (sysfs_streq(buf, count_function_str[function]))
+			break;
+	}
+	/* Return error if requested Count function mode not found */
+	if (func_index >= num_functions)
+		return -EINVAL;
+
+	err = counter->ops->function_set(counter, count, func_index);
+	if (err)
+		return err;
+
+	count->function = func_index;
+
+	return len;
+}
+
+struct count_ext_comp_t {
+	struct counter_count		*count;
+	const struct counter_count_ext	*ext;
+};
+
+static ssize_t counter_count_ext_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct count_ext_comp_t *const comp = devattr->component;
+	const struct counter_count_ext *const ext = comp->ext;
+
+	return ext->read(dev_get_drvdata(dev), comp->count, ext->priv, buf);
+}
+
+static ssize_t counter_count_ext_store(struct device *dev,
+				       struct device_attribute *attr,
+				       const char *buf, size_t len)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct count_ext_comp_t *const comp = devattr->component;
+	const struct counter_count_ext *const ext = comp->ext;
+
+	return ext->write(dev_get_drvdata(dev), comp->count, ext->priv, buf,
+		len);
+}
+
+static int counter_count_ext_register(
+	struct counter_device_attr_group *const group,
+	struct counter_count *const count)
+{
+	size_t i;
+	const struct counter_count_ext *ext;
+	struct count_ext_comp_t *count_ext_comp;
+	int err;
+
+	/* Create an attribute for each extension */
+	for (i = 0 ; i < count->num_ext; i++) {
+		ext = count->ext + i;
+
+		/* Allocate count_ext attribute component */
+		count_ext_comp = kmalloc(sizeof(*count_ext_comp), GFP_KERNEL);
+		if (!count_ext_comp) {
+			err = -ENOMEM;
+			goto err_free_attr_list;
+		}
+		count_ext_comp->count = count;
+		count_ext_comp->ext = ext;
+
+		/* Allocate count_ext attribute */
+		err = counter_attribute_create(group, "", ext->name,
+			(ext->read) ? counter_count_ext_show : NULL,
+			(ext->write) ? counter_count_ext_store : NULL,
+			count_ext_comp);
+		if (err) {
+			kfree(count_ext_comp);
+			goto err_free_attr_list;
+		}
+	}
+
+	return 0;
+
+err_free_attr_list:
+	counter_device_attr_list_free(&group->attr_list);
+	return err;
+}
+
+struct func_avail_comp_t {
+	const enum count_function	*functions_list;
+	size_t				num_functions;
+};
+
+static ssize_t counter_count_function_available_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct func_avail_comp_t *const component = devattr->component;
+	const enum count_function *const func_list = component->functions_list;
+	const size_t num_functions = component->num_functions;
+	size_t i;
+	enum count_function function;
+	ssize_t len = 0;
+
+	for (i = 0; i < num_functions; i++) {
+		function = func_list[i];
+		len += scnprintf(buf + len, PAGE_SIZE - len, "%s\n",
+			count_function_str[function]);
+	}
+
+	return len;
+}
+
+static int counter_count_attributes_create(
+	struct counter_device_attr_group *const group,
+	const struct counter_device *const counter,
+	struct counter_count *const count)
+{
+	struct count_comp_t *count_comp;
+	int err;
+	struct count_comp_t *func_comp;
+	struct func_avail_comp_t *avail_comp;
+
+	/* Allocate count attribute component */
+	count_comp = kmalloc(sizeof(*count_comp), GFP_KERNEL);
+	if (!count_comp)
+		return -ENOMEM;
+	count_comp->count = count;
+
+	/* Create main Count attribute */
+	err = counter_attribute_create(group, "", "count",
+		(counter->ops->count_read) ? counter_count_show : NULL,
+		(counter->ops->count_write) ? counter_count_store : NULL,
+		count_comp);
+	if (err) {
+		kfree(count_comp);
+		return err;
+	}
+
+	/* Allocate function attribute component */
+	func_comp = kmalloc(sizeof(*func_comp), GFP_KERNEL);
+	if (!func_comp) {
+		err = -ENOMEM;
+		goto err_free_attr_list;
+	}
+	func_comp->count = count;
+
+	/* Create Count function attribute */
+	err = counter_attribute_create(group, "", "function",
+		(counter->ops->function_get) ? counter_function_show : NULL,
+		(counter->ops->function_set) ? counter_function_store : NULL,
+		func_comp);
+	if (err) {
+		kfree(func_comp);
+		goto err_free_attr_list;
+	}
+
+	/* Allocate function available attribute component */
+	avail_comp = kmalloc(sizeof(*avail_comp), GFP_KERNEL);
+	if (!avail_comp) {
+		err = -ENOMEM;
+		goto err_free_attr_list;
+	}
+	avail_comp->functions_list = count->functions_list;
+	avail_comp->num_functions = count->num_functions;
+
+	/* Create Count function_available attribute */
+	err = counter_attribute_create(group, "", "function_available",
+				       counter_count_function_available_show,
+				       NULL, avail_comp);
+	if (err) {
+		kfree(avail_comp);
+		goto err_free_attr_list;
+	}
+
+	/* Create Count name attribute */
+	err = counter_name_attribute_create(group, count->name);
+	if (err)
+		goto err_free_attr_list;
+
+	/* Register Count extension attributes */
+	err = counter_count_ext_register(group, count);
+	if (err)
+		goto err_free_attr_list;
+
+	return 0;
+
+err_free_attr_list:
+	counter_device_attr_list_free(&group->attr_list);
+	return err;
+}
+
+static int counter_counts_register(
+	struct counter_device_attr_group *const groups_list,
+	const struct counter_device *const counter)
+{
+	size_t i;
+	struct counter_count *count;
+	const char *name;
+	int err;
+
+	/* Register each Count */
+	for (i = 0; i < counter->num_counts; i++) {
+		count = counter->counts + i;
+
+		/* Generate Count attribute directory name */
+		name = kasprintf(GFP_KERNEL, "count%d", count->id);
+		if (!name) {
+			err = -ENOMEM;
+			goto err_free_attr_groups;
+		}
+		groups_list[i].attr_group.name = name;
+
+		/* Register the Synapses associated with each Count */
+		err = counter_synapses_register(groups_list + i, counter, count,
+						name);
+		if (err)
+			goto err_free_attr_groups;
+
+		/* Create all attributes associated with Count */
+		err = counter_count_attributes_create(groups_list + i, counter,
+						      count);
+		if (err)
+			goto err_free_attr_groups;
+	}
+
+	return 0;
+
+err_free_attr_groups:
+	do {
+		kfree(groups_list[i].attr_group.name);
+		counter_device_attr_list_free(&groups_list[i].attr_list);
+	} while (i--);
+	return err;
+}
+
+struct size_comp_t {
+	size_t size;
+};
+
+static ssize_t counter_device_attr_size_show(struct device *dev,
+					     struct device_attribute *attr,
+					     char *buf)
+{
+	const struct size_comp_t *const comp = to_counter_attr(attr)->component;
+
+	return scnprintf(buf, PAGE_SIZE, "%zu\n", comp->size);
+}
+
+static int counter_size_attribute_create(
+	struct counter_device_attr_group *const group,
+	const size_t size, const char *const name)
+{
+	struct size_comp_t *size_comp;
+	int err;
+
+	/* Allocate size attribute component */
+	size_comp = kmalloc(sizeof(*size_comp), GFP_KERNEL);
+	if (!size_comp)
+		return -ENOMEM;
+	size_comp->size = size;
+
+	err = counter_attribute_create(group, "", name,
+				       counter_device_attr_size_show, NULL,
+				       size_comp);
+	if (err)
+		goto err_free_size_comp;
+
+	return 0;
+
+err_free_size_comp:
+	kfree(size_comp);
+	return err;
+}
+
+struct ext_comp_t {
+	const struct counter_device_ext	*ext;
+};
+
+static ssize_t counter_device_ext_show(struct device *dev,
+				       struct device_attribute *attr, char *buf)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct ext_comp_t *const component = devattr->component;
+	const struct counter_device_ext *const ext = component->ext;
+
+	return ext->read(dev_get_drvdata(dev), ext->priv, buf);
+}
+
+static ssize_t counter_device_ext_store(struct device *dev,
+					struct device_attribute *attr,
+					const char *buf, size_t len)
+{
+	const struct counter_device_attr *const devattr = to_counter_attr(attr);
+	const struct ext_comp_t *const component = devattr->component;
+	const struct counter_device_ext *const ext = component->ext;
+
+	return ext->write(dev_get_drvdata(dev), ext->priv, buf, len);
+}
+
+static int counter_device_ext_register(
+	struct counter_device_attr_group *const group,
+	struct counter_device *const counter)
+{
+	size_t i;
+	struct ext_comp_t *ext_comp;
+	int err;
+
+	/* Create an attribute for each extension */
+	for (i = 0 ; i < counter->num_ext; i++) {
+		/* Allocate extension attribute component */
+		ext_comp = kmalloc(sizeof(*ext_comp), GFP_KERNEL);
+		if (!ext_comp) {
+			err = -ENOMEM;
+			goto err_free_attr_list;
+		}
+
+		ext_comp->ext = counter->ext + i;
+
+		/* Allocate extension attribute */
+		err = counter_attribute_create(group, "", counter->ext[i].name,
+			(counter->ext[i].read) ? counter_device_ext_show : NULL,
+			(counter->ext[i].write) ? counter_device_ext_store : NULL,
+			ext_comp);
+		if (err) {
+			kfree(ext_comp);
+			goto err_free_attr_list;
+		}
+	}
+
+	return 0;
+
+err_free_attr_list:
+	counter_device_attr_list_free(&group->attr_list);
+	return err;
+}
+
+static int counter_global_attr_register(
+	struct counter_device_attr_group *const group,
+	struct counter_device *const counter)
+{
+	int err;
+
+	/* Create name attribute */
+	err = counter_name_attribute_create(group, counter->name);
+	if (err)
+		return err;
+
+	/* Create num_counts attribute */
+	err = counter_size_attribute_create(group, counter->num_counts,
+					    "num_counts");
+	if (err)
+		goto err_free_attr_list;
+
+	/* Create num_signals attribute */
+	err = counter_size_attribute_create(group, counter->num_signals,
+					    "num_signals");
+	if (err)
+		goto err_free_attr_list;
+
+	/* Register Counter device extension attributes */
+	err = counter_device_ext_register(group, counter);
+	if (err)
+		goto err_free_attr_list;
+
+	return 0;
+
+err_free_attr_list:
+	counter_device_attr_list_free(&group->attr_list);
+	return err;
+}
+
+static void counter_device_groups_list_free(
+	struct counter_device_attr_group *const groups_list,
+	const size_t num_groups)
+{
+	struct counter_device_attr_group *group;
+	size_t i;
+
+	/* loop through all attribute groups (signals, counts, global, etc.) */
+	for (i = 0; i < num_groups; i++) {
+		group = groups_list + i;
+
+		/* free all attribute group and associated attributes memory */
+		kfree(group->attr_group.name);
+		kfree(group->attr_group.attrs);
+		counter_device_attr_list_free(&group->attr_list);
+	}
+
+	kfree(groups_list);
+}
+
+static int counter_device_groups_list_prepare(
+	struct counter_device *const counter)
+{
+	const size_t total_num_groups =
+		counter->num_signals + counter->num_counts + 1;
+	struct counter_device_attr_group *groups_list;
+	size_t i;
+	int err;
+	size_t num_groups = 0;
+
+	/* Allocate space for attribute groups (signals, counts, and ext) */
+	groups_list = kcalloc(total_num_groups, sizeof(*groups_list),
+			      GFP_KERNEL);
+	if (!groups_list)
+		return -ENOMEM;
+
+	/* Initialize attribute lists */
+	for (i = 0; i < total_num_groups; i++)
+		INIT_LIST_HEAD(&groups_list[i].attr_list);
+
+	/* Register Signals */
+	err = counter_signals_register(groups_list, counter);
+	if (err)
+		goto err_free_groups_list;
+	num_groups += counter->num_signals;
+
+	/* Register Counts and respective Synapses */
+	err = counter_counts_register(groups_list + num_groups, counter);
+	if (err)
+		goto err_free_groups_list;
+	num_groups += counter->num_counts;
+
+	/* Register Counter global attributes */
+	err = counter_global_attr_register(groups_list + num_groups, counter);
+	if (err)
+		goto err_free_groups_list;
+	num_groups++;
+
+	/* Store groups_list in device_state */
+	counter->device_state->groups_list = groups_list;
+	counter->device_state->num_groups = num_groups;
+
+	return 0;
+
+err_free_groups_list:
+	counter_device_groups_list_free(groups_list, num_groups);
+	return err;
+}
+
+static int counter_device_groups_prepare(
+	struct counter_device_state *const device_state)
+{
+	size_t i, j;
+	struct counter_device_attr_group *group;
+	int err;
+	struct counter_device_attr *p;
+
+	/* Allocate attribute groups for association with device */
+	device_state->groups = kcalloc(device_state->num_groups + 1,
+				       sizeof(*device_state->groups),
+				       GFP_KERNEL);
+	if (!device_state->groups)
+		return -ENOMEM;
+
+	/* Prepare each group of attributes for association */
+	for (i = 0; i < device_state->num_groups; i++) {
+		group = device_state->groups_list + i;
+
+		/* Allocate space for attribute pointers in attribute group */
+		group->attr_group.attrs = kcalloc(group->num_attr + 1,
+			sizeof(*group->attr_group.attrs), GFP_KERNEL);
+		if (!group->attr_group.attrs) {
+			err = -ENOMEM;
+			goto err_free_groups;
+		}
+
+		/* Add attribute pointers to attribute group */
+		j = 0;
+		list_for_each_entry(p, &group->attr_list, l)
+			group->attr_group.attrs[j++] = &p->dev_attr.attr;
+
+		/* Group attributes in attribute group */
+		device_state->groups[i] = &group->attr_group;
+	}
+	/* Associate attributes with device */
+	device_state->dev.groups = device_state->groups;
+
+	return 0;
+
+err_free_groups:
+	do {
+		group = device_state->groups_list + i;
+		kfree(group->attr_group.attrs);
+		group->attr_group.attrs = NULL;
+	} while (i--);
+	kfree(device_state->groups);
+	return err;
+}
+
+/* Provides a unique ID for each counter device */
+static DEFINE_IDA(counter_ida);
+
+static void counter_device_release(struct device *dev)
+{
+	struct counter_device *const counter = dev_get_drvdata(dev);
+	struct counter_device_state *const device_state = counter->device_state;
+
+	kfree(device_state->groups);
+	counter_device_groups_list_free(device_state->groups_list,
+					device_state->num_groups);
+	ida_simple_remove(&counter_ida, device_state->id);
+	kfree(device_state);
+}
+
+static struct device_type counter_device_type = {
+	.name = "counter_device",
+	.release = counter_device_release
+};
+
+static struct bus_type counter_bus_type = {
+	.name = "counter"
+};
+
+/**
+ * counter_register - register Counter to the system
+ * @counter:	pointer to Counter to register
+ *
+ * This function registers a Counter to the system. A sysfs "counter" directory
+ * will be created and populated with sysfs attributes correlating with the
+ * Counter Signals, Synapses, and Counts respectively.
+ */
+int counter_register(struct counter_device *const counter)
+{
+	struct counter_device_state *device_state;
+	int err;
+
+	/* Allocate internal state container for Counter device */
+	device_state = kzalloc(sizeof(*device_state), GFP_KERNEL);
+	if (!device_state)
+		return -ENOMEM;
+	counter->device_state = device_state;
+
+	/* Acquire unique ID */
+	device_state->id = ida_simple_get(&counter_ida, 0, 0, GFP_KERNEL);
+	if (device_state->id < 0) {
+		err = device_state->id;
+		goto err_free_device_state;
+	}
+
+	/* Configure device structure for Counter */
+	device_state->dev.type = &counter_device_type;
+	device_state->dev.bus = &counter_bus_type;
+	if (counter->parent) {
+		device_state->dev.parent = counter->parent;
+		device_state->dev.of_node = counter->parent->of_node;
+	}
+	dev_set_name(&device_state->dev, "counter%d", device_state->id);
+	device_initialize(&device_state->dev);
+	dev_set_drvdata(&device_state->dev, counter);
+
+	/* Prepare device attributes */
+	err = counter_device_groups_list_prepare(counter);
+	if (err)
+		goto err_free_id;
+
+	/* Organize device attributes to groups and match to device */
+	err = counter_device_groups_prepare(device_state);
+	if (err)
+		goto err_free_groups_list;
+
+	/* Add device to system */
+	err = device_add(&device_state->dev);
+	if (err)
+		goto err_free_groups;
+
+	return 0;
+
+err_free_groups:
+	kfree(device_state->groups);
+err_free_groups_list:
+	counter_device_groups_list_free(device_state->groups_list,
+					device_state->num_groups);
+err_free_id:
+	ida_simple_remove(&counter_ida, device_state->id);
+err_free_device_state:
+	kfree(device_state);
+	return err;
+}
+EXPORT_SYMBOL(counter_register);
+
+/**
+ * counter_unregister - unregister Counter from the system
+ * @counter:	pointer to Counter to unregister
+ *
+ * The Counter is unregistered from the system; all allocated memory is freed.
+ */
+void counter_unregister(struct counter_device *const counter)
+{
+	if (counter)
+		device_del(&counter->device_state->dev);
+}
+EXPORT_SYMBOL(counter_unregister);
+
+static void devm_counter_unreg(struct device *dev, void *res)
+{
+	counter_unregister(*(struct counter_device **)res);
+}
+
+/**
+ * devm_counter_register - Resource-managed counter_register
+ * @dev:	device to allocate counter_device for
+ * @counter:	pointer to Counter to register
+ *
+ * Managed counter_register. The Counter registered with this function is
+ * automatically unregistered on driver detach. This function calls
+ * counter_register internally. Refer to that function for more information.
+ *
+ * If an Counter registered with this function needs to be unregistered
+ * separately, devm_counter_unregister must be used.
+ *
+ * RETURNS:
+ * 0 on success, negative error number on failure.
+ */
+int devm_counter_register(struct device *dev,
+			  struct counter_device *const counter)
+{
+	struct counter_device **ptr;
+	int ret;
+
+	ptr = devres_alloc(devm_counter_unreg, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return -ENOMEM;
+
+	ret = counter_register(counter);
+	if (!ret) {
+		*ptr = counter;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL(devm_counter_register);
+
+static int devm_counter_match(struct device *dev, void *res, void *data)
+{
+	struct counter_device **r = res;
+
+	if (!r || !*r) {
+		WARN_ON(!r || !*r);
+		return 0;
+	}
+
+	return *r == data;
+}
+
+/**
+ * devm_counter_unregister - Resource-managed counter_unregister
+ * @dev:	device this counter_device belongs to
+ * @counter:	pointer to Counter associated with the device
+ *
+ * Unregister Counter registered with devm_counter_register.
+ */
+void devm_counter_unregister(struct device *dev,
+			     struct counter_device *const counter)
+{
+	int rc;
+
+	rc = devres_release(dev, devm_counter_unreg, devm_counter_match,
+			    counter);
+	WARN_ON(rc);
+}
+EXPORT_SYMBOL(devm_counter_unregister);
+
+static int __init counter_init(void)
+{
+	return bus_register(&counter_bus_type);
+}
+
+static void __exit counter_exit(void)
+{
+	bus_unregister(&counter_bus_type);
+}
+
+subsys_initcall(counter_init);
+module_exit(counter_exit);
+
+MODULE_AUTHOR("William Breathitt Gray <vilhelm.gray@gmail.com>");
+MODULE_DESCRIPTION("Generic Counter interface");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/counter.h b/include/linux/counter.h
new file mode 100644
index 000000000000..88fc82ee30a7
--- /dev/null
+++ b/include/linux/counter.h
@@ -0,0 +1,534 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Counter interface
+ * Copyright (C) 2017 William Breathitt Gray
+ */
+#ifndef _COUNTER_H_
+#define _COUNTER_H_
+
+#include <linux/device.h>
+#include <linux/types.h>
+
+enum count_direction {
+	COUNT_DIRECTION_FORWARD = 0,
+	COUNT_DIRECTION_BACKWARD
+};
+extern const char *const count_direction_str[2];
+
+enum count_mode {
+	COUNT_MODE_NORMAL = 0,
+	COUNT_MODE_RANGE_LIMIT,
+	COUNT_MODE_NON_RECYCLE,
+	COUNT_MODE_MODULO_N
+};
+extern const char *const count_mode_str[4];
+
+struct counter_device;
+struct counter_signal;
+
+/**
+ * struct counter_signal_ext - Counter Signal extensions
+ * @name:	attribute name
+ * @read:	read callback for this attribute; may be NULL
+ * @write:	write callback for this attribute; may be NULL
+ * @priv:	data private to the driver
+ */
+struct counter_signal_ext {
+	const char *name;
+	ssize_t (*read)(struct counter_device *counter,
+			struct counter_signal *signal, void *priv, char *buf);
+	ssize_t (*write)(struct counter_device *counter,
+			 struct counter_signal *signal, void *priv,
+			 const char *buf, size_t len);
+	void *priv;
+};
+
+/**
+ * struct counter_signal - Counter Signal node
+ * @id:		unique ID used to identify signal
+ * @name:	device-specific Signal name; ideally, this should match the name
+ *		as it appears in the datasheet documentation
+ * @ext:	optional array of Counter Signal extensions
+ * @num_ext:	number of Counter Signal extensions specified in @ext
+ * @priv:	optional private data supplied by driver
+ */
+struct counter_signal {
+	int id;
+	const char *name;
+
+	const struct counter_signal_ext *ext;
+	size_t num_ext;
+
+	void *priv;
+};
+
+/**
+ * struct counter_signal_enum_ext - Signal enum extension attribute
+ * @items:	Array of strings
+ * @num_items:	Number of items specified in @items
+ * @set:	Set callback function; may be NULL
+ * @get:	Get callback function; may be NULL
+ *
+ * The counter_signal_enum_ext structure can be used to implement enum style
+ * Signal extension attributes. Enum style attributes are those which have a set
+ * of strings that map to unsigned integer values. The Generic Counter Signal
+ * enum extension helper code takes care of mapping between value and string, as
+ * well as generating a "_available" file which contains a list of all available
+ * items. The get callback is used to query the currently active item; the index
+ * of the item within the respective items array is returned via the 'item'
+ * parameter. The set callback is called when the attribute is updated; the
+ * 'item' parameter contains the index of the newly activated item within the
+ * respective items array.
+ */
+struct counter_signal_enum_ext {
+	const char * const *items;
+	size_t num_items;
+	int (*get)(struct counter_device *counter,
+		   struct counter_signal *signal, size_t *item);
+	int (*set)(struct counter_device *counter,
+		   struct counter_signal *signal, size_t item);
+};
+
+ssize_t counter_signal_enum_read(struct counter_device *counter,
+				 struct counter_signal *signal, void *priv,
+				 char *buf);
+ssize_t counter_signal_enum_write(struct counter_device *counter,
+				  struct counter_signal *signal, void *priv,
+				  const char *buf, size_t len);
+
+/**
+ * COUNTER_SIGNAL_ENUM() - Initialize Signal enum extension
+ * @_name:	Attribute name
+ * @_e:		Pointer to a counter_count_enum structure
+ *
+ * This should usually be used together with COUNTER_SIGNAL_ENUM_AVAILABLE()
+ */
+#define COUNTER_SIGNAL_ENUM(_name, _e) \
+{ \
+	.name = (_name), \
+	.read = counter_signal_enum_read, \
+	.write = counter_signal_enum_write, \
+	.priv = (_e) \
+}
+
+ssize_t counter_signal_enum_available_read(struct counter_device *counter,
+					   struct counter_signal *signal,
+					   void *priv, char *buf);
+
+/**
+ * COUNTER_SIGNAL_ENUM_AVAILABLE() - Initialize Signal enum available extension
+ * @_name:	Attribute name ("_available" will be appended to the name)
+ * @_e:		Pointer to a counter_signal_enum structure
+ *
+ * Creates a read only attribute that lists all the available enum items in a
+ * newline separated list. This should usually be used together with
+ * COUNTER_SIGNAL_ENUM()
+ */
+#define COUNTER_SIGNAL_ENUM_AVAILABLE(_name, _e) \
+{ \
+	.name = (_name "_available"), \
+	.read = counter_signal_enum_available_read, \
+	.priv = (_e) \
+}
+
+enum synapse_action {
+	SYNAPSE_ACTION_NONE = 0,
+	SYNAPSE_ACTION_RISING_EDGE,
+	SYNAPSE_ACTION_FALLING_EDGE,
+	SYNAPSE_ACTION_BOTH_EDGES
+};
+
+/**
+ * struct counter_synapse - Counter Synapse node
+ * @action:		index of current action mode
+ * @actions_list:	array of available action modes
+ * @num_actions:	number of action modes specified in @actions_list
+ * @signal:		pointer to associated signal
+ */
+struct counter_synapse {
+	size_t action;
+	const enum synapse_action *actions_list;
+	size_t num_actions;
+
+	struct counter_signal *signal;
+};
+
+struct counter_count;
+
+/**
+ * struct counter_count_ext - Counter Count extension
+ * @name:	attribute name
+ * @read:	read callback for this attribute; may be NULL
+ * @write:	write callback for this attribute; may be NULL
+ * @priv:	data private to the driver
+ */
+struct counter_count_ext {
+	const char *name;
+	ssize_t (*read)(struct counter_device *counter,
+			struct counter_count *count, void *priv, char *buf);
+	ssize_t (*write)(struct counter_device *counter,
+			 struct counter_count *count, void *priv,
+			 const char *buf, size_t len);
+	void *priv;
+};
+
+enum count_function {
+	COUNT_FUNCTION_INCREASE = 0,
+	COUNT_FUNCTION_DECREASE,
+	COUNT_FUNCTION_PULSE_DIRECTION,
+	COUNT_FUNCTION_QUADRATURE_X1_A,
+	COUNT_FUNCTION_QUADRATURE_X1_B,
+	COUNT_FUNCTION_QUADRATURE_X2_A,
+	COUNT_FUNCTION_QUADRATURE_X2_B,
+	COUNT_FUNCTION_QUADRATURE_X4
+};
+
+/**
+ * struct counter_count - Counter Count node
+ * @id:			unique ID used to identify Count
+ * @name:		device-specific Count name; ideally, this should match
+ *			the name as it appears in the datasheet documentation
+ * @function:		index of current function mode
+ * @functions_list:	array available function modes
+ * @num_functions:	number of function modes specified in @functions_list
+ * @synapses:		array of synapses for initialization
+ * @num_synapses:	number of synapses specified in @synapses
+ * @ext:		optional array of Counter Count extensions
+ * @num_ext:		number of Counter Count extensions specified in @ext
+ * @priv:		optional private data supplied by driver
+ */
+struct counter_count {
+	int id;
+	const char *name;
+
+	size_t function;
+	const enum count_function *functions_list;
+	size_t num_functions;
+
+	struct counter_synapse *synapses;
+	size_t num_synapses;
+
+	const struct counter_count_ext *ext;
+	size_t num_ext;
+
+	void *priv;
+};
+
+/**
+ * struct counter_count_enum_ext - Count enum extension attribute
+ * @items:	Array of strings
+ * @num_items:	Number of items specified in @items
+ * @set:	Set callback function; may be NULL
+ * @get:	Get callback function; may be NULL
+ *
+ * The counter_count_enum_ext structure can be used to implement enum style
+ * Count extension attributes. Enum style attributes are those which have a set
+ * of strings that map to unsigned integer values. The Generic Counter Count
+ * enum extension helper code takes care of mapping between value and string, as
+ * well as generating a "_available" file which contains a list of all available
+ * items. The get callback is used to query the currently active item; the index
+ * of the item within the respective items array is returned via the 'item'
+ * parameter. The set callback is called when the attribute is updated; the
+ * 'item' parameter contains the index of the newly activated item within the
+ * respective items array.
+ */
+struct counter_count_enum_ext {
+	const char * const *items;
+	size_t num_items;
+	int (*get)(struct counter_device *counter, struct counter_count *count,
+		   size_t *item);
+	int (*set)(struct counter_device *counter, struct counter_count *count,
+		   size_t item);
+};
+
+ssize_t counter_count_enum_read(struct counter_device *counter,
+				struct counter_count *count, void *priv,
+				char *buf);
+ssize_t counter_count_enum_write(struct counter_device *counter,
+				 struct counter_count *count, void *priv,
+				 const char *buf, size_t len);
+
+/**
+ * COUNTER_COUNT_ENUM() - Initialize Count enum extension
+ * @_name:	Attribute name
+ * @_e:		Pointer to a counter_count_enum structure
+ *
+ * This should usually be used together with COUNTER_COUNT_ENUM_AVAILABLE()
+ */
+#define COUNTER_COUNT_ENUM(_name, _e) \
+{ \
+	.name = (_name), \
+	.read = counter_count_enum_read, \
+	.write = counter_count_enum_write, \
+	.priv = (_e) \
+}
+
+ssize_t counter_count_enum_available_read(struct counter_device *counter,
+					  struct counter_count *count,
+					  void *priv, char *buf);
+
+/**
+ * COUNTER_COUNT_ENUM_AVAILABLE() - Initialize Count enum available extension
+ * @_name:	Attribute name ("_available" will be appended to the name)
+ * @_e:		Pointer to a counter_count_enum structure
+ *
+ * Creates a read only attribute that lists all the available enum items in a
+ * newline separated list. This should usually be used together with
+ * COUNTER_COUNT_ENUM()
+ */
+#define COUNTER_COUNT_ENUM_AVAILABLE(_name, _e) \
+{ \
+	.name = (_name "_available"), \
+	.read = counter_count_enum_available_read, \
+	.priv = (_e) \
+}
+
+/**
+ * struct counter_device_attr_group - internal container for attribute group
+ * @attr_group:	Counter sysfs attributes group
+ * @attr_list:	list to keep track of created Counter sysfs attributes
+ * @num_attr:	number of Counter sysfs attributes
+ */
+struct counter_device_attr_group {
+	struct attribute_group attr_group;
+	struct list_head attr_list;
+	size_t num_attr;
+};
+
+/**
+ * struct counter_device_state - internal state container for a Counter device
+ * @id:			unique ID used to identify the Counter
+ * @dev:		internal device structure
+ * @groups_list:	attribute groups list (for Signals, Counts, and ext)
+ * @num_groups:		number of attribute groups containers
+ * @groups:		Counter sysfs attribute groups (to populate @dev.groups)
+ */
+struct counter_device_state {
+	int id;
+	struct device dev;
+	struct counter_device_attr_group *groups_list;
+	size_t num_groups;
+	const struct attribute_group **groups;
+};
+
+/**
+ * struct signal_read_value - Opaque Signal read value
+ * @buf:	string representation of Signal read value
+ * @len:	length of string in @buf
+ */
+struct signal_read_value {
+	char *buf;
+	size_t len;
+};
+
+/**
+ * struct count_read_value - Opaque Count read value
+ * @buf:	string representation of Count read value
+ * @len:	length of string in @buf
+ */
+struct count_read_value {
+	char *buf;
+	size_t len;
+};
+
+/**
+ * struct count_write_value - Opaque Count write value
+ * @buf:	string representation of Count write value
+ */
+struct count_write_value {
+	const char *buf;
+};
+
+/**
+ * struct counter_ops - Callbacks from driver
+ * @signal_read:	optional read callback for Signal attribute. The read
+ *			value of the respective Signal should be passed back via
+ *			the val parameter. val points to an opaque type which
+ *			should be set only by calling the signal_read_value_set
+ *			function from within the signal_read callback.
+ * @count_read:		optional read callback for Count attribute. The read
+ *			value of the respective Count should be passed back via
+ *			the val parameter. val points to an opaque type which
+ *			should be set only by calling the count_read_value_set
+ *			function from within the count_read callback.
+ * @count_write:	optional write callback for Count attribute. The write
+ *			value for the respective Count is passed in via the val
+ *			parameter. val points to an opaque type which should be
+ *			accessed only by calling the count_write_value_get
+ *			function.
+ * @function_get:	function to get the current count function mode. Returns
+ *			0 on success and negative error code on error. The index
+ *			of the respective Count's returned function mode should
+ *			be passed back via the function parameter.
+ * @function_set:	function to set the count function mode. function is the
+ *			index of the requested function mode from the respective
+ *			Count's functions_list array.
+ * @action_get:		function to get the current action mode. Returns 0 on
+ *			success and negative error code on error. The index of
+ *			the respective Signal's returned action mode should be
+ *			passed back via the action parameter.
+ * @action_set:		function to set the action mode. action is the index of
+ *			the requested action mode from the respective Synapse's
+ *			actions_list array.
+ */
+struct counter_ops {
+	int (*signal_read)(struct counter_device *counter,
+			   struct counter_signal *signal,
+			   struct signal_read_value *val);
+	int (*count_read)(struct counter_device *counter,
+			  struct counter_count *count,
+			  struct count_read_value *val);
+	int (*count_write)(struct counter_device *counter,
+			   struct counter_count *count,
+			   struct count_write_value *val);
+	int (*function_get)(struct counter_device *counter,
+			    struct counter_count *count, size_t *function);
+	int (*function_set)(struct counter_device *counter,
+			    struct counter_count *count, size_t function);
+	int (*action_get)(struct counter_device *counter,
+			  struct counter_count *count,
+			  struct counter_synapse *synapse, size_t *action);
+	int (*action_set)(struct counter_device *counter,
+			  struct counter_count *count,
+			  struct counter_synapse *synapse, size_t action);
+};
+
+/**
+ * struct counter_device_ext - Counter device extension
+ * @name:	attribute name
+ * @read:	read callback for this attribute; may be NULL
+ * @write:	write callback for this attribute; may be NULL
+ * @priv:	data private to the driver
+ */
+struct counter_device_ext {
+	const char *name;
+	ssize_t (*read)(struct counter_device *counter, void *priv, char *buf);
+	ssize_t (*write)(struct counter_device *counter, void *priv,
+			 const char *buf, size_t len);
+	void *priv;
+};
+
+/**
+ * struct counter_device_enum_ext - Counter enum extension attribute
+ * @items:	Array of strings
+ * @num_items:	Number of items specified in @items
+ * @set:	Set callback function; may be NULL
+ * @get:	Get callback function; may be NULL
+ *
+ * The counter_device_enum_ext structure can be used to implement enum style
+ * Counter extension attributes. Enum style attributes are those which have a
+ * set of strings that map to unsigned integer values. The Generic Counter enum
+ * extension helper code takes care of mapping between value and string, as well
+ * as generating a "_available" file which contains a list of all available
+ * items. The get callback is used to query the currently active item; the index
+ * of the item within the respective items array is returned via the 'item'
+ * parameter. The set callback is called when the attribute is updated; the
+ * 'item' parameter contains the index of the newly activated item within the
+ * respective items array.
+ */
+struct counter_device_enum_ext {
+	const char * const *items;
+	size_t num_items;
+	int (*get)(struct counter_device *counter, size_t *item);
+	int (*set)(struct counter_device *counter, size_t item);
+};
+
+ssize_t counter_device_enum_read(struct counter_device *counter, void *priv,
+				 char *buf);
+ssize_t counter_device_enum_write(struct counter_device *counter, void *priv,
+				  const char *buf, size_t len);
+
+/**
+ * COUNTER_DEVICE_ENUM() - Initialize Counter enum extension
+ * @_name:	Attribute name
+ * @_e:		Pointer to a counter_device_enum structure
+ *
+ * This should usually be used together with COUNTER_DEVICE_ENUM_AVAILABLE()
+ */
+#define COUNTER_DEVICE_ENUM(_name, _e) \
+{ \
+	.name = (_name), \
+	.read = counter_device_enum_read, \
+	.write = counter_device_enum_write, \
+	.priv = (_e) \
+}
+
+ssize_t counter_device_enum_available_read(struct counter_device *counter,
+					   void *priv, char *buf);
+
+/**
+ * COUNTER_DEVICE_ENUM_AVAILABLE() - Initialize Counter enum available extension
+ * @_name:	Attribute name ("_available" will be appended to the name)
+ * @_e:		Pointer to a counter_device_enum structure
+ *
+ * Creates a read only attribute that lists all the available enum items in a
+ * newline separated list. This should usually be used together with
+ * COUNTER_DEVICE_ENUM()
+ */
+#define COUNTER_DEVICE_ENUM_AVAILABLE(_name, _e) \
+{ \
+	.name = (_name "_available"), \
+	.read = counter_device_enum_available_read, \
+	.priv = (_e) \
+}
+
+/**
+ * struct counter_device - Counter data structure
+ * @name:		name of the device as it appears in the datasheet
+ * @parent:		optional parent device providing the counters
+ * @device_state:	internal device state container
+ * @ops:		callbacks from driver
+ * @signals:		array of Signals
+ * @num_signals:	number of Signals specified in @signals
+ * @counts:		array of Counts
+ * @num_counts:		number of Counts specified in @counts
+ * @ext:		optional array of Counter device extensions
+ * @num_ext:		number of Counter device extensions specified in @ext
+ * @priv:		optional private data supplied by driver
+ */
+struct counter_device {
+	const char *name;
+	struct device *parent;
+	struct counter_device_state *device_state;
+
+	const struct counter_ops *ops;
+
+	struct counter_signal *signals;
+	size_t num_signals;
+	struct counter_count *counts;
+	size_t num_counts;
+
+	const struct counter_device_ext *ext;
+	size_t num_ext;
+
+	void *priv;
+};
+
+enum signal_level {
+	SIGNAL_LEVEL_LOW = 0,
+	SIGNAL_LEVEL_HIGH
+};
+
+enum signal_value_type {
+	SIGNAL_LEVEL = 0
+};
+
+enum count_value_type {
+	COUNT_POSITION = 0,
+};
+
+void signal_read_value_set(struct signal_read_value *const val,
+			   const enum signal_value_type type, void *const data);
+void count_read_value_set(struct count_read_value *const val,
+			  const enum count_value_type type, void *const data);
+int count_write_value_get(void *const data, const enum count_value_type type,
+			  const struct count_write_value *const val);
+
+int counter_register(struct counter_device *const counter);
+void counter_unregister(struct counter_device *const counter);
+int devm_counter_register(struct device *dev,
+			  struct counter_device *const counter);
+void devm_counter_unregister(struct device *dev,
+			     struct counter_device *const counter);
+
+#endif /* _COUNTER_H_ */
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 02/10] counter: Documentation: Add Generic Counter sysfs documentation
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
  2018-06-21 21:07 ` [PATCH v7 01/10] counter: Introduce the Generic Counter interface William Breathitt Gray
@ 2018-06-21 21:07 ` William Breathitt Gray
  2018-07-02 19:11   ` [v7, " David Lechner
  2018-06-21 21:07 ` [PATCH v7 03/10] docs: Add Generic Counter interface documentation William Breathitt Gray
                   ` (9 subsequent siblings)
  11 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:07 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

This patch adds standard documentation for the userspace sysfs
attributes of the Generic Counter interface.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-counter | 230 ++++++++++++++++++++
 MAINTAINERS                                 |   1 +
 2 files changed, 231 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-counter

diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter
new file mode 100644
index 000000000000..0bb0dce67bf8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-counter
@@ -0,0 +1,230 @@
+What:		/sys/bus/counter/devices/counterX/countY/count
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Count data of Count Y represented as a string.
+
+What:		/sys/bus/counter/devices/counterX/countY/ceiling
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Count value ceiling for Count Y. This is the upper limit for the
+		respective counter.
+
+What:		/sys/bus/counter/devices/counterX/countY/floor
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Count value floor for Count Y. This is the lower limit for the
+		respective counter.
+
+What:		/sys/bus/counter/devices/counterX/countY/count_mode
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Count mode for channel Y. The ceiling and floor values for
+		Count Y are used by the count mode where required. The following
+		count modes are available:
+
+		Normal:
+			Counting is continuous in either direction.
+
+		Range Limit:
+			An upper or lower limit is set, mimicking limit switches
+			in the mechanical counterpart. The upper limit is set to
+			the Count Y ceiling value, while the lower limit is set
+			to the Count Y floor value. The counter freezes at
+			count = ceiling when counting up, and at count = floor
+			when counting down. At either of these limits, the
+			counting is resumed only when the count direction is
+			reversed.
+
+		Non-Recycle:
+			The counter is disabled whenever a counter overflow or
+			underflow takes place. The counter is re-enabled when a
+			new count value is loaded to the counter via a preset
+			operation or direct write.
+
+		Modulo-N:
+			A count value boundary is set between the Count Y floor
+			value and the Count Y ceiling value. The counter is
+			reset to the Cunt Y floor value at count = ceiling when
+			counting up, while the counter is set to the Count Y
+			ceiling value at count = floor when counting down; the
+			counter does not freeze at the boundary points, but
+			counts continuously throughout.
+
+What:		/sys/bus/counter/devices/counterX/countY/count_mode_available
+What:		/sys/bus/counter/devices/counterX/countY/error_noise_available
+What:		/sys/bus/counter/devices/counterX/countY/function_available
+What:		/sys/bus/counter/devices/counterX/countY/signalZ_action_available
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Discrete set of available values for the respective Count Y
+		configuration are listed in this file. Values are delineated by
+		newline characters.
+
+What:		/sys/bus/counter/devices/counterX/countY/direction
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute that indicates the count direction of Count
+		Y. Two count directions are available: forward and backward.
+
+		Some counter devices are able to determine the direction of
+		their counting. For example, quadrature encoding counters can
+		determine the direction of movement by evaluating the leading
+		phase of the respective A and B quadrature encoding signals.
+		This attribute exposes such count directions.
+
+What:		/sys/bus/counter/devices/counterX/countY/enable
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Whether channel Y counter is enabled. Valid attribute values are
+		boolean.
+
+		This attribute is intended to serve as a pause/unpause mechanism
+		for Count Y. Suppose a counter device is used to count the total
+		movement of a conveyor belt: this attribute allows an operator
+		to temporarily pause the counter, service the conveyor belt,
+		and then finally unpause the counter to continue where it had
+		left off.
+
+What:		/sys/bus/counter/devices/counterX/countY/error_noise
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute that indicates whether excessive noise is
+		present at the channel Y counter inputs.
+
+What:		/sys/bus/counter/devices/counterX/countY/function
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Count function mode of Count Y; count function evaluation is
+		triggered by conditions specified by the Count Y signalZ_action
+		attributes. The following count functions are available:
+
+		Increase:
+			Accumulated count is incremented.
+
+		Decrease:
+			Accumulated count is decremented.
+
+		Pulse-Direction:
+			Rising edges on signal A updates the respective count.
+			The input level of signal B determines direction.
+
+		Quadrature x1 A:
+			If direction is forward, rising edges on quadrature pair
+			signal A updates the respective count; if the direction
+			is backward, falling edges on quadrature pair signal A
+			updates the respective count. Quadrature encoding
+			determines the direction.
+
+		Quadrature x1 B:
+			If direction is forward, rising edges on quadrature pair
+			signal B updates the respective count; if the direction
+			is backward, falling edges on quadrature pair signal B
+			updates the respective count. Quadrature encoding
+			determines the direction.
+
+		Quadrature x2 A:
+			Any state transition on quadrature pair signal A updates
+			the respective count. Quadrature encoding determines the
+			direction.
+
+		Quadrature x2 B:
+			Any state transition on quadrature pair signal B updates
+			the respective count. Quadrature encoding determines the
+			direction.
+
+		Quadrature x4:
+			Any state transition on either quadrature pair signals
+			updates	the respective count. Quadrature encoding
+			determines the direction.
+
+What:		/sys/bus/counter/devices/counterX/countY/name
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute that indicates the device-specific name of
+		Count Y. If possible, this should match the name of the
+		respective channel as it appears in the device datasheet.
+
+What:		/sys/bus/counter/devices/counterX/countY/preset
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		If the counter device supports preset registers -- registers
+		used to load counter channels to a set count upon device-defined
+		preset operation trigger events -- the preset count for channel
+		Y is provided by this attribute.
+
+What:		/sys/bus/counter/devices/counterX/countY/preset_enable
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Whether channel Y counter preset operation is enabled. Valid
+		attribute values are boolean.
+
+What:		/sys/bus/counter/devices/counterX/countY/signalZ_action
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Action mode of Count Y for Signal Z. This attribute indicates
+		the condition of Signal Z that triggers the count function
+		evaluation for Count Y. The following action modes are
+		available:
+
+		None:
+			Signal does not trigger the count function. In
+			Pulse-Direction count function mode, this Signal is
+			evaluated as Direction.
+
+		Rising Edge:
+			Low state transitions to high state.
+
+		Falling Edge:
+			High state transitions to low state.
+
+		Both Edges:
+			Any state transition.
+
+What:		/sys/bus/counter/devices/counterX/name
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute that indicates the device-specific name of
+		the Counter. This should match the name of the device as it
+		appears in its respective datasheet.
+
+What:		/sys/bus/counter/devices/counterX/num_counts
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute that indicates the total number of Counts
+		belonging to the Counter.
+
+What:		/sys/bus/counter/devices/counterX/num_signals
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute that indicates the total number of Signals
+		belonging to the Counter.
+
+What:		/sys/bus/counter/devices/counterX/signalY/signal
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Signal data of Signal Y represented as a string.
+
+What:		/sys/bus/counter/devices/counterX/signalY/name
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Read-only attribute that indicates the device-specific name of
+		Signal Y. If possible, this should match the name of the
+		respective signal as it appears in the device datasheet.
diff --git a/MAINTAINERS b/MAINTAINERS
index f6e995c142ed..f8a47fd197a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3692,6 +3692,7 @@ COUNTER SUBSYSTEM
 M:	William Breathitt Gray <vilhelm.gray@gmail.com>
 L:	linux-iio@vger.kernel.org
 S:	Maintained
+F:	Documentation/ABI/testing/sysfs-bus-counter*
 F:	drivers/counter/
 F:	include/linux/counter.h
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 03/10] docs: Add Generic Counter interface documentation
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
  2018-06-21 21:07 ` [PATCH v7 01/10] counter: Introduce the Generic Counter interface William Breathitt Gray
  2018-06-21 21:07 ` [PATCH v7 02/10] counter: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
@ 2018-06-21 21:07 ` William Breathitt Gray
  2018-06-22 16:51   ` Jonathan Cameron
                     ` (2 more replies)
  2018-06-21 21:07 ` [PATCH v7 04/10] counter: 104-quad-8: Add Generic Counter interface support William Breathitt Gray
                   ` (8 subsequent siblings)
  11 siblings, 3 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:07 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

This patch adds high-level documentation about the Generic Counter
interface.

Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 Documentation/driver-api/generic-counter.rst | 342 +++++++++++++++++++
 Documentation/driver-api/index.rst           |   1 +
 MAINTAINERS                                  |   1 +
 3 files changed, 344 insertions(+)
 create mode 100644 Documentation/driver-api/generic-counter.rst

diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
new file mode 100644
index 000000000000..f51db893f595
--- /dev/null
+++ b/Documentation/driver-api/generic-counter.rst
@@ -0,0 +1,342 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================
+Generic Counter Interface
+=========================
+
+Introduction
+============
+
+Counter devices are prevalent within a diverse spectrum of industries.
+The ubiquitous presence of these devices necessitates a common interface
+and standard of interaction and exposure. This driver API attempts to
+resolve the issue of duplicate code found among existing counter device
+drivers by introducing a generic counter interface for consumption. The
+Generic Counter interface enables drivers to support and expose a common
+set of components and functionality present in counter devices.
+
+Theory
+======
+
+Counter devices can vary greatly in design, but regardless of whether
+some devices are quadrature encoder counters or tally counters, all
+counter devices consist of a core set of components. This core set of
+components, shared by all counter devices, is what forms the essence of
+the Generic Counter interface.
+
+There are three core components to a counter:
+
+* Count:
+  Count data for a set of Signals.
+
+* Signal:
+  Input data that is evaluated by the counter to determine the count
+  data.
+
+* Synapse:
+  The association of a Signal with a respective Count.
+
+COUNT
+-----
+A Count represents the count data for a set of Signals. The Generic
+Counter interface provides the following available count data types:
+
+* COUNT_POSITION:
+  Unsigned integer value representing position.
+
+A Count has a count function mode which represents the update behavior
+for the count data. The Generic Counter interface provides the following
+available count function modes:
+
+* Increase:
+  Accumulated count is incremented.
+
+* Decrease:
+  Accumulated count is decremented.
+
+* Pulse-Direction:
+  Rising edges on signal A updates the respective count. The input level
+  of signal B determines direction.
+
+* Quadrature:
+  A pair of quadrature encoding signals are evaluated to determine
+  position and direction. The following Quadrature modes are available:
+
+  - x1 A:
+    If direction is forward, rising edges on quadrature pair signal A
+    updates the respective count; if the direction is backward, falling
+    edges on quadrature pair signal A updates the respective count.
+    Quadrature encoding determines the direction.
+
+  - x1 B:
+    If direction is forward, rising edges on quadrature pair signal B
+    updates the respective count; if the direction is backward, falling
+    edges on quadrature pair signal B updates the respective count.
+    Quadrature encoding determines the direction.
+
+  - x2 A:
+    Any state transition on quadrature pair signal A updates the
+    respective count. Quadrature encoding determines the direction.
+
+  - x2 B:
+    Any state transition on quadrature pair signal B updates the
+    respective count. Quadrature encoding determines the direction.
+
+  - x4:
+    Any state transition on either quadrature pair signals updates the
+    respective count. Quadrature encoding determines the direction.
+
+A Count has a set of one or more associated Signals.
+
+SIGNAL
+------
+A Signal represents a counter input data; this is the input data that is
+evaluated by the counter to determine the count data; e.g. a quadrature
+signal output line of a rotary encoder. Not all counter devices provide
+user access to the Signal data.
+
+The Generic Counter interface provides the following available signal
+data types for when the Signal data is available for user access:
+
+* SIGNAL_LEVEL:
+  Signal line state level. The following states are possible:
+
+  - SIGNAL_LEVEL_LOW:
+    Signal line is in a low state.
+
+  - SIGNAL_LEVEL_HIGH:
+    Signal line is in a high state.
+
+A Signal may be associated with one or more Counts.
+
+SYNAPSE
+-------
+A Synapse represents the association of a Signal with a respective
+Count. Signal data affects respective Count data, and the Synapse
+represents this relationship.
+
+The Synapse action mode specifies the Signal data condition which
+triggers the respective Count's count function evaluation to update the
+count data. The Generic Counter interface provides the following
+available action modes:
+
+* None:
+  Signal does not trigger the count function. In Pulse-Direction count
+  function mode, this Signal is evaluated as Direction.
+
+* Rising Edge:
+  Low state transitions to high state.
+
+* Falling Edge:
+  High state transitions to low state.
+
+* Both Edges:
+  Any state transition.
+
+A counter is defined as a set of input signals associated with count
+data that are generated by the evaluation of the state of the associated
+input signals as defined by the respective count functions. Within the
+context of the Generic Counter interface, a counter consists of Counts
+each associated with a set of Signals, whose respective Synapse
+instances represent the count function update conditions for the
+associated Counts.
+
+Paradigm
+========
+
+The most basic counter device may be expressed as a single Count
+associated with a single Signal via a single Synapse. Take for example
+a counter device which simply accumulates a count of rising edges on a
+source input line::
+
+                Count                Synapse        Signal
+                -----                -------        ------
+        +---------------------+
+        | Data: Count         |    Rising Edge     ________
+        | Function: Increase  |  <-------------   / Source \
+        |                     |                  ____________
+        +---------------------+
+
+In this example, the Signal is a source input line with a pulsing
+voltage, while the Count is a persistent count value which is repeatedly
+incremented. The Signal is associated with the respective Count via a
+Synapse. The increase function is triggered by the Signal data condition
+specified by the Synapse -- in this case a rising edge condition on the
+voltage input line. In summary, the counter device existence and
+behavior is aptly represented by respective Count, Signal, and Synapse
+components: a rising edge condition triggers an increase function on an
+accumulating count datum.
+
+A counter device is not limited to a single Signal; in fact, in theory
+many Signals may be associated with even a single Count. For example, a
+quadrature encoder counter device can keep track of position based on
+the states of two input lines::
+
+                   Count                 Synapse     Signal
+                   -----                 -------     ------
+        +-------------------------+
+        | Data: Position          |    Both Edges     ___
+        | Function: Quadrature x4 |  <------------   / A \
+        |                         |                 _______
+        |                         |
+        |                         |    Both Edges     ___
+        |                         |  <------------   / B \
+        |                         |                 _______
+        +-------------------------+
+
+In this example, two Signals (quadrature encoder lines A and B) are
+associated with a single Count: a rising or falling edge on either A or
+B triggers the "Quadrature x4" function which determines the direction
+of movement and updates the respective position data. The "Quadrature
+x4" function is likely implemented in the hardware of the quadrature
+encoder counter device; the Count, Signals, and Synapses simply
+represent this hardware behavior and functionality.
+
+Signals associated with the same Count can have differing Synapse action
+mode conditions. For example, a quadrature encoder counter device
+operating in a non-quadrature Pulse-Direction mode could have one input
+line dedicated for movement and a second input line dedicated for
+direction::
+
+                   Count                   Synapse      Signal
+                   -----                   -------      ------
+        +---------------------------+
+        | Data: Position            |    Rising Edge     ___
+        | Function: Pulse-Direction |  <-------------   / A \ (Movement)
+        |                           |                  _______
+        |                           |
+        |                           |       None         ___
+        |                           |  <-------------   / B \ (Direction)
+        |                           |                  _______
+        +---------------------------+
+
+Only Signal A triggers the "Pulse-Direction" update function, but the
+instantaneous state of Signal B is still required in order to know the
+direction so that the position data may be properly updated. Ultimately,
+both Signals are associated with the same Count via two respective
+Synapses, but only one Synapse has an active action mode condition which
+triggers the respective count function while the other is left with a
+"None" condition action mode to indicate its respective Signal's
+availability for state evaluation despite its non-triggering mode.
+
+Keep in mind that the Signal, Synapse, and Count are abstract
+representations which do not need to be closely married to their
+respective physical sources. This allows the user of a counter to
+divorce themselves from the nuances of physical components (such as
+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/sys-bus-counter-generic-sysfs 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
+==========
+
+Driver authors may utilize the Generic Counter interface in their code
+by including the include/linux/counter.h header file. This header file
+provides several core data structures, function prototypes, and macros
+for defining a counter device.
+
+.. kernel-doc:: include/linux/counter.h
+   :internal:
+
+.. kernel-doc:: drivers/counter/generic-counter.c
+   :export:
+
+Implementation
+==============
+
+To support a counter device, a driver must first allocate the available
+Counter Signals via counter_signal structures. These Signals should
+be stored as an array and set to the signals array member of an
+allocated counter_device structure before the Counter is registered to
+the system.
+
+Counter Counts may be allocated via counter_count structures, and
+respective Counter Signal associations (Synapses) made via
+counter_synapse structures. Associated counter_synapse structures are
+stored as an array and set to the the synapses array member of the
+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.
+
+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 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.
+
+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/sys-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.
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index f4180e7c7ed5..e39a9fd3d8c9 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -52,6 +52,7 @@ available subsections can be seen below.
    slimbus
    soundwire/index
    fpga/index
+   generic-counter
 
 .. only::  subproject and html
 
diff --git a/MAINTAINERS b/MAINTAINERS
index f8a47fd197a1..c7fd36500635 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3693,6 +3693,7 @@ M:	William Breathitt Gray <vilhelm.gray@gmail.com>
 L:	linux-iio@vger.kernel.org
 S:	Maintained
 F:	Documentation/ABI/testing/sysfs-bus-counter*
+F:	Documentation/driver-api/generic-counter.rst
 F:	drivers/counter/
 F:	include/linux/counter.h
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 04/10] counter: 104-quad-8: Add Generic Counter interface support
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (2 preceding siblings ...)
  2018-06-21 21:07 ` [PATCH v7 03/10] docs: Add Generic Counter interface documentation William Breathitt Gray
@ 2018-06-21 21:07 ` William Breathitt Gray
  2018-06-22 16:57   ` Jonathan Cameron
  2018-06-21 21:08 ` [PATCH v7 05/10] counter: 104-quad-8: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
                   ` (7 subsequent siblings)
  11 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:07 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

This patch adds support for the Generic Counter interface to the
104-QUAD-8 driver. The existing 104-QUAD-8 device interface should not
be affected by this patch; all changes are intended as supplemental
additions as perceived by the user.

Generic Counter Counts are created for the eight quadrature channel
counts, as well as their respective quadrature A and B Signals (which
are associated via respective Synapse structures) and respective index
Signals.

The new Generic Counter interface sysfs attributes are intended to
expose the same functionality and data available via the existing
104-QUAD-8 IIO device interface; the Generic Counter interface serves
to provide the respective functionality and data in a standard way
expected of counter devices.

Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 MAINTAINERS                            |   4 +-
 drivers/{iio => }/counter/104-quad-8.c | 782 ++++++++++++++++++++++++-
 drivers/counter/Kconfig                |  21 +
 drivers/counter/Makefile               |   2 +
 drivers/iio/counter/Kconfig            |  17 -
 drivers/iio/counter/Makefile           |   1 -
 6 files changed, 784 insertions(+), 43 deletions(-)
 rename drivers/{iio => }/counter/104-quad-8.c (44%)

diff --git a/MAINTAINERS b/MAINTAINERS
index c7fd36500635..4083523699f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -266,12 +266,12 @@ L:	linux-gpio@vger.kernel.org
 S:	Maintained
 F:	drivers/gpio/gpio-104-idio-16.c
 
-ACCES 104-QUAD-8 IIO DRIVER
+ACCES 104-QUAD-8 DRIVER
 M:	William Breathitt Gray <vilhelm.gray@gmail.com>
 L:	linux-iio@vger.kernel.org
 S:	Maintained
 F:	Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
-F:	drivers/iio/counter/104-quad-8.c
+F:	drivers/counter/104-quad-8.c
 
 ACCES PCI-IDIO-16 GPIO DRIVER
 M:	William Breathitt Gray <vilhelm.gray@gmail.com>
diff --git a/drivers/iio/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
similarity index 44%
rename from drivers/iio/counter/104-quad-8.c
rename to drivers/counter/104-quad-8.c
index 92be8d0f7735..bbd1640f3a51 100644
--- a/drivers/iio/counter/104-quad-8.c
+++ b/drivers/counter/104-quad-8.c
@@ -1,19 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
- * IIO driver for the ACCES 104-QUAD-8
+ * Counter driver for the ACCES 104-QUAD-8
  * Copyright (C) 2016 William Breathitt Gray
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, version 2, as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
  * This driver supports the ACCES 104-QUAD-8 and ACCES 104-QUAD-4.
  */
 #include <linux/bitops.h>
+#include <linux/counter.h>
 #include <linux/device.h>
 #include <linux/errno.h>
 #include <linux/iio/iio.h>
@@ -37,6 +30,7 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
 
 /**
  * struct quad8_iio - IIO device private data structure
+ * @counter:		instance of the counter_device
  * @preset:		array of preset values
  * @count_mode:		array of count mode configurations
  * @quadrature_mode:	array of quadrature mode configurations
@@ -48,6 +42,7 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
  * @base:		base port address of the IIO device
  */
 struct quad8_iio {
+	struct counter_device counter;
 	unsigned int preset[QUAD8_NUM_COUNTERS];
 	unsigned int count_mode[QUAD8_NUM_COUNTERS];
 	unsigned int quadrature_mode[QUAD8_NUM_COUNTERS];
@@ -91,6 +86,10 @@ struct quad8_iio {
 #define QUAD8_RLD_CNTR_OUT 0x10
 #define QUAD8_CHAN_OP_ENABLE_COUNTERS 0x00
 #define QUAD8_CHAN_OP_RESET_COUNTERS 0x01
+#define QUAD8_CMR_QUADRATURE_X1 0x08
+#define QUAD8_CMR_QUADRATURE_X2 0x10
+#define QUAD8_CMR_QUADRATURE_X4 0x18
+
 
 static int quad8_read_raw(struct iio_dev *indio_dev,
 	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
@@ -346,13 +345,13 @@ static const char *const quad8_count_modes[] = {
 };
 
 static int quad8_set_count_mode(struct iio_dev *indio_dev,
-	const struct iio_chan_spec *chan, unsigned int count_mode)
+	const struct iio_chan_spec *chan, unsigned int cnt_mode)
 {
 	struct quad8_iio *const priv = iio_priv(indio_dev);
-	unsigned int mode_cfg = count_mode << 1;
+	unsigned int mode_cfg = cnt_mode << 1;
 	const int base_offset = priv->base + 2 * chan->channel + 1;
 
-	priv->count_mode[chan->channel] = count_mode;
+	priv->count_mode[chan->channel] = cnt_mode;
 
 	/* Add quadrature mode configuration */
 	if (priv->quadrature_mode[chan->channel])
@@ -562,24 +561,746 @@ static const struct iio_chan_spec quad8_channels[] = {
 	QUAD8_COUNT_CHAN(7), QUAD8_INDEX_CHAN(7)
 };
 
+static int quad8_signal_read(struct counter_device *counter,
+	struct counter_signal *signal, struct signal_read_value *val)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	unsigned int state;
+	enum signal_level level;
+
+	/* Only Index signal levels can be read */
+	if (signal->id < 16)
+		return -EINVAL;
+
+	state = inb(priv->base + QUAD8_REG_INDEX_INPUT_LEVELS)
+		& BIT(signal->id - 16);
+
+	level = (state) ? SIGNAL_LEVEL_HIGH : SIGNAL_LEVEL_LOW;
+
+	signal_read_value_set(val, SIGNAL_LEVEL, &level);
+
+	return 0;
+}
+
+static int quad8_count_read(struct counter_device *counter,
+	struct counter_count *count, struct count_read_value *val)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	const int base_offset = priv->base + 2 * count->id;
+	unsigned int flags;
+	unsigned int borrow;
+	unsigned int carry;
+	unsigned long position;
+	int i;
+
+	flags = inb(base_offset + 1);
+	borrow = flags & QUAD8_FLAG_BT;
+	carry = !!(flags & QUAD8_FLAG_CT);
+
+	/* Borrow XOR Carry effectively doubles count range */
+	position = (unsigned long)(borrow ^ carry) << 24;
+
+	/* Reset Byte Pointer; transfer Counter to Output Latch */
+	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_CNTR_OUT,
+	     base_offset + 1);
+
+	for (i = 0; i < 3; i++)
+		position |= (unsigned long)inb(base_offset) << (8 * i);
+
+	count_read_value_set(val, COUNT_POSITION, &position);
+
+	return 0;
+}
+
+static int quad8_count_write(struct counter_device *counter,
+	struct counter_count *count, struct count_write_value *val)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	const int base_offset = priv->base + 2 * count->id;
+	int err;
+	unsigned long position;
+	int i;
+
+	err = count_write_value_get(&position, COUNT_POSITION, val);
+	if (err)
+		return err;
+
+	/* Only 24-bit values are supported */
+	if (position > 0xFFFFFF)
+		return -EINVAL;
+
+	/* Reset Byte Pointer */
+	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
+
+	/* Counter can only be set via Preset Register */
+	for (i = 0; i < 3; i++)
+		outb(position >> (8 * i), base_offset);
+
+	/* Transfer Preset Register to Counter */
+	outb(QUAD8_CTR_RLD | QUAD8_RLD_PRESET_CNTR, base_offset + 1);
+
+	/* Reset Byte Pointer */
+	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
+
+	/* Set Preset Register back to original value */
+	position = priv->preset[count->id];
+	for (i = 0; i < 3; i++)
+		outb(position >> (8 * i), base_offset);
+
+	/* Reset Borrow, Carry, Compare, and Sign flags */
+	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_FLAGS, base_offset + 1);
+	/* Reset Error flag */
+	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_E, base_offset + 1);
+
+	return 0;
+}
+
+enum quad8_count_function {
+	QUAD8_COUNT_FUNCTION_PULSE_DIRECTION = 0,
+	QUAD8_COUNT_FUNCTION_QUADRATURE_X1,
+	QUAD8_COUNT_FUNCTION_QUADRATURE_X2,
+	QUAD8_COUNT_FUNCTION_QUADRATURE_X4
+};
+
+static enum count_function quad8_count_functions_list[] = {
+	[QUAD8_COUNT_FUNCTION_PULSE_DIRECTION] = COUNT_FUNCTION_PULSE_DIRECTION,
+	[QUAD8_COUNT_FUNCTION_QUADRATURE_X1] = COUNT_FUNCTION_QUADRATURE_X1_A,
+	[QUAD8_COUNT_FUNCTION_QUADRATURE_X2] = COUNT_FUNCTION_QUADRATURE_X2_A,
+	[QUAD8_COUNT_FUNCTION_QUADRATURE_X4] = COUNT_FUNCTION_QUADRATURE_X4
+};
+
+static int quad8_function_get(struct counter_device *counter,
+	struct counter_count *count, size_t *function)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	const int id = count->id;
+	const unsigned int quadrature_mode = priv->quadrature_mode[id];
+	const unsigned int scale = priv->quadrature_scale[id];
+
+	if (quadrature_mode)
+		switch (scale) {
+		case 0:
+			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X1;
+			break;
+		case 1:
+			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X2;
+			break;
+		case 2:
+			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X4;
+			break;
+		}
+	else
+		*function = QUAD8_COUNT_FUNCTION_PULSE_DIRECTION;
+
+	return 0;
+}
+
+static int quad8_function_set(struct counter_device *counter,
+	struct counter_count *count, size_t function)
+{
+	struct quad8_iio *const priv = counter->priv;
+	const int id = count->id;
+	unsigned int *const quadrature_mode = priv->quadrature_mode + id;
+	unsigned int *const scale = priv->quadrature_scale + id;
+	unsigned int mode_cfg = priv->count_mode[id] << 1;
+	unsigned int *const synchronous_mode = priv->synchronous_mode + id;
+	const unsigned int idr_cfg = priv->index_polarity[id] << 1;
+	const int base_offset = priv->base + 2 * id + 1;
+
+	if (function == QUAD8_COUNT_FUNCTION_PULSE_DIRECTION) {
+		*quadrature_mode = 0;
+
+		/* Quadrature scaling only available in quadrature mode */
+		*scale = 0;
+
+		/* Synchronous function not supported in non-quadrature mode */
+		if (*synchronous_mode) {
+			*synchronous_mode = 0;
+			/* Disable synchronous function mode */
+			outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
+		}
+	} else {
+		*quadrature_mode = 1;
+
+		switch (function) {
+		case QUAD8_COUNT_FUNCTION_QUADRATURE_X1:
+			*scale = 0;
+			mode_cfg |= QUAD8_CMR_QUADRATURE_X1;
+			break;
+		case QUAD8_COUNT_FUNCTION_QUADRATURE_X2:
+			*scale = 1;
+			mode_cfg |= QUAD8_CMR_QUADRATURE_X2;
+			break;
+		case QUAD8_COUNT_FUNCTION_QUADRATURE_X4:
+			*scale = 2;
+			mode_cfg |= QUAD8_CMR_QUADRATURE_X4;
+			break;
+		}
+	}
+
+	/* Load mode configuration to Counter Mode Register */
+	outb(QUAD8_CTR_CMR | mode_cfg, base_offset);
+
+	return 0;
+}
+
+static void quad8_direction_get(struct counter_device *counter,
+	struct counter_count *count, enum count_direction *direction)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	unsigned int ud_flag;
+	const unsigned int flag_addr = priv->base + 2 * count->id + 1;
+
+	/* U/D flag: nonzero = up, zero = down */
+	ud_flag = inb(flag_addr) & QUAD8_FLAG_UD;
+
+	*direction = (ud_flag) ? COUNT_DIRECTION_FORWARD :
+		COUNT_DIRECTION_BACKWARD;
+}
+
+enum quad8_synapse_action {
+	QUAD8_SYNAPSE_ACTION_NONE = 0,
+	QUAD8_SYNAPSE_ACTION_RISING_EDGE,
+	QUAD8_SYNAPSE_ACTION_FALLING_EDGE,
+	QUAD8_SYNAPSE_ACTION_BOTH_EDGES
+};
+
+static enum synapse_action quad8_index_actions_list[] = {
+	[QUAD8_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
+	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = SYNAPSE_ACTION_RISING_EDGE
+};
+
+static enum synapse_action quad8_synapse_actions_list[] = {
+	[QUAD8_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
+	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = SYNAPSE_ACTION_RISING_EDGE,
+	[QUAD8_SYNAPSE_ACTION_FALLING_EDGE] = SYNAPSE_ACTION_FALLING_EDGE,
+	[QUAD8_SYNAPSE_ACTION_BOTH_EDGES] = SYNAPSE_ACTION_BOTH_EDGES
+};
+
+static int quad8_action_get(struct counter_device *counter,
+	struct counter_count *count, struct counter_synapse *synapse,
+	size_t *action)
+{
+	struct quad8_iio *const priv = counter->priv;
+	int err;
+	size_t function = 0;
+	const size_t signal_a_id = count->synapses[0].signal->id;
+	enum count_direction direction;
+
+	/* Handle Index signals */
+	if (synapse->signal->id >= 16) {
+		if (priv->preset_enable[count->id])
+			*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
+		else
+			*action = QUAD8_SYNAPSE_ACTION_NONE;
+
+		return 0;
+	}
+
+	err = quad8_function_get(counter, count, &function);
+	if (err)
+		return err;
+
+	/* Default action mode */
+	*action = QUAD8_SYNAPSE_ACTION_NONE;
+
+	/* Determine action mode based on current count function mode */
+	switch (function) {
+	case QUAD8_COUNT_FUNCTION_PULSE_DIRECTION:
+		if (synapse->signal->id == signal_a_id)
+			*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
+		break;
+	case QUAD8_COUNT_FUNCTION_QUADRATURE_X1:
+		if (synapse->signal->id == signal_a_id) {
+			quad8_direction_get(counter, count, &direction);
+
+			if (direction == COUNT_DIRECTION_FORWARD)
+				*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
+			else
+				*action = QUAD8_SYNAPSE_ACTION_FALLING_EDGE;
+		}
+		break;
+	case QUAD8_COUNT_FUNCTION_QUADRATURE_X2:
+		if (synapse->signal->id == signal_a_id)
+			*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
+		break;
+	case QUAD8_COUNT_FUNCTION_QUADRATURE_X4:
+		*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
+		break;
+	}
+
+	return 0;
+}
+
+const struct counter_ops quad8_ops = {
+	.signal_read = quad8_signal_read,
+	.count_read = quad8_count_read,
+	.count_write = quad8_count_write,
+	.function_get = quad8_function_get,
+	.function_set = quad8_function_set,
+	.action_get = quad8_action_get
+};
+
+static int quad8_index_polarity_get(struct counter_device *counter,
+	struct counter_signal *signal, size_t *index_polarity)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	const size_t channel_id = signal->id - 16;
+
+	*index_polarity = priv->index_polarity[channel_id];
+
+	return 0;
+}
+
+static int quad8_index_polarity_set(struct counter_device *counter,
+	struct counter_signal *signal, size_t index_polarity)
+{
+	struct quad8_iio *const priv = counter->priv;
+	const size_t channel_id = signal->id - 16;
+	const unsigned int idr_cfg = priv->synchronous_mode[channel_id] |
+		index_polarity << 1;
+	const int base_offset = priv->base + 2 * channel_id + 1;
+
+	priv->index_polarity[channel_id] = index_polarity;
+
+	/* Load Index Control configuration to Index Control Register */
+	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
+
+	return 0;
+}
+
+static struct counter_signal_enum_ext quad8_index_pol_enum = {
+	.items = quad8_index_polarity_modes,
+	.num_items = ARRAY_SIZE(quad8_index_polarity_modes),
+	.get = quad8_index_polarity_get,
+	.set = quad8_index_polarity_set
+};
+
+static int quad8_synchronous_mode_get(struct counter_device *counter,
+	struct counter_signal *signal, size_t *synchronous_mode)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	const size_t channel_id = signal->id - 16;
+
+	*synchronous_mode = priv->synchronous_mode[channel_id];
+
+	return 0;
+}
+
+static int quad8_synchronous_mode_set(struct counter_device *counter,
+	struct counter_signal *signal, size_t synchronous_mode)
+{
+	struct quad8_iio *const priv = counter->priv;
+	const size_t channel_id = signal->id - 16;
+	const unsigned int idr_cfg = synchronous_mode |
+		priv->index_polarity[channel_id] << 1;
+	const int base_offset = priv->base + 2 * channel_id + 1;
+
+	/* Index function must be non-synchronous in non-quadrature mode */
+	if (synchronous_mode && !priv->quadrature_mode[channel_id])
+		return -EINVAL;
+
+	priv->synchronous_mode[channel_id] = synchronous_mode;
+
+	/* Load Index Control configuration to Index Control Register */
+	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
+
+	return 0;
+}
+
+static struct counter_signal_enum_ext quad8_syn_mode_enum = {
+	.items = quad8_synchronous_modes,
+	.num_items = ARRAY_SIZE(quad8_synchronous_modes),
+	.get = quad8_synchronous_mode_get,
+	.set = quad8_synchronous_mode_set
+};
+
+static ssize_t quad8_count_floor_read(struct counter_device *counter,
+	struct counter_count *count, void *private, char *buf)
+{
+	/* Only a floor of 0 is supported */
+	return snprintf(buf, PAGE_SIZE, "0\n");
+}
+
+static int quad8_count_mode_get(struct counter_device *counter,
+	struct counter_count *count, size_t *cnt_mode)
+{
+	const struct quad8_iio *const priv = counter->priv;
+
+	/* Map 104-QUAD-8 count mode to Generic Counter count mode */
+	switch (priv->count_mode[count->id]) {
+	case 0:
+		*cnt_mode = COUNT_MODE_NORMAL;
+		break;
+	case 1:
+		*cnt_mode = COUNT_MODE_RANGE_LIMIT;
+		break;
+	case 2:
+		*cnt_mode = COUNT_MODE_NON_RECYCLE;
+		break;
+	case 3:
+		*cnt_mode = COUNT_MODE_MODULO_N;
+		break;
+	}
+
+	return 0;
+}
+
+static int quad8_count_mode_set(struct counter_device *counter,
+	struct counter_count *count, size_t cnt_mode)
+{
+	struct quad8_iio *const priv = counter->priv;
+	unsigned int mode_cfg;
+	const int base_offset = priv->base + 2 * count->id + 1;
+
+	/* Map Generic Counter count mode to 104-QUAD-8 count mode */
+	switch (cnt_mode) {
+	case COUNT_MODE_NORMAL:
+		cnt_mode = 0;
+		break;
+	case COUNT_MODE_RANGE_LIMIT:
+		cnt_mode = 1;
+		break;
+	case COUNT_MODE_NON_RECYCLE:
+		cnt_mode = 2;
+		break;
+	case COUNT_MODE_MODULO_N:
+		cnt_mode = 3;
+		break;
+	}
+
+	priv->count_mode[count->id] = cnt_mode;
+
+	/* Set count mode configuration value */
+	mode_cfg = cnt_mode << 1;
+
+	/* Add quadrature mode configuration */
+	if (priv->quadrature_mode[count->id])
+		mode_cfg |= (priv->quadrature_scale[count->id] + 1) << 3;
+
+	/* Load mode configuration to Counter Mode Register */
+	outb(QUAD8_CTR_CMR | mode_cfg, base_offset);
+
+	return 0;
+}
+
+static struct counter_count_enum_ext quad8_cnt_mode_enum = {
+	.items = count_mode_str,
+	.num_items = ARRAY_SIZE(count_mode_str),
+	.get = quad8_count_mode_get,
+	.set = quad8_count_mode_set
+};
+
+static ssize_t quad8_count_direction_read(struct counter_device *counter,
+	struct counter_count *count, void *priv, char *buf)
+{
+	enum count_direction dir;
+
+	quad8_direction_get(counter, count, &dir);
+
+	return scnprintf(buf, PAGE_SIZE, "%s\n", count_direction_str[dir]);
+}
+
+static ssize_t quad8_count_enable_read(struct counter_device *counter,
+	struct counter_count *count, void *private, char *buf)
+{
+	const struct quad8_iio *const priv = counter->priv;
+
+	return scnprintf(buf, PAGE_SIZE, "%u\n", priv->ab_enable[count->id]);
+}
+
+static ssize_t quad8_count_enable_write(struct counter_device *counter,
+	struct counter_count *count, void *private, const char *buf, size_t len)
+{
+	struct quad8_iio *const priv = counter->priv;
+	const int base_offset = priv->base + 2 * count->id;
+	int err;
+	bool ab_enable;
+	unsigned int ior_cfg;
+
+	err = kstrtobool(buf, &ab_enable);
+	if (err)
+		return err;
+
+	priv->ab_enable[count->id] = ab_enable;
+
+	ior_cfg = ab_enable | priv->preset_enable[count->id] << 1;
+
+	/* Load I/O control configuration */
+	outb(QUAD8_CTR_IOR | ior_cfg, base_offset + 1);
+
+	return len;
+}
+
+static int quad8_error_noise_get(struct counter_device *counter,
+	struct counter_count *count, size_t *noise_error)
+{
+	const struct quad8_iio *const priv = counter->priv;
+	const int base_offset = priv->base + 2 * count->id + 1;
+
+	*noise_error = !!(inb(base_offset) & QUAD8_FLAG_E);
+
+	return 0;
+}
+
+static struct counter_count_enum_ext quad8_error_noise_enum = {
+	.items = quad8_noise_error_states,
+	.num_items = ARRAY_SIZE(quad8_noise_error_states),
+	.get = quad8_error_noise_get
+};
+
+static ssize_t quad8_count_preset_read(struct counter_device *counter,
+	struct counter_count *count, void *private, char *buf)
+{
+	const struct quad8_iio *const priv = counter->priv;
+
+	return snprintf(buf, PAGE_SIZE, "%u\n", priv->preset[count->id]);
+}
+
+static ssize_t quad8_count_preset_write(struct counter_device *counter,
+	struct counter_count *count, void *private, const char *buf, size_t len)
+{
+	struct quad8_iio *const priv = counter->priv;
+	const int base_offset = priv->base + 2 * count->id;
+	unsigned int preset;
+	int ret;
+	int i;
+
+	ret = kstrtouint(buf, 0, &preset);
+	if (ret)
+		return ret;
+
+	/* Only 24-bit values are supported */
+	if (preset > 0xFFFFFF)
+		return -EINVAL;
+
+	priv->preset[count->id] = preset;
+
+	/* Reset Byte Pointer */
+	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
+
+	/* Set Preset Register */
+	for (i = 0; i < 3; i++)
+		outb(preset >> (8 * i), base_offset);
+
+	return len;
+}
+
+static ssize_t quad8_count_ceiling_read(struct counter_device *counter,
+	struct counter_count *count, void *private, char *buf)
+{
+	const struct quad8_iio *const priv = counter->priv;
+
+	/* Range Limit and Modulo-N count modes use preset value as ceiling */
+	switch (priv->count_mode[count->id]) {
+	case 1:
+	case 3:
+		return quad8_count_preset_read(counter, count, private, buf);
+	}
+
+	/* By default 0x1FFFFFF (25 bits unsigned) is maximum count */
+	return snprintf(buf, PAGE_SIZE, "33554431\n");
+}
+
+static ssize_t quad8_count_ceiling_write(struct counter_device *counter,
+	struct counter_count *count, void *private, const char *buf, size_t len)
+{
+	struct quad8_iio *const priv = counter->priv;
+
+	/* Range Limit and Modulo-N count modes use preset value as ceiling */
+	switch (priv->count_mode[count->id]) {
+	case 1:
+	case 3:
+		return quad8_count_preset_write(counter, count, private, buf,
+						len);
+	}
+
+	return len;
+}
+
+static ssize_t quad8_count_preset_enable_read(struct counter_device *counter,
+	struct counter_count *count, void *private, char *buf)
+{
+	const struct quad8_iio *const priv = counter->priv;
+
+	return snprintf(buf, PAGE_SIZE, "%u\n",
+		!priv->preset_enable[count->id]);
+}
+
+static ssize_t quad8_count_preset_enable_write(struct counter_device *counter,
+	struct counter_count *count, void *private, const char *buf, size_t len)
+{
+	struct quad8_iio *const priv = counter->priv;
+	const int base_offset = priv->base + 2 * count->id + 1;
+	bool preset_enable;
+	int ret;
+	unsigned int ior_cfg;
+
+	ret = kstrtobool(buf, &preset_enable);
+	if (ret)
+		return ret;
+
+	/* Preset enable is active low in Input/Output Control register */
+	preset_enable = !preset_enable;
+
+	priv->preset_enable[count->id] = preset_enable;
+
+	ior_cfg = priv->ab_enable[count->id] | (unsigned int)preset_enable << 1;
+
+	/* Load I/O control configuration to Input / Output Control Register */
+	outb(QUAD8_CTR_IOR | ior_cfg, base_offset);
+
+	return len;
+}
+
+static const struct counter_signal_ext quad8_index_ext[] = {
+	COUNTER_SIGNAL_ENUM("index_polarity", &quad8_index_pol_enum),
+	COUNTER_SIGNAL_ENUM_AVAILABLE("index_polarity",	&quad8_index_pol_enum),
+	COUNTER_SIGNAL_ENUM("synchronous_mode", &quad8_syn_mode_enum),
+	COUNTER_SIGNAL_ENUM_AVAILABLE("synchronous_mode", &quad8_syn_mode_enum)
+};
+
+#define	QUAD8_QUAD_SIGNAL(_id, _name) {	\
+	.id = (_id),			\
+	.name = (_name)			\
+}
+
+#define	QUAD8_INDEX_SIGNAL(_id, _name) {	\
+	.id = (_id),				\
+	.name = (_name),			\
+	.ext = quad8_index_ext,			\
+	.num_ext = ARRAY_SIZE(quad8_index_ext)	\
+}
+
+static struct counter_signal quad8_signals[] = {
+	QUAD8_QUAD_SIGNAL(0, "Channel 1 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(1, "Channel 1 Quadrature B"),
+	QUAD8_QUAD_SIGNAL(2, "Channel 2 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(3, "Channel 2 Quadrature B"),
+	QUAD8_QUAD_SIGNAL(4, "Channel 3 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(5, "Channel 3 Quadrature B"),
+	QUAD8_QUAD_SIGNAL(6, "Channel 4 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(7, "Channel 4 Quadrature B"),
+	QUAD8_QUAD_SIGNAL(8, "Channel 5 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(9, "Channel 5 Quadrature B"),
+	QUAD8_QUAD_SIGNAL(10, "Channel 6 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(11, "Channel 6 Quadrature B"),
+	QUAD8_QUAD_SIGNAL(12, "Channel 7 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(13, "Channel 7 Quadrature B"),
+	QUAD8_QUAD_SIGNAL(14, "Channel 8 Quadrature A"),
+	QUAD8_QUAD_SIGNAL(15, "Channel 8 Quadrature B"),
+	QUAD8_INDEX_SIGNAL(16, "Channel 1 Index"),
+	QUAD8_INDEX_SIGNAL(17, "Channel 2 Index"),
+	QUAD8_INDEX_SIGNAL(18, "Channel 3 Index"),
+	QUAD8_INDEX_SIGNAL(19, "Channel 4 Index"),
+	QUAD8_INDEX_SIGNAL(20, "Channel 5 Index"),
+	QUAD8_INDEX_SIGNAL(21, "Channel 6 Index"),
+	QUAD8_INDEX_SIGNAL(22, "Channel 7 Index"),
+	QUAD8_INDEX_SIGNAL(23, "Channel 8 Index")
+};
+
+#define QUAD8_COUNT_SYNAPSES(_id) {					\
+	{								\
+		.actions_list = quad8_synapse_actions_list,		\
+		.num_actions = ARRAY_SIZE(quad8_synapse_actions_list),	\
+		.signal = quad8_signals + 2 * (_id)			\
+	},								\
+	{								\
+		.actions_list = quad8_synapse_actions_list,		\
+		.num_actions = ARRAY_SIZE(quad8_synapse_actions_list),	\
+		.signal = quad8_signals + 2 * (_id) + 1			\
+	},								\
+	{								\
+		.actions_list = quad8_index_actions_list,		\
+		.num_actions = ARRAY_SIZE(quad8_index_actions_list),	\
+		.signal = quad8_signals + 2 * (_id) + 16		\
+	}								\
+}
+
+static struct counter_synapse quad8_count_synapses[][3] = {
+	QUAD8_COUNT_SYNAPSES(0), QUAD8_COUNT_SYNAPSES(1),
+	QUAD8_COUNT_SYNAPSES(2), QUAD8_COUNT_SYNAPSES(3),
+	QUAD8_COUNT_SYNAPSES(4), QUAD8_COUNT_SYNAPSES(5),
+	QUAD8_COUNT_SYNAPSES(6), QUAD8_COUNT_SYNAPSES(7)
+};
+
+static const struct counter_count_ext quad8_count_ext[] = {
+	{
+		.name = "ceiling",
+		.read = quad8_count_ceiling_read,
+		.write = quad8_count_ceiling_write
+	},
+	{
+		.name = "floor",
+		.read = quad8_count_floor_read
+	},
+	COUNTER_COUNT_ENUM("count_mode", &quad8_cnt_mode_enum),
+	COUNTER_COUNT_ENUM_AVAILABLE("count_mode", &quad8_cnt_mode_enum),
+	{
+		.name = "direction",
+		.read = quad8_count_direction_read
+	},
+	{
+		.name = "enable",
+		.read = quad8_count_enable_read,
+		.write = quad8_count_enable_write
+	},
+	COUNTER_COUNT_ENUM("error_noise", &quad8_error_noise_enum),
+	COUNTER_COUNT_ENUM_AVAILABLE("error_noise", &quad8_error_noise_enum),
+	{
+		.name = "preset",
+		.read = quad8_count_preset_read,
+		.write = quad8_count_preset_write
+	},
+	{
+		.name = "preset_enable",
+		.read = quad8_count_preset_enable_read,
+		.write = quad8_count_preset_enable_write
+	}
+};
+
+#define QUAD8_COUNT(_id, _cntname) {					\
+	.id = (_id),							\
+	.name = (_cntname),						\
+	.functions_list = quad8_count_functions_list,			\
+	.num_functions = ARRAY_SIZE(quad8_count_functions_list),	\
+	.synapses = quad8_count_synapses[(_id)],			\
+	.num_synapses =	2,						\
+	.ext = quad8_count_ext,						\
+	.num_ext = ARRAY_SIZE(quad8_count_ext)				\
+}
+
+static struct counter_count quad8_counts[] = {
+	QUAD8_COUNT(0, "Channel 1 Count"),
+	QUAD8_COUNT(1, "Channel 2 Count"),
+	QUAD8_COUNT(2, "Channel 3 Count"),
+	QUAD8_COUNT(3, "Channel 4 Count"),
+	QUAD8_COUNT(4, "Channel 5 Count"),
+	QUAD8_COUNT(5, "Channel 6 Count"),
+	QUAD8_COUNT(6, "Channel 7 Count"),
+	QUAD8_COUNT(7, "Channel 8 Count")
+};
+
 static int quad8_probe(struct device *dev, unsigned int id)
 {
 	struct iio_dev *indio_dev;
-	struct quad8_iio *priv;
+	struct quad8_iio *quad8iio;
 	int i, j;
 	unsigned int base_offset;
+	int err;
 
-	indio_dev = devm_iio_device_alloc(dev, sizeof(*priv));
-	if (!indio_dev)
-		return -ENOMEM;
-
-	if (!devm_request_region(dev, base[id], QUAD8_EXTENT,
-		dev_name(dev))) {
+	if (!devm_request_region(dev, base[id], QUAD8_EXTENT, dev_name(dev))) {
 		dev_err(dev, "Unable to lock port addresses (0x%X-0x%X)\n",
 			base[id], base[id] + QUAD8_EXTENT);
 		return -EBUSY;
 	}
 
+	/* Allocate IIO device; this also allocates driver data structure */
+	indio_dev = devm_iio_device_alloc(dev, sizeof(*quad8iio));
+	if (!indio_dev)
+		return -ENOMEM;
+
+	/* Initialize IIO device */
 	indio_dev->info = &quad8_info;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	indio_dev->num_channels = ARRAY_SIZE(quad8_channels);
@@ -587,8 +1308,17 @@ static int quad8_probe(struct device *dev, unsigned int id)
 	indio_dev->name = dev_name(dev);
 	indio_dev->dev.parent = dev;
 
-	priv = iio_priv(indio_dev);
-	priv->base = base[id];
+	/* Initialize Counter device and driver data */
+	quad8iio = iio_priv(indio_dev);
+	quad8iio->counter.name = dev_name(dev);
+	quad8iio->counter.parent = dev;
+	quad8iio->counter.ops = &quad8_ops;
+	quad8iio->counter.counts = quad8_counts;
+	quad8iio->counter.num_counts = ARRAY_SIZE(quad8_counts);
+	quad8iio->counter.signals = quad8_signals;
+	quad8iio->counter.num_signals = ARRAY_SIZE(quad8_signals);
+	quad8iio->counter.priv = quad8iio;
+	quad8iio->base = base[id];
 
 	/* Reset all counters and disable interrupt function */
 	outb(QUAD8_CHAN_OP_RESET_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
@@ -614,7 +1344,13 @@ static int quad8_probe(struct device *dev, unsigned int id)
 	/* Enable all counters */
 	outb(QUAD8_CHAN_OP_ENABLE_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
 
-	return devm_iio_device_register(dev, indio_dev);
+	/* Register IIO device */
+	err = devm_iio_device_register(dev, indio_dev);
+	if (err)
+		return err;
+
+	/* Register Counter device */
+	return devm_counter_register(dev, &quad8iio->counter);
 }
 
 static struct isa_driver quad8_driver = {
diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
index 65fa92abd5a4..7646f5df76f3 100644
--- a/drivers/counter/Kconfig
+++ b/drivers/counter/Kconfig
@@ -16,3 +16,24 @@ menuconfig COUNTER
 	  consumption. The Generic Counter interface enables drivers to support
 	  and expose a common set of components and functionality present in
 	  counter devices.
+
+if COUNTER
+
+config 104_QUAD_8
+	tristate "ACCES 104-QUAD-8 driver"
+	depends on PC104 && X86 && IIO
+	select ISA_BUS_API
+	help
+	  Say yes here to build support for the ACCES 104-QUAD-8 quadrature
+	  encoder counter/interface device family (104-QUAD-8, 104-QUAD-4).
+
+	  A counter's respective error flag may be cleared by performing a write
+	  operation on the respective count value attribute. Although the
+	  104-QUAD-8 counters have a 25-bit range, only the lower 24 bits may be
+	  set, either directly or via the counter's preset attribute. Interrupts
+	  are not supported by this driver.
+
+	  The base port addresses for the devices may be configured via the base
+	  array module parameter.
+
+endif # COUNTER
diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
index ad1ba7109cdc..23a4f6263e45 100644
--- a/drivers/counter/Makefile
+++ b/drivers/counter/Makefile
@@ -6,3 +6,5 @@
 
 obj-$(CONFIG_COUNTER) += counter.o
 counter-y := generic-counter.o
+
+obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
diff --git a/drivers/iio/counter/Kconfig b/drivers/iio/counter/Kconfig
index bf1e559ad7cd..eeb358122cbe 100644
--- a/drivers/iio/counter/Kconfig
+++ b/drivers/iio/counter/Kconfig
@@ -5,23 +5,6 @@
 
 menu "Counters"
 
-config 104_QUAD_8
-	tristate "ACCES 104-QUAD-8 driver"
-	depends on PC104 && X86
-	select ISA_BUS_API
-	help
-	  Say yes here to build support for the ACCES 104-QUAD-8 quadrature
-	  encoder counter/interface device family (104-QUAD-8, 104-QUAD-4).
-
-	  Performing a write to a counter's IIO_CHAN_INFO_RAW sets the counter and
-	  also clears the counter's respective error flag. Although the counters
-	  have a 25-bit range, only the lower 24 bits may be set, either directly
-	  or via a counter's preset attribute. Interrupts are not supported by
-	  this driver.
-
-	  The base port addresses for the devices may be configured via the base
-	  array module parameter.
-
 config STM32_LPTIMER_CNT
 	tristate "STM32 LP Timer encoder counter driver"
 	depends on MFD_STM32_LPTIMER || COMPILE_TEST
diff --git a/drivers/iio/counter/Makefile b/drivers/iio/counter/Makefile
index 1b9a896eb488..93933ba49280 100644
--- a/drivers/iio/counter/Makefile
+++ b/drivers/iio/counter/Makefile
@@ -4,5 +4,4 @@
 
 # When adding new entries keep the list in alphabetical order
 
-obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
 obj-$(CONFIG_STM32_LPTIMER_CNT)	+= stm32-lptimer-cnt.o
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 05/10] counter: 104-quad-8: Documentation: Add Generic Counter sysfs documentation
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (3 preceding siblings ...)
  2018-06-21 21:07 ` [PATCH v7 04/10] counter: 104-quad-8: Add Generic Counter interface support William Breathitt Gray
@ 2018-06-21 21:08 ` William Breathitt Gray
  2018-06-22 16:59   ` Jonathan Cameron
  2018-06-21 21:08 ` [PATCH v7 06/10] counter: Add STM32 Timer quadrature encoder William Breathitt Gray
                   ` (6 subsequent siblings)
  11 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:08 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

This patch adds standard documentation for the Generic Counter interface
userspace sysfs attributes of the 104-QUAD-8 driver.

Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 .../ABI/testing/sysfs-bus-counter-104-quad-8  | 36 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 37 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-counter-104-quad-8

diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
new file mode 100644
index 000000000000..062637df3c78
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
@@ -0,0 +1,36 @@
+What:		/sys/bus/counter/devices/counterX/signalY/index_polarity
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Active level of index input Signal Y; irrelevant in
+		non-synchronous load mode.
+
+What:		/sys/bus/counter/devices/counterX/signalY/index_polarity_available
+What:		/sys/bus/counter/devices/counterX/signalY/synchronous_mode_available
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Discrete set of available values for the respective Signal Y
+		configuration are listed in this file.
+
+What:		/sys/bus/counter/devices/counterX/signalY/synchronous_mode
+KernelVersion:	4.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Configure the counter associated with Signal Y for
+		non-synchronous or synchronous load mode. Synchronous load mode
+		cannot be selected in non-quadrature (Pulse-Direction) clock
+		mode.
+
+		Non-synchronous:
+			A logic low level is the active level at this index
+			input. The index function (as enabled via preset_enable)
+			is performed directly on the active level of the index
+			input.
+
+		Synchronous:
+			Intended for interfacing with encoder Index output in
+			quadrature clock mode. The active level is configured
+			via index_polarity. The index function (as enabled via
+			preset_enable) is performed synchronously with the
+			quadrature clock on the active level of the index input.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4083523699f3..a06fd762f5d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -270,6 +270,7 @@ ACCES 104-QUAD-8 DRIVER
 M:	William Breathitt Gray <vilhelm.gray@gmail.com>
 L:	linux-iio@vger.kernel.org
 S:	Maintained
+F:	Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
 F:	Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
 F:	drivers/counter/104-quad-8.c
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 06/10] counter: Add STM32 Timer quadrature encoder
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (4 preceding siblings ...)
  2018-06-21 21:08 ` [PATCH v7 05/10] counter: 104-quad-8: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
@ 2018-06-21 21:08 ` William Breathitt Gray
  2018-06-22 17:03   ` Jonathan Cameron
  2018-06-21 21:08 ` [PATCH v7 07/10] dt-bindings: counter: Document stm32 " William Breathitt Gray
                   ` (5 subsequent siblings)
  11 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:08 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

From: Benjamin Gaignard <benjamin.gaignard@st.com>

Implement counter part of the STM32 timer hardware block by using
counter API. Hardware only supports X2 and X4 quadrature modes. A
ceiling value can be set to define the maximum value reachable by the
counter.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Co-authored-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 drivers/counter/Kconfig           |  10 +
 drivers/counter/Makefile          |   1 +
 drivers/counter/stm32-timer-cnt.c | 390 ++++++++++++++++++++++++++++++
 3 files changed, 401 insertions(+)
 create mode 100644 drivers/counter/stm32-timer-cnt.c

diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
index 7646f5df76f3..fcfbaa935122 100644
--- a/drivers/counter/Kconfig
+++ b/drivers/counter/Kconfig
@@ -36,4 +36,14 @@ config 104_QUAD_8
 	  The base port addresses for the devices may be configured via the base
 	  array module parameter.
 
+config STM32_TIMER_CNT
+	tristate "STM32 Timer encoder counter driver"
+	depends on MFD_STM32_TIMERS || COMPILE_TEST
+	help
+	  Select this option to enable STM32 Timer quadrature encoder
+	  and counter driver.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called stm32-timer-cnt.
+
 endif # COUNTER
diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
index 23a4f6263e45..ff024259fb46 100644
--- a/drivers/counter/Makefile
+++ b/drivers/counter/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_COUNTER) += counter.o
 counter-y := generic-counter.o
 
 obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
+obj-$(CONFIG_STM32_TIMER_CNT)	+= stm32-timer-cnt.o
diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
new file mode 100644
index 000000000000..0b15e729798b
--- /dev/null
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32 Timer Encoder and Counter driver
+ *
+ * Copyright (C) STMicroelectronics 2018
+ *
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
+ *
+ */
+#include <linux/counter.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/types.h>
+#include <linux/mfd/stm32-timers.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#define TIM_CCMR_CCXS	(BIT(8) | BIT(0))
+#define TIM_CCMR_MASK	(TIM_CCMR_CC1S | TIM_CCMR_CC2S | \
+			 TIM_CCMR_IC1F | TIM_CCMR_IC2F)
+#define TIM_CCER_MASK	(TIM_CCER_CC1P | TIM_CCER_CC1NP | \
+			 TIM_CCER_CC2P | TIM_CCER_CC2NP)
+
+struct stm32_timer_cnt {
+	struct counter_device counter;
+	struct regmap *regmap;
+	struct clk *clk;
+	u32 ceiling;
+};
+
+/**
+ * stm32_count_function - enumerates stm32 timer counter encoder modes
+ * @STM32_COUNT_SLAVE_MODE_DISABLED: counts on internal clock when CEN=1
+ * @STM32_COUNT_ENCODER_MODE_1: counts TI1FP1 edges, depending on TI2FP2 level
+ * @STM32_COUNT_ENCODER_MODE_2: counts TI2FP2 edges, depending on TI1FP1 level
+ * @STM32_COUNT_ENCODER_MODE_3: counts on both TI1FP1 and TI2FP2 edges
+ */
+enum stm32_count_function {
+	STM32_COUNT_SLAVE_MODE_DISABLED = -1,
+	STM32_COUNT_ENCODER_MODE_1,
+	STM32_COUNT_ENCODER_MODE_2,
+	STM32_COUNT_ENCODER_MODE_3,
+};
+
+static enum count_function stm32_count_functions[] = {
+	[STM32_COUNT_ENCODER_MODE_1] = COUNT_FUNCTION_QUADRATURE_X2_A,
+	[STM32_COUNT_ENCODER_MODE_2] = COUNT_FUNCTION_QUADRATURE_X2_B,
+	[STM32_COUNT_ENCODER_MODE_3] = COUNT_FUNCTION_QUADRATURE_X4,
+};
+
+static int stm32_count_read(struct counter_device *counter,
+			    struct counter_count *count,
+			    struct count_read_value *val)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	u32 cnt;
+
+	regmap_read(priv->regmap, TIM_CNT, &cnt);
+	count_read_value_set(val, COUNT_POSITION, &cnt);
+
+	return 0;
+}
+
+static int stm32_count_write(struct counter_device *counter,
+			     struct counter_count *count,
+			     struct count_write_value *val)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	u32 cnt;
+	int err;
+
+	err = count_write_value_get(&cnt, COUNT_POSITION, val);
+	if (err)
+		return err;
+
+	if (cnt > priv->ceiling)
+		return -EINVAL;
+
+	return regmap_write(priv->regmap, TIM_CNT, cnt);
+}
+
+static int stm32_count_function_get(struct counter_device *counter,
+				    struct counter_count *count,
+				    size_t *function)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	u32 smcr;
+
+	regmap_read(priv->regmap, TIM_SMCR, &smcr);
+
+	switch (smcr & TIM_SMCR_SMS) {
+	case 1:
+		*function = STM32_COUNT_ENCODER_MODE_1;
+		return 0;
+	case 2:
+		*function = STM32_COUNT_ENCODER_MODE_2;
+		return 0;
+	case 3:
+		*function = STM32_COUNT_ENCODER_MODE_3;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+static int stm32_count_function_set(struct counter_device *counter,
+				    struct counter_count *count,
+				    size_t function)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	u32 cr1, sms;
+
+	switch (function) {
+	case STM32_COUNT_ENCODER_MODE_1:
+		sms = 1;
+		break;
+	case STM32_COUNT_ENCODER_MODE_2:
+		sms = 2;
+		break;
+	case STM32_COUNT_ENCODER_MODE_3:
+		sms = 3;
+		break;
+	default:
+		sms = 0;
+		break;
+	}
+
+	/* Store enable status */
+	regmap_read(priv->regmap, TIM_CR1, &cr1);
+
+	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
+
+	/* TIMx_ARR register shouldn't be buffered (ARPE=0) */
+	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, 0);
+	regmap_write(priv->regmap, TIM_ARR, priv->ceiling);
+
+	regmap_update_bits(priv->regmap, TIM_SMCR, TIM_SMCR_SMS, sms);
+
+	/* Make sure that registers are updated */
+	regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
+
+	/* Restore the enable status */
+	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, cr1);
+
+	return 0;
+}
+
+static ssize_t stm32_count_direction_read(struct counter_device *counter,
+				      struct counter_count *count,
+				      void *private, char *buf)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	const char *direction;
+	u32 cr1;
+
+	regmap_read(priv->regmap, TIM_CR1, &cr1);
+	direction = (cr1 & TIM_CR1_DIR) ? "backward" : "forward";
+
+	return scnprintf(buf, PAGE_SIZE, "%s\n", direction);
+}
+
+static ssize_t stm32_count_ceiling_read(struct counter_device *counter,
+					struct counter_count *count,
+					void *private, char *buf)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	u32 arr;
+
+	regmap_read(priv->regmap, TIM_ARR, &arr);
+
+	return snprintf(buf, PAGE_SIZE, "%u\n", arr);
+}
+
+static ssize_t stm32_count_ceiling_write(struct counter_device *counter,
+					 struct counter_count *count,
+					 void *private,
+					 const char *buf, size_t len)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	unsigned int ceiling;
+	int ret;
+
+	ret = kstrtouint(buf, 0, &ceiling);
+	if (ret)
+		return ret;
+
+	/* TIMx_ARR register shouldn't be buffered (ARPE=0) */
+	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, 0);
+	regmap_write(priv->regmap, TIM_ARR, ceiling);
+
+	priv->ceiling = ceiling;
+	return len;
+}
+
+static ssize_t stm32_count_enable_read(struct counter_device *counter,
+				       struct counter_count *count,
+				       void *private, char *buf)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	u32 cr1;
+
+	regmap_read(priv->regmap, TIM_CR1, &cr1);
+
+	return scnprintf(buf, PAGE_SIZE, "%d\n", (bool)(cr1 & TIM_CR1_CEN));
+}
+
+static ssize_t stm32_count_enable_write(struct counter_device *counter,
+					struct counter_count *count,
+					void *private,
+					const char *buf, size_t len)
+{
+	struct stm32_timer_cnt *const priv = counter->priv;
+	int err;
+	u32 cr1;
+	bool enable;
+
+	err = kstrtobool(buf, &enable);
+	if (err)
+		return err;
+
+	if (enable) {
+		regmap_read(priv->regmap, TIM_CR1, &cr1);
+			if (!(cr1 & TIM_CR1_CEN))
+				clk_enable(priv->clk);
+
+		regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN,
+				   TIM_CR1_CEN);
+	} else {
+		regmap_read(priv->regmap, TIM_CR1, &cr1);
+		regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
+		if (cr1 & TIM_CR1_CEN)
+			clk_disable(priv->clk);
+	}
+
+	return len;
+}
+
+static const struct counter_count_ext stm32_count_ext[] = {
+	{
+		.name = "direction",
+		.read = stm32_count_direction_read,
+	},
+	{
+		.name = "enable",
+		.read = stm32_count_enable_read,
+		.write = stm32_count_enable_write
+	},
+	{
+		.name = "ceiling",
+		.read = stm32_count_ceiling_read,
+		.write = stm32_count_ceiling_write
+	},
+};
+
+enum stm32_synapse_action {
+	STM32_SYNAPSE_ACTION_NONE,
+	STM32_SYNAPSE_ACTION_BOTH_EDGES
+};
+
+static enum synapse_action stm32_synapse_actions[] = {
+	[STM32_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
+	[STM32_SYNAPSE_ACTION_BOTH_EDGES] = SYNAPSE_ACTION_BOTH_EDGES
+};
+
+static int stm32_action_get(struct counter_device *counter,
+			    struct counter_count *count,
+			    struct counter_synapse *synapse,
+			    size_t *action)
+{
+	size_t function;
+	int err;
+
+	/* Default action mode (e.g. STM32_COUNT_SLAVE_MODE_DISABLED) */
+	*action = STM32_SYNAPSE_ACTION_NONE;
+
+	err = stm32_count_function_get(counter, count, &function);
+	if (err)
+		return 0;
+
+	switch (function) {
+	case STM32_COUNT_ENCODER_MODE_1:
+		/* counts up/down on TI1FP1 edge depending on TI2FP2 level */
+		if (synapse->signal->id == count->synapses[0].signal->id)
+			*action = STM32_SYNAPSE_ACTION_BOTH_EDGES;
+		break;
+	case STM32_COUNT_ENCODER_MODE_2:
+		/* counts up/down on TI2FP2 edge depending on TI1FP1 level */
+		if (synapse->signal->id == count->synapses[1].signal->id)
+			*action = STM32_SYNAPSE_ACTION_BOTH_EDGES;
+		break;
+	case STM32_COUNT_ENCODER_MODE_3:
+		/* counts up/down on both TI1FP1 and TI2FP2 edges */
+		*action = STM32_SYNAPSE_ACTION_BOTH_EDGES;
+		break;
+	}
+
+	return 0;
+}
+
+static const struct counter_ops stm32_timer_cnt_ops = {
+	.count_read = stm32_count_read,
+	.count_write = stm32_count_write,
+	.function_get = stm32_count_function_get,
+	.function_set = stm32_count_function_set,
+	.action_get = stm32_action_get,
+};
+
+static struct counter_signal stm32_signals[] = {
+	{
+		.id = 0,
+		.name = "Channel 1 Quadrature A"
+	},
+	{
+		.id = 1,
+		.name = "Channel 1 Quadrature B"
+	}
+};
+
+static struct counter_synapse stm32_count_synapses[] = {
+	{
+		.actions_list = stm32_synapse_actions,
+		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
+		.signal = &stm32_signals[0]
+	},
+	{
+		.actions_list = stm32_synapse_actions,
+		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
+		.signal = &stm32_signals[1]
+	}
+};
+
+static struct counter_count stm32_counts = {
+	.id = 0,
+	.name = "Channel 1 Count",
+	.functions_list = stm32_count_functions,
+	.num_functions = ARRAY_SIZE(stm32_count_functions),
+	.synapses = stm32_count_synapses,
+	.num_synapses = ARRAY_SIZE(stm32_count_synapses),
+	.ext = stm32_count_ext,
+	.num_ext = ARRAY_SIZE(stm32_count_ext)
+};
+
+static int stm32_timer_cnt_probe(struct platform_device *pdev)
+{
+	struct stm32_timers *ddata = dev_get_drvdata(pdev->dev.parent);
+	struct device *dev = &pdev->dev;
+	struct stm32_timer_cnt *priv;
+
+	if (IS_ERR_OR_NULL(ddata))
+		return -EINVAL;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->regmap = ddata->regmap;
+	priv->clk = ddata->clk;
+	priv->ceiling = ddata->max_arr;
+
+	priv->counter.name = dev_name(dev);
+	priv->counter.parent = dev;
+	priv->counter.ops = &stm32_timer_cnt_ops;
+	priv->counter.counts = &stm32_counts;
+	priv->counter.num_counts = 1;
+	priv->counter.signals = stm32_signals;
+	priv->counter.num_signals = ARRAY_SIZE(stm32_signals);
+	priv->counter.priv = priv;
+
+	/* Register Counter device */
+	return devm_counter_register(dev, &priv->counter);
+}
+
+static const struct of_device_id stm32_timer_cnt_of_match[] = {
+	{ .compatible = "st,stm32-timer-counter", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, stm32_timer_cnt_of_match);
+
+static struct platform_driver stm32_timer_cnt_driver = {
+	.probe = stm32_timer_cnt_probe,
+	.driver = {
+		.name = "stm32-timer-counter",
+		.of_match_table = stm32_timer_cnt_of_match,
+	},
+};
+module_platform_driver(stm32_timer_cnt_driver);
+
+MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
+MODULE_ALIAS("platform:stm32-timer-counter");
+MODULE_DESCRIPTION("STMicroelectronics STM32 TIMER counter driver");
+MODULE_LICENSE("GPL v2");
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 07/10] dt-bindings: counter: Document stm32 quadrature encoder
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (5 preceding siblings ...)
  2018-06-21 21:08 ` [PATCH v7 06/10] counter: Add STM32 Timer quadrature encoder William Breathitt Gray
@ 2018-06-21 21:08 ` William Breathitt Gray
  2018-07-02 19:56   ` [v7,07/10] " David Lechner
  2018-07-05 21:13   ` [PATCH v7 07/10] " Rob Herring
  2018-06-21 21:08 ` [PATCH v7 08/10] counter: stm32-lptimer: add counter device William Breathitt Gray
                   ` (4 subsequent siblings)
  11 siblings, 2 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:08 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

From: Benjamin Gaignard <benjamin.gaignard@st.com>

Add bindings for STM32 Timer quadrature encoder.
It is a sub-node of STM32 Timer which implement the
quadratic encoder part of the hardware.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 .../bindings/counter/stm32-timer-cnt.txt      | 31 +++++++++++++++++++
 .../devicetree/bindings/mfd/stm32-timers.txt  |  7 +++++
 2 files changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt

diff --git a/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
new file mode 100644
index 000000000000..c52fcdd4bf6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
@@ -0,0 +1,31 @@
+STMicroelectronics STM32 Timer quadrature encoder
+
+STM32 Timer provides quadrature encoder to detect
+angular position and direction of rotary elements,
+from IN1 and IN2 input signals.
+
+Must be a sub-node of an STM32 Timer device tree node.
+See ../mfd/stm32-timers.txt for details about the parent node.
+
+Required properties:
+- compatible:		Must be "st,stm32-timer-counter".
+- pinctrl-names: 	Set to "default".
+- pinctrl-0: 		List of phandles pointing to pin configuration nodes,
+			to set CH1/CH2 pins in mode of operation for STM32
+			Timer input on external pin.
+
+Example:
+	timers@40010000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "st,stm32-timers";
+		reg = <0x40010000 0x400>;
+		clocks = <&rcc 0 160>;
+		clock-names = "int";
+
+		counter {
+			compatible = "st,stm32-timer-counter";
+			pinctrl-names = "default";
+			pinctrl-0 = <&tim1_in_pins>;
+		};
+	};
diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
index 1db6e0057a63..ff9c14ada30b 100644
--- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
+++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
@@ -23,6 +23,7 @@ Optional parameters:
 Optional subnodes:
 - pwm:			See ../pwm/pwm-stm32.txt
 - timer:		See ../iio/timer/stm32-timer-trigger.txt
+- counter:		See ../counter/stm32-timer-cnt.txt
 
 Example:
 	timers@40010000 {
@@ -43,4 +44,10 @@ Example:
 			compatible = "st,stm32-timer-trigger";
 			reg = <0>;
 		};
+
+		counter {
+			compatible = "st,stm32-timer-counter";
+			pinctrl-names = "default";
+			pinctrl-0 = <&tim1_in_pins>;
+		};
 	};
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 08/10] counter: stm32-lptimer: add counter device
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (6 preceding siblings ...)
  2018-06-21 21:08 ` [PATCH v7 07/10] dt-bindings: counter: Document stm32 " William Breathitt Gray
@ 2018-06-21 21:08 ` William Breathitt Gray
  2018-06-22 17:06   ` Jonathan Cameron
  2018-06-21 21:08 ` [PATCH v7 09/10] dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move William Breathitt Gray
                   ` (3 subsequent siblings)
  11 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:08 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

From: Fabrice Gasnier <fabrice.gasnier@st.com>

Add support for new counter device to stm32-lptimer.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 drivers/counter/Kconfig                       |  10 +
 drivers/counter/Makefile                      |   1 +
 drivers/{iio => }/counter/stm32-lptimer-cnt.c | 361 ++++++++++++++++--
 drivers/iio/Kconfig                           |   1 -
 drivers/iio/Makefile                          |   1 -
 drivers/iio/counter/Kconfig                   |  17 -
 drivers/iio/counter/Makefile                  |   7 -
 7 files changed, 350 insertions(+), 48 deletions(-)
 rename drivers/{iio => }/counter/stm32-lptimer-cnt.c (48%)
 delete mode 100644 drivers/iio/counter/Kconfig
 delete mode 100644 drivers/iio/counter/Makefile

diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
index fcfbaa935122..fc072b97e5d2 100644
--- a/drivers/counter/Kconfig
+++ b/drivers/counter/Kconfig
@@ -46,4 +46,14 @@ config STM32_TIMER_CNT
 	  To compile this driver as a module, choose M here: the
 	  module will be called stm32-timer-cnt.
 
+config STM32_LPTIMER_CNT
+	tristate "STM32 LP Timer encoder counter driver"
+	depends on (MFD_STM32_LPTIMER || COMPILE_TEST) && IIO
+	help
+	  Select this option to enable STM32 Low-Power Timer quadrature encoder
+	  and counter driver.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called stm32-lptimer-cnt.
+
 endif # COUNTER
diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
index ff024259fb46..8ff19b32022b 100644
--- a/drivers/counter/Makefile
+++ b/drivers/counter/Makefile
@@ -9,3 +9,4 @@ counter-y := generic-counter.o
 
 obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
 obj-$(CONFIG_STM32_TIMER_CNT)	+= stm32-timer-cnt.o
+obj-$(CONFIG_STM32_LPTIMER_CNT)	+= stm32-lptimer-cnt.o
diff --git a/drivers/iio/counter/stm32-lptimer-cnt.c b/drivers/counter/stm32-lptimer-cnt.c
similarity index 48%
rename from drivers/iio/counter/stm32-lptimer-cnt.c
rename to drivers/counter/stm32-lptimer-cnt.c
index 42fb8ba67090..80fc883f84e7 100644
--- a/drivers/iio/counter/stm32-lptimer-cnt.c
+++ b/drivers/counter/stm32-lptimer-cnt.c
@@ -11,16 +11,18 @@
  */
 
 #include <linux/bitfield.h>
+#include <linux/counter.h>
 #include <linux/iio/iio.h>
 #include <linux/mfd/stm32-lptimer.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
 
 struct stm32_lptim_cnt {
+	struct counter_device counter;
 	struct device *dev;
 	struct regmap *regmap;
 	struct clk *clk;
-	u32 preset;
+	u32 ceiling;
 	u32 polarity;
 	u32 quadrature_mode;
 };
@@ -54,7 +56,7 @@ static int stm32_lptim_set_enable_state(struct stm32_lptim_cnt *priv,
 	}
 
 	/* LP timer must be enabled before writing CMP & ARR */
-	ret = regmap_write(priv->regmap, STM32_LPTIM_ARR, priv->preset);
+	ret = regmap_write(priv->regmap, STM32_LPTIM_ARR, priv->ceiling);
 	if (ret)
 		return ret;
 
@@ -247,44 +249,57 @@ static const struct iio_enum stm32_lptim_cnt_polarity_en = {
 	.set = stm32_lptim_cnt_set_polarity,
 };
 
-static ssize_t stm32_lptim_cnt_get_preset(struct iio_dev *indio_dev,
-					  uintptr_t private,
-					  const struct iio_chan_spec *chan,
-					  char *buf)
+static ssize_t stm32_lptim_cnt_get_ceiling(struct stm32_lptim_cnt *priv,
+					   char *buf)
 {
-	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
-
-	return snprintf(buf, PAGE_SIZE, "%u\n", priv->preset);
+	return snprintf(buf, PAGE_SIZE, "%u\n", priv->ceiling);
 }
 
-static ssize_t stm32_lptim_cnt_set_preset(struct iio_dev *indio_dev,
-					  uintptr_t private,
-					  const struct iio_chan_spec *chan,
-					  const char *buf, size_t len)
+static ssize_t stm32_lptim_cnt_set_ceiling(struct stm32_lptim_cnt *priv,
+					   const char *buf, size_t len)
 {
-	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
 	int ret;
 
 	if (stm32_lptim_is_enabled(priv))
 		return -EBUSY;
 
-	ret = kstrtouint(buf, 0, &priv->preset);
+	ret = kstrtouint(buf, 0, &priv->ceiling);
 	if (ret)
 		return ret;
 
-	if (priv->preset > STM32_LPTIM_MAX_ARR)
+	if (priv->ceiling > STM32_LPTIM_MAX_ARR)
 		return -EINVAL;
 
 	return len;
 }
 
+static ssize_t stm32_lptim_cnt_get_preset_iio(struct iio_dev *indio_dev,
+					      uintptr_t private,
+					      const struct iio_chan_spec *chan,
+					      char *buf)
+{
+	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
+
+	return stm32_lptim_cnt_get_ceiling(priv, buf);
+}
+
+static ssize_t stm32_lptim_cnt_set_preset_iio(struct iio_dev *indio_dev,
+					      uintptr_t private,
+					      const struct iio_chan_spec *chan,
+					      const char *buf, size_t len)
+{
+	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
+
+	return stm32_lptim_cnt_set_ceiling(priv, buf, len);
+}
+
 /* LP timer with encoder */
 static const struct iio_chan_spec_ext_info stm32_lptim_enc_ext_info[] = {
 	{
 		.name = "preset",
 		.shared = IIO_SEPARATE,
-		.read = stm32_lptim_cnt_get_preset,
-		.write = stm32_lptim_cnt_set_preset,
+		.read = stm32_lptim_cnt_get_preset_iio,
+		.write = stm32_lptim_cnt_set_preset_iio,
 	},
 	IIO_ENUM("polarity", IIO_SEPARATE, &stm32_lptim_cnt_polarity_en),
 	IIO_ENUM_AVAILABLE("polarity", &stm32_lptim_cnt_polarity_en),
@@ -309,8 +324,8 @@ static const struct iio_chan_spec_ext_info stm32_lptim_cnt_ext_info[] = {
 	{
 		.name = "preset",
 		.shared = IIO_SEPARATE,
-		.read = stm32_lptim_cnt_get_preset,
-		.write = stm32_lptim_cnt_set_preset,
+		.read = stm32_lptim_cnt_get_preset_iio,
+		.write = stm32_lptim_cnt_set_preset_iio,
 	},
 	IIO_ENUM("polarity", IIO_SEPARATE, &stm32_lptim_cnt_polarity_en),
 	IIO_ENUM_AVAILABLE("polarity", &stm32_lptim_cnt_polarity_en),
@@ -327,11 +342,293 @@ static const struct iio_chan_spec stm32_lptim_cnt_channels = {
 	.indexed = 1,
 };
 
+/**
+ * stm32_lptim_cnt_function - enumerates stm32 LPTimer counter & encoder modes
+ * @STM32_LPTIM_COUNTER_INCREASE: up count on IN1 rising, falling or both edges
+ * @STM32_LPTIM_ENCODER_BOTH_EDGE: count on both edges (IN1 & IN2 quadrature)
+ */
+enum stm32_lptim_cnt_function {
+	STM32_LPTIM_COUNTER_INCREASE,
+	STM32_LPTIM_ENCODER_BOTH_EDGE,
+};
+
+static enum count_function stm32_lptim_cnt_functions[] = {
+	[STM32_LPTIM_COUNTER_INCREASE] = COUNT_FUNCTION_INCREASE,
+	[STM32_LPTIM_ENCODER_BOTH_EDGE] = COUNT_FUNCTION_QUADRATURE_X4,
+};
+
+enum stm32_lptim_synapse_action {
+	STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE,
+	STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE,
+	STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES,
+	STM32_LPTIM_SYNAPSE_ACTION_NONE,
+};
+
+static enum synapse_action stm32_lptim_cnt_synapse_actions[] = {
+	/* Index must match with stm32_lptim_cnt_polarity[] (priv->polarity) */
+	[STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE] = SYNAPSE_ACTION_RISING_EDGE,
+	[STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE] = SYNAPSE_ACTION_FALLING_EDGE,
+	[STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES] = SYNAPSE_ACTION_BOTH_EDGES,
+	[STM32_LPTIM_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
+};
+
+static int stm32_lptim_cnt_read(struct counter_device *counter,
+				struct counter_count *count,
+				struct count_read_value *val)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+	u32 cnt;
+	int ret;
+
+	ret = regmap_read(priv->regmap, STM32_LPTIM_CNT, &cnt);
+	if (ret)
+		return ret;
+
+	count_read_value_set(val, COUNT_POSITION, &cnt);
+
+	return 0;
+}
+
+static int stm32_lptim_cnt_function_get(struct counter_device *counter,
+					struct counter_count *count,
+					size_t *function)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+
+	if (!priv->quadrature_mode) {
+		*function = STM32_LPTIM_COUNTER_INCREASE;
+		return 0;
+	}
+
+	if (priv->polarity == STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES) {
+		*function = STM32_LPTIM_ENCODER_BOTH_EDGE;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+static int stm32_lptim_cnt_function_set(struct counter_device *counter,
+					struct counter_count *count,
+					size_t function)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+
+	if (stm32_lptim_is_enabled(priv))
+		return -EBUSY;
+
+	switch (function) {
+	case STM32_LPTIM_COUNTER_INCREASE:
+		priv->quadrature_mode = 0;
+		return 0;
+	case STM32_LPTIM_ENCODER_BOTH_EDGE:
+		priv->quadrature_mode = 1;
+		priv->polarity = STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+static ssize_t stm32_lptim_cnt_enable_read(struct counter_device *counter,
+					   struct counter_count *count,
+					   void *private, char *buf)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+	int ret;
+
+	ret = stm32_lptim_is_enabled(priv);
+	if (ret < 0)
+		return ret;
+
+	return scnprintf(buf, PAGE_SIZE, "%u\n", ret);
+}
+
+static ssize_t stm32_lptim_cnt_enable_write(struct counter_device *counter,
+					    struct counter_count *count,
+					    void *private,
+					    const char *buf, size_t len)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+	bool enable;
+	int ret;
+
+	ret = kstrtobool(buf, &enable);
+	if (ret)
+		return ret;
+
+	/* Check nobody uses the timer, or already disabled/enabled */
+	ret = stm32_lptim_is_enabled(priv);
+	if ((ret < 0) || (!ret && !enable))
+		return ret;
+	if (enable && ret)
+		return -EBUSY;
+
+	ret = stm32_lptim_setup(priv, enable);
+	if (ret)
+		return ret;
+
+	ret = stm32_lptim_set_enable_state(priv, enable);
+	if (ret)
+		return ret;
+
+	return len;
+}
+
+static ssize_t stm32_lptim_cnt_ceiling_read(struct counter_device *counter,
+					    struct counter_count *count,
+					    void *private, char *buf)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+
+	return stm32_lptim_cnt_get_ceiling(priv, buf);
+}
+
+static ssize_t stm32_lptim_cnt_ceiling_write(struct counter_device *counter,
+					     struct counter_count *count,
+					     void *private,
+					     const char *buf, size_t len)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+
+	return stm32_lptim_cnt_set_ceiling(priv, buf, len);
+}
+
+static const struct counter_count_ext stm32_lptim_cnt_ext[] = {
+	{
+		.name = "enable",
+		.read = stm32_lptim_cnt_enable_read,
+		.write = stm32_lptim_cnt_enable_write
+	},
+	{
+		.name = "ceiling",
+		.read = stm32_lptim_cnt_ceiling_read,
+		.write = stm32_lptim_cnt_ceiling_write
+	},
+};
+
+static int stm32_lptim_cnt_action_get(struct counter_device *counter,
+				      struct counter_count *count,
+				      struct counter_synapse *synapse,
+				      size_t *action)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+	size_t function;
+	int err;
+
+	err = stm32_lptim_cnt_function_get(counter, count, &function);
+	if (err)
+		return err;
+
+	switch (function) {
+	case STM32_LPTIM_COUNTER_INCREASE:
+		/* LP Timer acts as up-counter on input 1 */
+		if (synapse->signal->id == count->synapses[0].signal->id)
+			*action = priv->polarity;
+		else
+			*action = STM32_LPTIM_SYNAPSE_ACTION_NONE;
+		return 0;
+	case STM32_LPTIM_ENCODER_BOTH_EDGE:
+		*action = priv->polarity;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+static int stm32_lptim_cnt_action_set(struct counter_device *counter,
+				      struct counter_count *count,
+				      struct counter_synapse *synapse,
+				      size_t action)
+{
+	struct stm32_lptim_cnt *const priv = counter->priv;
+	size_t function;
+	int err;
+
+	if (stm32_lptim_is_enabled(priv))
+		return -EBUSY;
+
+	err = stm32_lptim_cnt_function_get(counter, count, &function);
+	if (err)
+		return err;
+
+	/* only set polarity when in counter mode (on input 1) */
+	if (function == STM32_LPTIM_COUNTER_INCREASE
+	    && synapse->signal->id == count->synapses[0].signal->id) {
+		switch (action) {
+		case STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE:
+		case STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE:
+		case STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES:
+			priv->polarity = action;
+			return 0;
+		}
+	}
+
+	return -EINVAL;
+}
+
+static const struct counter_ops stm32_lptim_cnt_ops = {
+	.count_read = stm32_lptim_cnt_read,
+	.function_get = stm32_lptim_cnt_function_get,
+	.function_set = stm32_lptim_cnt_function_set,
+	.action_get = stm32_lptim_cnt_action_get,
+	.action_set = stm32_lptim_cnt_action_set,
+};
+
+static struct counter_signal stm32_lptim_cnt_signals[] = {
+	{
+		.id = 0,
+		.name = "Channel 1 Quadrature A"
+	},
+	{
+		.id = 1,
+		.name = "Channel 1 Quadrature B"
+	}
+};
+
+static struct counter_synapse stm32_lptim_cnt_synapses[] = {
+	{
+		.actions_list = stm32_lptim_cnt_synapse_actions,
+		.num_actions = ARRAY_SIZE(stm32_lptim_cnt_synapse_actions),
+		.signal = &stm32_lptim_cnt_signals[0]
+	},
+	{
+		.actions_list = stm32_lptim_cnt_synapse_actions,
+		.num_actions = ARRAY_SIZE(stm32_lptim_cnt_synapse_actions),
+		.signal = &stm32_lptim_cnt_signals[1]
+	}
+};
+
+/* LP timer with encoder */
+static struct counter_count stm32_lptim_enc_counts = {
+	.id = 0,
+	.name = "LPTimer Count",
+	.functions_list = stm32_lptim_cnt_functions,
+	.num_functions = ARRAY_SIZE(stm32_lptim_cnt_functions),
+	.synapses = stm32_lptim_cnt_synapses,
+	.num_synapses = ARRAY_SIZE(stm32_lptim_cnt_synapses),
+	.ext = stm32_lptim_cnt_ext,
+	.num_ext = ARRAY_SIZE(stm32_lptim_cnt_ext)
+};
+
+/* LP timer without encoder (counter only) */
+static struct counter_count stm32_lptim_in1_counts = {
+	.id = 0,
+	.name = "LPTimer Count",
+	.functions_list = stm32_lptim_cnt_functions,
+	.num_functions = 1,
+	.synapses = stm32_lptim_cnt_synapses,
+	.num_synapses = 1,
+	.ext = stm32_lptim_cnt_ext,
+	.num_ext = ARRAY_SIZE(stm32_lptim_cnt_ext)
+};
+
 static int stm32_lptim_cnt_probe(struct platform_device *pdev)
 {
 	struct stm32_lptimer *ddata = dev_get_drvdata(pdev->dev.parent);
 	struct stm32_lptim_cnt *priv;
 	struct iio_dev *indio_dev;
+	int ret;
 
 	if (IS_ERR_OR_NULL(ddata))
 		return -EINVAL;
@@ -344,8 +641,9 @@ static int stm32_lptim_cnt_probe(struct platform_device *pdev)
 	priv->dev = &pdev->dev;
 	priv->regmap = ddata->regmap;
 	priv->clk = ddata->clk;
-	priv->preset = STM32_LPTIM_MAX_ARR;
+	priv->ceiling = STM32_LPTIM_MAX_ARR;
 
+	/* Initialize IIO device */
 	indio_dev->name = dev_name(&pdev->dev);
 	indio_dev->dev.parent = &pdev->dev;
 	indio_dev->dev.of_node = pdev->dev.of_node;
@@ -356,9 +654,28 @@ static int stm32_lptim_cnt_probe(struct platform_device *pdev)
 		indio_dev->channels = &stm32_lptim_cnt_channels;
 	indio_dev->num_channels = 1;
 
+	/* Initialize Counter device */
+	priv->counter.name = dev_name(&pdev->dev);
+	priv->counter.parent = &pdev->dev;
+	priv->counter.ops = &stm32_lptim_cnt_ops;
+	if (ddata->has_encoder) {
+		priv->counter.counts = &stm32_lptim_enc_counts;
+		priv->counter.num_signals = ARRAY_SIZE(stm32_lptim_cnt_signals);
+	} else {
+		priv->counter.counts = &stm32_lptim_in1_counts;
+		priv->counter.num_signals = 1;
+	}
+	priv->counter.num_counts = 1;
+	priv->counter.signals = stm32_lptim_cnt_signals;
+	priv->counter.priv = priv;
+
 	platform_set_drvdata(pdev, priv);
 
-	return devm_iio_device_register(&pdev->dev, indio_dev);
+	ret = devm_iio_device_register(&pdev->dev, indio_dev);
+	if (ret)
+		return ret;
+
+	return devm_counter_register(&pdev->dev, &priv->counter);
 }
 
 static const struct of_device_id stm32_lptim_cnt_of_match[] = {
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index d08aeb41cd07..ac764840483a 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -74,7 +74,6 @@ source "drivers/iio/afe/Kconfig"
 source "drivers/iio/amplifiers/Kconfig"
 source "drivers/iio/chemical/Kconfig"
 source "drivers/iio/common/Kconfig"
-source "drivers/iio/counter/Kconfig"
 source "drivers/iio/dac/Kconfig"
 source "drivers/iio/dummy/Kconfig"
 source "drivers/iio/frequency/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index cb5993251381..bff682ad1cfb 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -20,7 +20,6 @@ obj-y += amplifiers/
 obj-y += buffer/
 obj-y += chemical/
 obj-y += common/
-obj-y += counter/
 obj-y += dac/
 obj-y += dummy/
 obj-y += gyro/
diff --git a/drivers/iio/counter/Kconfig b/drivers/iio/counter/Kconfig
deleted file mode 100644
index eeb358122cbe..000000000000
--- a/drivers/iio/counter/Kconfig
+++ /dev/null
@@ -1,17 +0,0 @@
-#
-# Counter devices
-#
-# When adding new entries keep the list in alphabetical order
-
-menu "Counters"
-
-config STM32_LPTIMER_CNT
-	tristate "STM32 LP Timer encoder counter driver"
-	depends on MFD_STM32_LPTIMER || COMPILE_TEST
-	help
-	  Select this option to enable STM32 Low-Power Timer quadrature encoder
-	  and counter driver.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called stm32-lptimer-cnt.
-endmenu
diff --git a/drivers/iio/counter/Makefile b/drivers/iio/counter/Makefile
deleted file mode 100644
index 93933ba49280..000000000000
--- a/drivers/iio/counter/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-#
-# Makefile for IIO counter devices
-#
-
-# When adding new entries keep the list in alphabetical order
-
-obj-$(CONFIG_STM32_LPTIMER_CNT)	+= stm32-lptimer-cnt.o
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 09/10] dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (7 preceding siblings ...)
  2018-06-21 21:08 ` [PATCH v7 08/10] counter: stm32-lptimer: add counter device William Breathitt Gray
@ 2018-06-21 21:08 ` William Breathitt Gray
  2018-07-05 21:13   ` Rob Herring
  2018-06-21 21:09 ` [PATCH v7 10/10] iio: counter: Add deprecation markings for IIO Counter attributes William Breathitt Gray
                   ` (2 subsequent siblings)
  11 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:08 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

From: Fabrice Gasnier <fabrice.gasnier@st.com>

The STM32 LP Timer counter driver now resides under the Counter
subsystem. This patch adjusts dt-bindings to account for the STM32
lptimer driver move.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 .../devicetree/bindings/{iio => }/counter/stm32-lptimer-cnt.txt | 0
 Documentation/devicetree/bindings/mfd/stm32-lptimer.txt         | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename Documentation/devicetree/bindings/{iio => }/counter/stm32-lptimer-cnt.txt (100%)

diff --git a/Documentation/devicetree/bindings/iio/counter/stm32-lptimer-cnt.txt b/Documentation/devicetree/bindings/counter/stm32-lptimer-cnt.txt
similarity index 100%
rename from Documentation/devicetree/bindings/iio/counter/stm32-lptimer-cnt.txt
rename to Documentation/devicetree/bindings/counter/stm32-lptimer-cnt.txt
diff --git a/Documentation/devicetree/bindings/mfd/stm32-lptimer.txt b/Documentation/devicetree/bindings/mfd/stm32-lptimer.txt
index 2a9ff29db9c9..fb54e4dad5b3 100644
--- a/Documentation/devicetree/bindings/mfd/stm32-lptimer.txt
+++ b/Documentation/devicetree/bindings/mfd/stm32-lptimer.txt
@@ -16,7 +16,7 @@ Required properties:
 
 Optional subnodes:
 - pwm:			See ../pwm/pwm-stm32-lp.txt
-- counter:		See ../iio/timer/stm32-lptimer-cnt.txt
+- counter:		See ../counter/stm32-lptimer-cnt.txt
 - trigger:		See ../iio/timer/stm32-lptimer-trigger.txt
 
 Example:
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH v7 10/10] iio: counter: Add deprecation markings for IIO Counter attributes
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (8 preceding siblings ...)
  2018-06-21 21:08 ` [PATCH v7 09/10] dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move William Breathitt Gray
@ 2018-06-21 21:09 ` William Breathitt Gray
  2018-06-22 17:10 ` [PATCH v7 00/10] Introduce the Counter subsystem Jonathan Cameron
  2018-07-02 18:13 ` David Lechner
  11 siblings, 0 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-06-21 21:09 UTC (permalink / raw)
  To: gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland, William Breathitt Gray

The IIO counter subdirectory is now superceded by the Counter subsystem.
This patch adds deprecation warnings to the documentation of the
relevant IIO Counter sysfs attributes.

Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-iio          |  8 ++++++++
 .../ABI/testing/sysfs-bus-iio-counter-104-quad-8 | 16 ++++++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index c7353030670a..fc50adf08e47 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1649,6 +1649,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_countY_raw
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Raw counter device counts from channel Y. For quadrature
 		counters, multiplication by an available [Y]_scale results in
 		the counts of a single quadrature signal phase from channel Y.
@@ -1657,6 +1659,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_indexY_raw
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Raw counter device index value from channel Y. This attribute
 		provides an absolute positional reference (e.g. a pulse once per
 		revolution) which may be used to home positional systems as
@@ -1666,6 +1670,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_count_count_direction_available
 KernelVersion:	4.12
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		A list of possible counting directions which are:
 		- "up"	: counter device is increasing.
 		- "down": counter device is decreasing.
@@ -1674,4 +1680,6 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_countY_count_direction
 KernelVersion:	4.12
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Raw counter device counters direction for channel Y.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8 b/Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
index 7fac2c268d9a..bac3d0d48b7b 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
+++ b/Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
@@ -6,6 +6,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_index_synchronous_mode_available
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Discrete set of available values for the respective counter
 		configuration are listed in this file.
 
@@ -13,6 +15,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_countY_count_mode
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Count mode for channel Y. Four count modes are available:
 		normal, range limit, non-recycle, and modulo-n. The preset value
 		for channel Y is used by the count mode where required.
@@ -47,6 +51,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_countY_noise_error
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Read-only attribute that indicates whether excessive noise is
 		present at the channel Y count inputs in quadrature clock mode;
 		irrelevant in non-quadrature clock mode.
@@ -55,6 +61,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_countY_preset
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		If the counter device supports preset registers, the preset
 		count for channel Y is provided by this attribute.
 
@@ -62,6 +70,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_countY_quadrature_mode
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Configure channel Y counter for non-quadrature or quadrature
 		clock mode. Selecting non-quadrature clock mode will disable
 		synchronous load mode. In quadrature clock mode, the channel Y
@@ -83,6 +93,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_countY_set_to_preset_on_index
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Whether to set channel Y counter with channel Y preset value
 		when channel Y index input is active, or continuously count.
 		Valid attribute values are boolean.
@@ -91,6 +103,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_indexY_index_polarity
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Active level of channel Y index input; irrelevant in
 		non-synchronous load mode.
 
@@ -98,6 +112,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_indexY_synchronous_mode
 KernelVersion:	4.10
 Contact:	linux-iio@vger.kernel.org
 Description:
+		This interface is deprecated; please use the Counter subsystem.
+
 		Configure channel Y counter for non-synchronous or synchronous
 		load mode. Synchronous load mode cannot be selected in
 		non-quadrature clock mode.
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 03/10] docs: Add Generic Counter interface documentation
  2018-06-21 21:07 ` [PATCH v7 03/10] docs: Add Generic Counter interface documentation William Breathitt Gray
@ 2018-06-22 16:51   ` Jonathan Cameron
  2018-07-02 19:37   ` [v7,03/10] " David Lechner
  2018-07-02 19:42   ` David Lechner
  2 siblings, 0 replies; 41+ messages in thread
From: Jonathan Cameron @ 2018-06-22 16:51 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Thu, 21 Jun 2018 17:07:30 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> This patch adds high-level documentation about the Generic Counter
> interface.
> 
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  Documentation/driver-api/generic-counter.rst | 342 +++++++++++++++++++
>  Documentation/driver-api/index.rst           |   1 +
>  MAINTAINERS                                  |   1 +
>  3 files changed, 344 insertions(+)
>  create mode 100644 Documentation/driver-api/generic-counter.rst
> 
> diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
> new file mode 100644
> index 000000000000..f51db893f595
> --- /dev/null
> +++ b/Documentation/driver-api/generic-counter.rst
> @@ -0,0 +1,342 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=========================
> +Generic Counter Interface
> +=========================
> +
> +Introduction
> +============
> +
> +Counter devices are prevalent within a diverse spectrum of industries.
> +The ubiquitous presence of these devices necessitates a common interface
> +and standard of interaction and exposure. This driver API attempts to
> +resolve the issue of duplicate code found among existing counter device
> +drivers by introducing a generic counter interface for consumption. The
> +Generic Counter interface enables drivers to support and expose a common
> +set of components and functionality present in counter devices.
> +
> +Theory
> +======
> +
> +Counter devices can vary greatly in design, but regardless of whether
> +some devices are quadrature encoder counters or tally counters, all
> +counter devices consist of a core set of components. This core set of
> +components, shared by all counter devices, is what forms the essence of
> +the Generic Counter interface.
> +
> +There are three core components to a counter:
> +
> +* Count:
> +  Count data for a set of Signals.
> +
> +* Signal:
> +  Input data that is evaluated by the counter to determine the count
> +  data.
> +
> +* Synapse:
> +  The association of a Signal with a respective Count.
> +
> +COUNT
> +-----
> +A Count represents the count data for a set of Signals. The Generic
> +Counter interface provides the following available count data types:
> +
> +* COUNT_POSITION:
> +  Unsigned integer value representing position.
> +
> +A Count has a count function mode which represents the update behavior
> +for the count data. The Generic Counter interface provides the following
> +available count function modes:
> +
> +* Increase:
> +  Accumulated count is incremented.
> +
> +* Decrease:
> +  Accumulated count is decremented.
> +
> +* Pulse-Direction:
> +  Rising edges on signal A updates the respective count. The input level
> +  of signal B determines direction.
> +
> +* Quadrature:
> +  A pair of quadrature encoding signals are evaluated to determine
> +  position and direction. The following Quadrature modes are available:
> +
> +  - x1 A:
> +    If direction is forward, rising edges on quadrature pair signal A
> +    updates the respective count; if the direction is backward, falling
> +    edges on quadrature pair signal A updates the respective count.
> +    Quadrature encoding determines the direction.
> +
> +  - x1 B:
> +    If direction is forward, rising edges on quadrature pair signal B
> +    updates the respective count; if the direction is backward, falling
> +    edges on quadrature pair signal B updates the respective count.
> +    Quadrature encoding determines the direction.
> +
> +  - x2 A:
> +    Any state transition on quadrature pair signal A updates the
> +    respective count. Quadrature encoding determines the direction.
> +
> +  - x2 B:
> +    Any state transition on quadrature pair signal B updates the
> +    respective count. Quadrature encoding determines the direction.
> +
> +  - x4:
> +    Any state transition on either quadrature pair signals updates the
> +    respective count. Quadrature encoding determines the direction.
> +
> +A Count has a set of one or more associated Signals.
> +
> +SIGNAL
> +------
> +A Signal represents a counter input data; this is the input data that is
> +evaluated by the counter to determine the count data; e.g. a quadrature
> +signal output line of a rotary encoder. Not all counter devices provide
> +user access to the Signal data.
> +
> +The Generic Counter interface provides the following available signal
> +data types for when the Signal data is available for user access:
> +
> +* SIGNAL_LEVEL:
> +  Signal line state level. The following states are possible:
> +
> +  - SIGNAL_LEVEL_LOW:
> +    Signal line is in a low state.
> +
> +  - SIGNAL_LEVEL_HIGH:
> +    Signal line is in a high state.
> +
> +A Signal may be associated with one or more Counts.
> +
> +SYNAPSE
> +-------
> +A Synapse represents the association of a Signal with a respective
> +Count. Signal data affects respective Count data, and the Synapse
> +represents this relationship.
> +
> +The Synapse action mode specifies the Signal data condition which
> +triggers the respective Count's count function evaluation to update the
> +count data. The Generic Counter interface provides the following
> +available action modes:
> +
> +* None:
> +  Signal does not trigger the count function. In Pulse-Direction count
> +  function mode, this Signal is evaluated as Direction.
> +
> +* Rising Edge:
> +  Low state transitions to high state.
> +
> +* Falling Edge:
> +  High state transitions to low state.
> +
> +* Both Edges:
> +  Any state transition.
> +
> +A counter is defined as a set of input signals associated with count
> +data that are generated by the evaluation of the state of the associated
> +input signals as defined by the respective count functions. Within the
> +context of the Generic Counter interface, a counter consists of Counts
> +each associated with a set of Signals, whose respective Synapse
> +instances represent the count function update conditions for the
> +associated Counts.
> +
> +Paradigm
> +========
> +
> +The most basic counter device may be expressed as a single Count
> +associated with a single Signal via a single Synapse. Take for example
> +a counter device which simply accumulates a count of rising edges on a
> +source input line::
> +
> +                Count                Synapse        Signal
> +                -----                -------        ------
> +        +---------------------+
> +        | Data: Count         |    Rising Edge     ________
> +        | Function: Increase  |  <-------------   / Source \
> +        |                     |                  ____________
> +        +---------------------+
> +
> +In this example, the Signal is a source input line with a pulsing
> +voltage, while the Count is a persistent count value which is repeatedly
> +incremented. The Signal is associated with the respective Count via a
> +Synapse. The increase function is triggered by the Signal data condition
> +specified by the Synapse -- in this case a rising edge condition on the
> +voltage input line. In summary, the counter device existence and
> +behavior is aptly represented by respective Count, Signal, and Synapse
> +components: a rising edge condition triggers an increase function on an
> +accumulating count datum.
> +
> +A counter device is not limited to a single Signal; in fact, in theory
> +many Signals may be associated with even a single Count. For example, a
> +quadrature encoder counter device can keep track of position based on
> +the states of two input lines::
> +
> +                   Count                 Synapse     Signal
> +                   -----                 -------     ------
> +        +-------------------------+
> +        | Data: Position          |    Both Edges     ___
> +        | Function: Quadrature x4 |  <------------   / A \
> +        |                         |                 _______
> +        |                         |
> +        |                         |    Both Edges     ___
> +        |                         |  <------------   / B \
> +        |                         |                 _______
> +        +-------------------------+
> +
> +In this example, two Signals (quadrature encoder lines A and B) are
> +associated with a single Count: a rising or falling edge on either A or
> +B triggers the "Quadrature x4" function which determines the direction
> +of movement and updates the respective position data. The "Quadrature
> +x4" function is likely implemented in the hardware of the quadrature
> +encoder counter device; the Count, Signals, and Synapses simply
> +represent this hardware behavior and functionality.
> +
> +Signals associated with the same Count can have differing Synapse action
> +mode conditions. For example, a quadrature encoder counter device
> +operating in a non-quadrature Pulse-Direction mode could have one input
> +line dedicated for movement and a second input line dedicated for
> +direction::
> +
> +                   Count                   Synapse      Signal
> +                   -----                   -------      ------
> +        +---------------------------+
> +        | Data: Position            |    Rising Edge     ___
> +        | Function: Pulse-Direction |  <-------------   / A \ (Movement)
> +        |                           |                  _______
> +        |                           |
> +        |                           |       None         ___
> +        |                           |  <-------------   / B \ (Direction)
> +        |                           |                  _______
> +        +---------------------------+
> +
> +Only Signal A triggers the "Pulse-Direction" update function, but the
> +instantaneous state of Signal B is still required in order to know the
> +direction so that the position data may be properly updated. Ultimately,
> +both Signals are associated with the same Count via two respective
> +Synapses, but only one Synapse has an active action mode condition which
> +triggers the respective count function while the other is left with a
> +"None" condition action mode to indicate its respective Signal's
> +availability for state evaluation despite its non-triggering mode.
> +
> +Keep in mind that the Signal, Synapse, and Count are abstract
> +representations which do not need to be closely married to their
> +respective physical sources. This allows the user of a counter to
> +divorce themselves from the nuances of physical components (such as
> +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/sys-bus-counter-generic-sysfs 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
> +==========
> +
> +Driver authors may utilize the Generic Counter interface in their code
> +by including the include/linux/counter.h header file. This header file
> +provides several core data structures, function prototypes, and macros
> +for defining a counter device.
> +
> +.. kernel-doc:: include/linux/counter.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/counter/generic-counter.c
> +   :export:
> +
> +Implementation
> +==============
> +
> +To support a counter device, a driver must first allocate the available
> +Counter Signals via counter_signal structures. These Signals should
> +be stored as an array and set to the signals array member of an
> +allocated counter_device structure before the Counter is registered to
> +the system.
> +
> +Counter Counts may be allocated via counter_count structures, and
> +respective Counter Signal associations (Synapses) made via
> +counter_synapse structures. Associated counter_synapse structures are
> +stored as an array and set to the the synapses array member of the
> +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.
> +
> +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 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.
> +
> +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/sys-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.
> diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
> index f4180e7c7ed5..e39a9fd3d8c9 100644
> --- a/Documentation/driver-api/index.rst
> +++ b/Documentation/driver-api/index.rst
> @@ -52,6 +52,7 @@ available subsections can be seen below.
>     slimbus
>     soundwire/index
>     fpga/index
> +   generic-counter
>  
>  .. only::  subproject and html
>  
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f8a47fd197a1..c7fd36500635 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3693,6 +3693,7 @@ M:	William Breathitt Gray <vilhelm.gray@gmail.com>
>  L:	linux-iio@vger.kernel.org
>  S:	Maintained
>  F:	Documentation/ABI/testing/sysfs-bus-counter*
> +F:	Documentation/driver-api/generic-counter.rst
>  F:	drivers/counter/
>  F:	include/linux/counter.h
>  



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 04/10] counter: 104-quad-8: Add Generic Counter interface support
  2018-06-21 21:07 ` [PATCH v7 04/10] counter: 104-quad-8: Add Generic Counter interface support William Breathitt Gray
@ 2018-06-22 16:57   ` Jonathan Cameron
  0 siblings, 0 replies; 41+ messages in thread
From: Jonathan Cameron @ 2018-06-22 16:57 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Thu, 21 Jun 2018 17:07:42 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> This patch adds support for the Generic Counter interface to the
> 104-QUAD-8 driver. The existing 104-QUAD-8 device interface should not
> be affected by this patch; all changes are intended as supplemental
> additions as perceived by the user.
> 
> Generic Counter Counts are created for the eight quadrature channel
> counts, as well as their respective quadrature A and B Signals (which
> are associated via respective Synapse structures) and respective index
> Signals.
> 
> The new Generic Counter interface sysfs attributes are intended to
> expose the same functionality and data available via the existing
> 104-QUAD-8 IIO device interface; the Generic Counter interface serves
> to provide the respective functionality and data in a standard way
> expected of counter devices.
> 
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>

On comment inline that the license changes should have been a separate patch
as it doesn't have anything to do with the move or additional subsystem
registration.  However, I don't care 'that much' if everything else is fine.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  MAINTAINERS                            |   4 +-
>  drivers/{iio => }/counter/104-quad-8.c | 782 ++++++++++++++++++++++++-
>  drivers/counter/Kconfig                |  21 +
>  drivers/counter/Makefile               |   2 +
>  drivers/iio/counter/Kconfig            |  17 -
>  drivers/iio/counter/Makefile           |   1 -
>  6 files changed, 784 insertions(+), 43 deletions(-)
>  rename drivers/{iio => }/counter/104-quad-8.c (44%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c7fd36500635..4083523699f3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -266,12 +266,12 @@ L:	linux-gpio@vger.kernel.org
>  S:	Maintained
>  F:	drivers/gpio/gpio-104-idio-16.c
>  
> -ACCES 104-QUAD-8 IIO DRIVER
> +ACCES 104-QUAD-8 DRIVER
>  M:	William Breathitt Gray <vilhelm.gray@gmail.com>
>  L:	linux-iio@vger.kernel.org
>  S:	Maintained
>  F:	Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
> -F:	drivers/iio/counter/104-quad-8.c
> +F:	drivers/counter/104-quad-8.c
>  
>  ACCES PCI-IDIO-16 GPIO DRIVER
>  M:	William Breathitt Gray <vilhelm.gray@gmail.com>
> diff --git a/drivers/iio/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> similarity index 44%
> rename from drivers/iio/counter/104-quad-8.c
> rename to drivers/counter/104-quad-8.c
> index 92be8d0f7735..bbd1640f3a51 100644
> --- a/drivers/iio/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -1,19 +1,12 @@
> +// SPDX-License-Identifier: GPL-2.0-only
>  /*
> - * IIO driver for the ACCES 104-QUAD-8
> + * Counter driver for the ACCES 104-QUAD-8
>   * Copyright (C) 2016 William Breathitt Gray
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License, version 2, as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * General Public License for more details.
> - *

I know it's trivial, bu I would have preferred this as a precursor patch
rather than rolled in here.

Meh, doesn't really matter though but if you 'are' respinning for another
reason then it would be nice to clean up ;)

>   * This driver supports the ACCES 104-QUAD-8 and ACCES 104-QUAD-4.
>   */
>  #include <linux/bitops.h>
> +#include <linux/counter.h>
>  #include <linux/device.h>
>  #include <linux/errno.h>
>  #include <linux/iio/iio.h>
> @@ -37,6 +30,7 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
>  
>  /**
>   * struct quad8_iio - IIO device private data structure
> + * @counter:		instance of the counter_device
>   * @preset:		array of preset values
>   * @count_mode:		array of count mode configurations
>   * @quadrature_mode:	array of quadrature mode configurations
> @@ -48,6 +42,7 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
>   * @base:		base port address of the IIO device
>   */
>  struct quad8_iio {
> +	struct counter_device counter;
>  	unsigned int preset[QUAD8_NUM_COUNTERS];
>  	unsigned int count_mode[QUAD8_NUM_COUNTERS];
>  	unsigned int quadrature_mode[QUAD8_NUM_COUNTERS];
> @@ -91,6 +86,10 @@ struct quad8_iio {
>  #define QUAD8_RLD_CNTR_OUT 0x10
>  #define QUAD8_CHAN_OP_ENABLE_COUNTERS 0x00
>  #define QUAD8_CHAN_OP_RESET_COUNTERS 0x01
> +#define QUAD8_CMR_QUADRATURE_X1 0x08
> +#define QUAD8_CMR_QUADRATURE_X2 0x10
> +#define QUAD8_CMR_QUADRATURE_X4 0x18
> +
>  
>  static int quad8_read_raw(struct iio_dev *indio_dev,
>  	struct iio_chan_spec const *chan, int *val, int *val2, long mask)
> @@ -346,13 +345,13 @@ static const char *const quad8_count_modes[] = {
>  };
>  
>  static int quad8_set_count_mode(struct iio_dev *indio_dev,
> -	const struct iio_chan_spec *chan, unsigned int count_mode)
> +	const struct iio_chan_spec *chan, unsigned int cnt_mode)
>  {
>  	struct quad8_iio *const priv = iio_priv(indio_dev);
> -	unsigned int mode_cfg = count_mode << 1;
> +	unsigned int mode_cfg = cnt_mode << 1;
>  	const int base_offset = priv->base + 2 * chan->channel + 1;
>  
> -	priv->count_mode[chan->channel] = count_mode;
> +	priv->count_mode[chan->channel] = cnt_mode;
>  
>  	/* Add quadrature mode configuration */
>  	if (priv->quadrature_mode[chan->channel])
> @@ -562,24 +561,746 @@ static const struct iio_chan_spec quad8_channels[] = {
>  	QUAD8_COUNT_CHAN(7), QUAD8_INDEX_CHAN(7)
>  };
>  
> +static int quad8_signal_read(struct counter_device *counter,
> +	struct counter_signal *signal, struct signal_read_value *val)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	unsigned int state;
> +	enum signal_level level;
> +
> +	/* Only Index signal levels can be read */
> +	if (signal->id < 16)
> +		return -EINVAL;
> +
> +	state = inb(priv->base + QUAD8_REG_INDEX_INPUT_LEVELS)
> +		& BIT(signal->id - 16);
> +
> +	level = (state) ? SIGNAL_LEVEL_HIGH : SIGNAL_LEVEL_LOW;
> +
> +	signal_read_value_set(val, SIGNAL_LEVEL, &level);
> +
> +	return 0;
> +}
> +
> +static int quad8_count_read(struct counter_device *counter,
> +	struct counter_count *count, struct count_read_value *val)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	const int base_offset = priv->base + 2 * count->id;
> +	unsigned int flags;
> +	unsigned int borrow;
> +	unsigned int carry;
> +	unsigned long position;
> +	int i;
> +
> +	flags = inb(base_offset + 1);
> +	borrow = flags & QUAD8_FLAG_BT;
> +	carry = !!(flags & QUAD8_FLAG_CT);
> +
> +	/* Borrow XOR Carry effectively doubles count range */
> +	position = (unsigned long)(borrow ^ carry) << 24;
> +
> +	/* Reset Byte Pointer; transfer Counter to Output Latch */
> +	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_CNTR_OUT,
> +	     base_offset + 1);
> +
> +	for (i = 0; i < 3; i++)
> +		position |= (unsigned long)inb(base_offset) << (8 * i);
> +
> +	count_read_value_set(val, COUNT_POSITION, &position);
> +
> +	return 0;
> +}
> +
> +static int quad8_count_write(struct counter_device *counter,
> +	struct counter_count *count, struct count_write_value *val)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	const int base_offset = priv->base + 2 * count->id;
> +	int err;
> +	unsigned long position;
> +	int i;
> +
> +	err = count_write_value_get(&position, COUNT_POSITION, val);
> +	if (err)
> +		return err;
> +
> +	/* Only 24-bit values are supported */
> +	if (position > 0xFFFFFF)
> +		return -EINVAL;
> +
> +	/* Reset Byte Pointer */
> +	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
> +
> +	/* Counter can only be set via Preset Register */
> +	for (i = 0; i < 3; i++)
> +		outb(position >> (8 * i), base_offset);
> +
> +	/* Transfer Preset Register to Counter */
> +	outb(QUAD8_CTR_RLD | QUAD8_RLD_PRESET_CNTR, base_offset + 1);
> +
> +	/* Reset Byte Pointer */
> +	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
> +
> +	/* Set Preset Register back to original value */
> +	position = priv->preset[count->id];
> +	for (i = 0; i < 3; i++)
> +		outb(position >> (8 * i), base_offset);
> +
> +	/* Reset Borrow, Carry, Compare, and Sign flags */
> +	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_FLAGS, base_offset + 1);
> +	/* Reset Error flag */
> +	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_E, base_offset + 1);
> +
> +	return 0;
> +}
> +
> +enum quad8_count_function {
> +	QUAD8_COUNT_FUNCTION_PULSE_DIRECTION = 0,
> +	QUAD8_COUNT_FUNCTION_QUADRATURE_X1,
> +	QUAD8_COUNT_FUNCTION_QUADRATURE_X2,
> +	QUAD8_COUNT_FUNCTION_QUADRATURE_X4
> +};
> +
> +static enum count_function quad8_count_functions_list[] = {
> +	[QUAD8_COUNT_FUNCTION_PULSE_DIRECTION] = COUNT_FUNCTION_PULSE_DIRECTION,
> +	[QUAD8_COUNT_FUNCTION_QUADRATURE_X1] = COUNT_FUNCTION_QUADRATURE_X1_A,
> +	[QUAD8_COUNT_FUNCTION_QUADRATURE_X2] = COUNT_FUNCTION_QUADRATURE_X2_A,
> +	[QUAD8_COUNT_FUNCTION_QUADRATURE_X4] = COUNT_FUNCTION_QUADRATURE_X4
> +};
> +
> +static int quad8_function_get(struct counter_device *counter,
> +	struct counter_count *count, size_t *function)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	const int id = count->id;
> +	const unsigned int quadrature_mode = priv->quadrature_mode[id];
> +	const unsigned int scale = priv->quadrature_scale[id];
> +
> +	if (quadrature_mode)
> +		switch (scale) {
> +		case 0:
> +			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X1;
> +			break;
> +		case 1:
> +			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X2;
> +			break;
> +		case 2:
> +			*function = QUAD8_COUNT_FUNCTION_QUADRATURE_X4;
> +			break;
> +		}
> +	else
> +		*function = QUAD8_COUNT_FUNCTION_PULSE_DIRECTION;
> +
> +	return 0;
> +}
> +
> +static int quad8_function_set(struct counter_device *counter,
> +	struct counter_count *count, size_t function)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	const int id = count->id;
> +	unsigned int *const quadrature_mode = priv->quadrature_mode + id;
> +	unsigned int *const scale = priv->quadrature_scale + id;
> +	unsigned int mode_cfg = priv->count_mode[id] << 1;
> +	unsigned int *const synchronous_mode = priv->synchronous_mode + id;
> +	const unsigned int idr_cfg = priv->index_polarity[id] << 1;
> +	const int base_offset = priv->base + 2 * id + 1;
> +
> +	if (function == QUAD8_COUNT_FUNCTION_PULSE_DIRECTION) {
> +		*quadrature_mode = 0;
> +
> +		/* Quadrature scaling only available in quadrature mode */
> +		*scale = 0;
> +
> +		/* Synchronous function not supported in non-quadrature mode */
> +		if (*synchronous_mode) {
> +			*synchronous_mode = 0;
> +			/* Disable synchronous function mode */
> +			outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
> +		}
> +	} else {
> +		*quadrature_mode = 1;
> +
> +		switch (function) {
> +		case QUAD8_COUNT_FUNCTION_QUADRATURE_X1:
> +			*scale = 0;
> +			mode_cfg |= QUAD8_CMR_QUADRATURE_X1;
> +			break;
> +		case QUAD8_COUNT_FUNCTION_QUADRATURE_X2:
> +			*scale = 1;
> +			mode_cfg |= QUAD8_CMR_QUADRATURE_X2;
> +			break;
> +		case QUAD8_COUNT_FUNCTION_QUADRATURE_X4:
> +			*scale = 2;
> +			mode_cfg |= QUAD8_CMR_QUADRATURE_X4;
> +			break;
> +		}
> +	}
> +
> +	/* Load mode configuration to Counter Mode Register */
> +	outb(QUAD8_CTR_CMR | mode_cfg, base_offset);
> +
> +	return 0;
> +}
> +
> +static void quad8_direction_get(struct counter_device *counter,
> +	struct counter_count *count, enum count_direction *direction)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	unsigned int ud_flag;
> +	const unsigned int flag_addr = priv->base + 2 * count->id + 1;
> +
> +	/* U/D flag: nonzero = up, zero = down */
> +	ud_flag = inb(flag_addr) & QUAD8_FLAG_UD;
> +
> +	*direction = (ud_flag) ? COUNT_DIRECTION_FORWARD :
> +		COUNT_DIRECTION_BACKWARD;
> +}
> +
> +enum quad8_synapse_action {
> +	QUAD8_SYNAPSE_ACTION_NONE = 0,
> +	QUAD8_SYNAPSE_ACTION_RISING_EDGE,
> +	QUAD8_SYNAPSE_ACTION_FALLING_EDGE,
> +	QUAD8_SYNAPSE_ACTION_BOTH_EDGES
> +};
> +
> +static enum synapse_action quad8_index_actions_list[] = {
> +	[QUAD8_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
> +	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = SYNAPSE_ACTION_RISING_EDGE
> +};
> +
> +static enum synapse_action quad8_synapse_actions_list[] = {
> +	[QUAD8_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
> +	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = SYNAPSE_ACTION_RISING_EDGE,
> +	[QUAD8_SYNAPSE_ACTION_FALLING_EDGE] = SYNAPSE_ACTION_FALLING_EDGE,
> +	[QUAD8_SYNAPSE_ACTION_BOTH_EDGES] = SYNAPSE_ACTION_BOTH_EDGES
> +};
> +
> +static int quad8_action_get(struct counter_device *counter,
> +	struct counter_count *count, struct counter_synapse *synapse,
> +	size_t *action)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	int err;
> +	size_t function = 0;
> +	const size_t signal_a_id = count->synapses[0].signal->id;
> +	enum count_direction direction;
> +
> +	/* Handle Index signals */
> +	if (synapse->signal->id >= 16) {
> +		if (priv->preset_enable[count->id])
> +			*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
> +		else
> +			*action = QUAD8_SYNAPSE_ACTION_NONE;
> +
> +		return 0;
> +	}
> +
> +	err = quad8_function_get(counter, count, &function);
> +	if (err)
> +		return err;
> +
> +	/* Default action mode */
> +	*action = QUAD8_SYNAPSE_ACTION_NONE;
> +
> +	/* Determine action mode based on current count function mode */
> +	switch (function) {
> +	case QUAD8_COUNT_FUNCTION_PULSE_DIRECTION:
> +		if (synapse->signal->id == signal_a_id)
> +			*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
> +		break;
> +	case QUAD8_COUNT_FUNCTION_QUADRATURE_X1:
> +		if (synapse->signal->id == signal_a_id) {
> +			quad8_direction_get(counter, count, &direction);
> +
> +			if (direction == COUNT_DIRECTION_FORWARD)
> +				*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
> +			else
> +				*action = QUAD8_SYNAPSE_ACTION_FALLING_EDGE;
> +		}
> +		break;
> +	case QUAD8_COUNT_FUNCTION_QUADRATURE_X2:
> +		if (synapse->signal->id == signal_a_id)
> +			*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
> +		break;
> +	case QUAD8_COUNT_FUNCTION_QUADRATURE_X4:
> +		*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
> +		break;
> +	}
> +
> +	return 0;
> +}
> +
> +const struct counter_ops quad8_ops = {
> +	.signal_read = quad8_signal_read,
> +	.count_read = quad8_count_read,
> +	.count_write = quad8_count_write,
> +	.function_get = quad8_function_get,
> +	.function_set = quad8_function_set,
> +	.action_get = quad8_action_get
> +};
> +
> +static int quad8_index_polarity_get(struct counter_device *counter,
> +	struct counter_signal *signal, size_t *index_polarity)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	const size_t channel_id = signal->id - 16;
> +
> +	*index_polarity = priv->index_polarity[channel_id];
> +
> +	return 0;
> +}
> +
> +static int quad8_index_polarity_set(struct counter_device *counter,
> +	struct counter_signal *signal, size_t index_polarity)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	const size_t channel_id = signal->id - 16;
> +	const unsigned int idr_cfg = priv->synchronous_mode[channel_id] |
> +		index_polarity << 1;
> +	const int base_offset = priv->base + 2 * channel_id + 1;
> +
> +	priv->index_polarity[channel_id] = index_polarity;
> +
> +	/* Load Index Control configuration to Index Control Register */
> +	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
> +
> +	return 0;
> +}
> +
> +static struct counter_signal_enum_ext quad8_index_pol_enum = {
> +	.items = quad8_index_polarity_modes,
> +	.num_items = ARRAY_SIZE(quad8_index_polarity_modes),
> +	.get = quad8_index_polarity_get,
> +	.set = quad8_index_polarity_set
> +};
> +
> +static int quad8_synchronous_mode_get(struct counter_device *counter,
> +	struct counter_signal *signal, size_t *synchronous_mode)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	const size_t channel_id = signal->id - 16;
> +
> +	*synchronous_mode = priv->synchronous_mode[channel_id];
> +
> +	return 0;
> +}
> +
> +static int quad8_synchronous_mode_set(struct counter_device *counter,
> +	struct counter_signal *signal, size_t synchronous_mode)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	const size_t channel_id = signal->id - 16;
> +	const unsigned int idr_cfg = synchronous_mode |
> +		priv->index_polarity[channel_id] << 1;
> +	const int base_offset = priv->base + 2 * channel_id + 1;
> +
> +	/* Index function must be non-synchronous in non-quadrature mode */
> +	if (synchronous_mode && !priv->quadrature_mode[channel_id])
> +		return -EINVAL;
> +
> +	priv->synchronous_mode[channel_id] = synchronous_mode;
> +
> +	/* Load Index Control configuration to Index Control Register */
> +	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
> +
> +	return 0;
> +}
> +
> +static struct counter_signal_enum_ext quad8_syn_mode_enum = {
> +	.items = quad8_synchronous_modes,
> +	.num_items = ARRAY_SIZE(quad8_synchronous_modes),
> +	.get = quad8_synchronous_mode_get,
> +	.set = quad8_synchronous_mode_set
> +};
> +
> +static ssize_t quad8_count_floor_read(struct counter_device *counter,
> +	struct counter_count *count, void *private, char *buf)
> +{
> +	/* Only a floor of 0 is supported */
> +	return snprintf(buf, PAGE_SIZE, "0\n");
> +}
> +
> +static int quad8_count_mode_get(struct counter_device *counter,
> +	struct counter_count *count, size_t *cnt_mode)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +
> +	/* Map 104-QUAD-8 count mode to Generic Counter count mode */
> +	switch (priv->count_mode[count->id]) {
> +	case 0:
> +		*cnt_mode = COUNT_MODE_NORMAL;
> +		break;
> +	case 1:
> +		*cnt_mode = COUNT_MODE_RANGE_LIMIT;
> +		break;
> +	case 2:
> +		*cnt_mode = COUNT_MODE_NON_RECYCLE;
> +		break;
> +	case 3:
> +		*cnt_mode = COUNT_MODE_MODULO_N;
> +		break;
> +	}
> +
> +	return 0;
> +}
> +
> +static int quad8_count_mode_set(struct counter_device *counter,
> +	struct counter_count *count, size_t cnt_mode)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	unsigned int mode_cfg;
> +	const int base_offset = priv->base + 2 * count->id + 1;
> +
> +	/* Map Generic Counter count mode to 104-QUAD-8 count mode */
> +	switch (cnt_mode) {
> +	case COUNT_MODE_NORMAL:
> +		cnt_mode = 0;
> +		break;
> +	case COUNT_MODE_RANGE_LIMIT:
> +		cnt_mode = 1;
> +		break;
> +	case COUNT_MODE_NON_RECYCLE:
> +		cnt_mode = 2;
> +		break;
> +	case COUNT_MODE_MODULO_N:
> +		cnt_mode = 3;
> +		break;
> +	}
> +
> +	priv->count_mode[count->id] = cnt_mode;
> +
> +	/* Set count mode configuration value */
> +	mode_cfg = cnt_mode << 1;
> +
> +	/* Add quadrature mode configuration */
> +	if (priv->quadrature_mode[count->id])
> +		mode_cfg |= (priv->quadrature_scale[count->id] + 1) << 3;
> +
> +	/* Load mode configuration to Counter Mode Register */
> +	outb(QUAD8_CTR_CMR | mode_cfg, base_offset);
> +
> +	return 0;
> +}
> +
> +static struct counter_count_enum_ext quad8_cnt_mode_enum = {
> +	.items = count_mode_str,
> +	.num_items = ARRAY_SIZE(count_mode_str),
> +	.get = quad8_count_mode_get,
> +	.set = quad8_count_mode_set
> +};
> +
> +static ssize_t quad8_count_direction_read(struct counter_device *counter,
> +	struct counter_count *count, void *priv, char *buf)
> +{
> +	enum count_direction dir;
> +
> +	quad8_direction_get(counter, count, &dir);
> +
> +	return scnprintf(buf, PAGE_SIZE, "%s\n", count_direction_str[dir]);
> +}
> +
> +static ssize_t quad8_count_enable_read(struct counter_device *counter,
> +	struct counter_count *count, void *private, char *buf)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +
> +	return scnprintf(buf, PAGE_SIZE, "%u\n", priv->ab_enable[count->id]);
> +}
> +
> +static ssize_t quad8_count_enable_write(struct counter_device *counter,
> +	struct counter_count *count, void *private, const char *buf, size_t len)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	const int base_offset = priv->base + 2 * count->id;
> +	int err;
> +	bool ab_enable;
> +	unsigned int ior_cfg;
> +
> +	err = kstrtobool(buf, &ab_enable);
> +	if (err)
> +		return err;
> +
> +	priv->ab_enable[count->id] = ab_enable;
> +
> +	ior_cfg = ab_enable | priv->preset_enable[count->id] << 1;
> +
> +	/* Load I/O control configuration */
> +	outb(QUAD8_CTR_IOR | ior_cfg, base_offset + 1);
> +
> +	return len;
> +}
> +
> +static int quad8_error_noise_get(struct counter_device *counter,
> +	struct counter_count *count, size_t *noise_error)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +	const int base_offset = priv->base + 2 * count->id + 1;
> +
> +	*noise_error = !!(inb(base_offset) & QUAD8_FLAG_E);
> +
> +	return 0;
> +}
> +
> +static struct counter_count_enum_ext quad8_error_noise_enum = {
> +	.items = quad8_noise_error_states,
> +	.num_items = ARRAY_SIZE(quad8_noise_error_states),
> +	.get = quad8_error_noise_get
> +};
> +
> +static ssize_t quad8_count_preset_read(struct counter_device *counter,
> +	struct counter_count *count, void *private, char *buf)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +
> +	return snprintf(buf, PAGE_SIZE, "%u\n", priv->preset[count->id]);
> +}
> +
> +static ssize_t quad8_count_preset_write(struct counter_device *counter,
> +	struct counter_count *count, void *private, const char *buf, size_t len)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	const int base_offset = priv->base + 2 * count->id;
> +	unsigned int preset;
> +	int ret;
> +	int i;
> +
> +	ret = kstrtouint(buf, 0, &preset);
> +	if (ret)
> +		return ret;
> +
> +	/* Only 24-bit values are supported */
> +	if (preset > 0xFFFFFF)
> +		return -EINVAL;
> +
> +	priv->preset[count->id] = preset;
> +
> +	/* Reset Byte Pointer */
> +	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
> +
> +	/* Set Preset Register */
> +	for (i = 0; i < 3; i++)
> +		outb(preset >> (8 * i), base_offset);
> +
> +	return len;
> +}
> +
> +static ssize_t quad8_count_ceiling_read(struct counter_device *counter,
> +	struct counter_count *count, void *private, char *buf)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +
> +	/* Range Limit and Modulo-N count modes use preset value as ceiling */
> +	switch (priv->count_mode[count->id]) {
> +	case 1:
> +	case 3:
> +		return quad8_count_preset_read(counter, count, private, buf);
> +	}
> +
> +	/* By default 0x1FFFFFF (25 bits unsigned) is maximum count */
> +	return snprintf(buf, PAGE_SIZE, "33554431\n");
> +}
> +
> +static ssize_t quad8_count_ceiling_write(struct counter_device *counter,
> +	struct counter_count *count, void *private, const char *buf, size_t len)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +
> +	/* Range Limit and Modulo-N count modes use preset value as ceiling */
> +	switch (priv->count_mode[count->id]) {
> +	case 1:
> +	case 3:
> +		return quad8_count_preset_write(counter, count, private, buf,
> +						len);
> +	}
> +
> +	return len;
> +}
> +
> +static ssize_t quad8_count_preset_enable_read(struct counter_device *counter,
> +	struct counter_count *count, void *private, char *buf)
> +{
> +	const struct quad8_iio *const priv = counter->priv;
> +
> +	return snprintf(buf, PAGE_SIZE, "%u\n",
> +		!priv->preset_enable[count->id]);
> +}
> +
> +static ssize_t quad8_count_preset_enable_write(struct counter_device *counter,
> +	struct counter_count *count, void *private, const char *buf, size_t len)
> +{
> +	struct quad8_iio *const priv = counter->priv;
> +	const int base_offset = priv->base + 2 * count->id + 1;
> +	bool preset_enable;
> +	int ret;
> +	unsigned int ior_cfg;
> +
> +	ret = kstrtobool(buf, &preset_enable);
> +	if (ret)
> +		return ret;
> +
> +	/* Preset enable is active low in Input/Output Control register */
> +	preset_enable = !preset_enable;
> +
> +	priv->preset_enable[count->id] = preset_enable;
> +
> +	ior_cfg = priv->ab_enable[count->id] | (unsigned int)preset_enable << 1;
> +
> +	/* Load I/O control configuration to Input / Output Control Register */
> +	outb(QUAD8_CTR_IOR | ior_cfg, base_offset);
> +
> +	return len;
> +}
> +
> +static const struct counter_signal_ext quad8_index_ext[] = {
> +	COUNTER_SIGNAL_ENUM("index_polarity", &quad8_index_pol_enum),
> +	COUNTER_SIGNAL_ENUM_AVAILABLE("index_polarity",	&quad8_index_pol_enum),
> +	COUNTER_SIGNAL_ENUM("synchronous_mode", &quad8_syn_mode_enum),
> +	COUNTER_SIGNAL_ENUM_AVAILABLE("synchronous_mode", &quad8_syn_mode_enum)
> +};
> +
> +#define	QUAD8_QUAD_SIGNAL(_id, _name) {	\
> +	.id = (_id),			\
> +	.name = (_name)			\
> +}
> +
> +#define	QUAD8_INDEX_SIGNAL(_id, _name) {	\
> +	.id = (_id),				\
> +	.name = (_name),			\
> +	.ext = quad8_index_ext,			\
> +	.num_ext = ARRAY_SIZE(quad8_index_ext)	\
> +}
> +
> +static struct counter_signal quad8_signals[] = {
> +	QUAD8_QUAD_SIGNAL(0, "Channel 1 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(1, "Channel 1 Quadrature B"),
> +	QUAD8_QUAD_SIGNAL(2, "Channel 2 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(3, "Channel 2 Quadrature B"),
> +	QUAD8_QUAD_SIGNAL(4, "Channel 3 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(5, "Channel 3 Quadrature B"),
> +	QUAD8_QUAD_SIGNAL(6, "Channel 4 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(7, "Channel 4 Quadrature B"),
> +	QUAD8_QUAD_SIGNAL(8, "Channel 5 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(9, "Channel 5 Quadrature B"),
> +	QUAD8_QUAD_SIGNAL(10, "Channel 6 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(11, "Channel 6 Quadrature B"),
> +	QUAD8_QUAD_SIGNAL(12, "Channel 7 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(13, "Channel 7 Quadrature B"),
> +	QUAD8_QUAD_SIGNAL(14, "Channel 8 Quadrature A"),
> +	QUAD8_QUAD_SIGNAL(15, "Channel 8 Quadrature B"),
> +	QUAD8_INDEX_SIGNAL(16, "Channel 1 Index"),
> +	QUAD8_INDEX_SIGNAL(17, "Channel 2 Index"),
> +	QUAD8_INDEX_SIGNAL(18, "Channel 3 Index"),
> +	QUAD8_INDEX_SIGNAL(19, "Channel 4 Index"),
> +	QUAD8_INDEX_SIGNAL(20, "Channel 5 Index"),
> +	QUAD8_INDEX_SIGNAL(21, "Channel 6 Index"),
> +	QUAD8_INDEX_SIGNAL(22, "Channel 7 Index"),
> +	QUAD8_INDEX_SIGNAL(23, "Channel 8 Index")
> +};
> +
> +#define QUAD8_COUNT_SYNAPSES(_id) {					\
> +	{								\
> +		.actions_list = quad8_synapse_actions_list,		\
> +		.num_actions = ARRAY_SIZE(quad8_synapse_actions_list),	\
> +		.signal = quad8_signals + 2 * (_id)			\
> +	},								\
> +	{								\
> +		.actions_list = quad8_synapse_actions_list,		\
> +		.num_actions = ARRAY_SIZE(quad8_synapse_actions_list),	\
> +		.signal = quad8_signals + 2 * (_id) + 1			\
> +	},								\
> +	{								\
> +		.actions_list = quad8_index_actions_list,		\
> +		.num_actions = ARRAY_SIZE(quad8_index_actions_list),	\
> +		.signal = quad8_signals + 2 * (_id) + 16		\
> +	}								\
> +}
> +
> +static struct counter_synapse quad8_count_synapses[][3] = {
> +	QUAD8_COUNT_SYNAPSES(0), QUAD8_COUNT_SYNAPSES(1),
> +	QUAD8_COUNT_SYNAPSES(2), QUAD8_COUNT_SYNAPSES(3),
> +	QUAD8_COUNT_SYNAPSES(4), QUAD8_COUNT_SYNAPSES(5),
> +	QUAD8_COUNT_SYNAPSES(6), QUAD8_COUNT_SYNAPSES(7)
> +};
> +
> +static const struct counter_count_ext quad8_count_ext[] = {
> +	{
> +		.name = "ceiling",
> +		.read = quad8_count_ceiling_read,
> +		.write = quad8_count_ceiling_write
> +	},
> +	{
> +		.name = "floor",
> +		.read = quad8_count_floor_read
> +	},
> +	COUNTER_COUNT_ENUM("count_mode", &quad8_cnt_mode_enum),
> +	COUNTER_COUNT_ENUM_AVAILABLE("count_mode", &quad8_cnt_mode_enum),
> +	{
> +		.name = "direction",
> +		.read = quad8_count_direction_read
> +	},
> +	{
> +		.name = "enable",
> +		.read = quad8_count_enable_read,
> +		.write = quad8_count_enable_write
> +	},
> +	COUNTER_COUNT_ENUM("error_noise", &quad8_error_noise_enum),
> +	COUNTER_COUNT_ENUM_AVAILABLE("error_noise", &quad8_error_noise_enum),
> +	{
> +		.name = "preset",
> +		.read = quad8_count_preset_read,
> +		.write = quad8_count_preset_write
> +	},
> +	{
> +		.name = "preset_enable",
> +		.read = quad8_count_preset_enable_read,
> +		.write = quad8_count_preset_enable_write
> +	}
> +};
> +
> +#define QUAD8_COUNT(_id, _cntname) {					\
> +	.id = (_id),							\
> +	.name = (_cntname),						\
> +	.functions_list = quad8_count_functions_list,			\
> +	.num_functions = ARRAY_SIZE(quad8_count_functions_list),	\
> +	.synapses = quad8_count_synapses[(_id)],			\
> +	.num_synapses =	2,						\
> +	.ext = quad8_count_ext,						\
> +	.num_ext = ARRAY_SIZE(quad8_count_ext)				\
> +}
> +
> +static struct counter_count quad8_counts[] = {
> +	QUAD8_COUNT(0, "Channel 1 Count"),
> +	QUAD8_COUNT(1, "Channel 2 Count"),
> +	QUAD8_COUNT(2, "Channel 3 Count"),
> +	QUAD8_COUNT(3, "Channel 4 Count"),
> +	QUAD8_COUNT(4, "Channel 5 Count"),
> +	QUAD8_COUNT(5, "Channel 6 Count"),
> +	QUAD8_COUNT(6, "Channel 7 Count"),
> +	QUAD8_COUNT(7, "Channel 8 Count")
> +};
> +
>  static int quad8_probe(struct device *dev, unsigned int id)
>  {
>  	struct iio_dev *indio_dev;
> -	struct quad8_iio *priv;
> +	struct quad8_iio *quad8iio;
>  	int i, j;
>  	unsigned int base_offset;
> +	int err;
>  
> -	indio_dev = devm_iio_device_alloc(dev, sizeof(*priv));
> -	if (!indio_dev)
> -		return -ENOMEM;
> -
> -	if (!devm_request_region(dev, base[id], QUAD8_EXTENT,
> -		dev_name(dev))) {
> +	if (!devm_request_region(dev, base[id], QUAD8_EXTENT, dev_name(dev))) {
>  		dev_err(dev, "Unable to lock port addresses (0x%X-0x%X)\n",
>  			base[id], base[id] + QUAD8_EXTENT);
>  		return -EBUSY;
>  	}
>  
> +	/* Allocate IIO device; this also allocates driver data structure */
> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*quad8iio));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	/* Initialize IIO device */
>  	indio_dev->info = &quad8_info;
>  	indio_dev->modes = INDIO_DIRECT_MODE;
>  	indio_dev->num_channels = ARRAY_SIZE(quad8_channels);
> @@ -587,8 +1308,17 @@ static int quad8_probe(struct device *dev, unsigned int id)
>  	indio_dev->name = dev_name(dev);
>  	indio_dev->dev.parent = dev;
>  
> -	priv = iio_priv(indio_dev);
> -	priv->base = base[id];
> +	/* Initialize Counter device and driver data */
> +	quad8iio = iio_priv(indio_dev);
> +	quad8iio->counter.name = dev_name(dev);
> +	quad8iio->counter.parent = dev;
> +	quad8iio->counter.ops = &quad8_ops;
> +	quad8iio->counter.counts = quad8_counts;
> +	quad8iio->counter.num_counts = ARRAY_SIZE(quad8_counts);
> +	quad8iio->counter.signals = quad8_signals;
> +	quad8iio->counter.num_signals = ARRAY_SIZE(quad8_signals);
> +	quad8iio->counter.priv = quad8iio;
> +	quad8iio->base = base[id];
>  
>  	/* Reset all counters and disable interrupt function */
>  	outb(QUAD8_CHAN_OP_RESET_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
> @@ -614,7 +1344,13 @@ static int quad8_probe(struct device *dev, unsigned int id)
>  	/* Enable all counters */
>  	outb(QUAD8_CHAN_OP_ENABLE_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
>  
> -	return devm_iio_device_register(dev, indio_dev);
> +	/* Register IIO device */
> +	err = devm_iio_device_register(dev, indio_dev);
> +	if (err)
> +		return err;
> +
> +	/* Register Counter device */
> +	return devm_counter_register(dev, &quad8iio->counter);
>  }
>  
>  static struct isa_driver quad8_driver = {
> diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
> index 65fa92abd5a4..7646f5df76f3 100644
> --- a/drivers/counter/Kconfig
> +++ b/drivers/counter/Kconfig
> @@ -16,3 +16,24 @@ menuconfig COUNTER
>  	  consumption. The Generic Counter interface enables drivers to support
>  	  and expose a common set of components and functionality present in
>  	  counter devices.
> +
> +if COUNTER
> +
> +config 104_QUAD_8
> +	tristate "ACCES 104-QUAD-8 driver"
> +	depends on PC104 && X86 && IIO
> +	select ISA_BUS_API
> +	help
> +	  Say yes here to build support for the ACCES 104-QUAD-8 quadrature
> +	  encoder counter/interface device family (104-QUAD-8, 104-QUAD-4).
> +
> +	  A counter's respective error flag may be cleared by performing a write
> +	  operation on the respective count value attribute. Although the
> +	  104-QUAD-8 counters have a 25-bit range, only the lower 24 bits may be
> +	  set, either directly or via the counter's preset attribute. Interrupts
> +	  are not supported by this driver.
> +
> +	  The base port addresses for the devices may be configured via the base
> +	  array module parameter.
> +
> +endif # COUNTER
> diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
> index ad1ba7109cdc..23a4f6263e45 100644
> --- a/drivers/counter/Makefile
> +++ b/drivers/counter/Makefile
> @@ -6,3 +6,5 @@
>  
>  obj-$(CONFIG_COUNTER) += counter.o
>  counter-y := generic-counter.o
> +
> +obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
> diff --git a/drivers/iio/counter/Kconfig b/drivers/iio/counter/Kconfig
> index bf1e559ad7cd..eeb358122cbe 100644
> --- a/drivers/iio/counter/Kconfig
> +++ b/drivers/iio/counter/Kconfig
> @@ -5,23 +5,6 @@
>  
>  menu "Counters"
>  
> -config 104_QUAD_8
> -	tristate "ACCES 104-QUAD-8 driver"
> -	depends on PC104 && X86
> -	select ISA_BUS_API
> -	help
> -	  Say yes here to build support for the ACCES 104-QUAD-8 quadrature
> -	  encoder counter/interface device family (104-QUAD-8, 104-QUAD-4).
> -
> -	  Performing a write to a counter's IIO_CHAN_INFO_RAW sets the counter and
> -	  also clears the counter's respective error flag. Although the counters
> -	  have a 25-bit range, only the lower 24 bits may be set, either directly
> -	  or via a counter's preset attribute. Interrupts are not supported by
> -	  this driver.
> -
> -	  The base port addresses for the devices may be configured via the base
> -	  array module parameter.
> -
>  config STM32_LPTIMER_CNT
>  	tristate "STM32 LP Timer encoder counter driver"
>  	depends on MFD_STM32_LPTIMER || COMPILE_TEST
> diff --git a/drivers/iio/counter/Makefile b/drivers/iio/counter/Makefile
> index 1b9a896eb488..93933ba49280 100644
> --- a/drivers/iio/counter/Makefile
> +++ b/drivers/iio/counter/Makefile
> @@ -4,5 +4,4 @@
>  
>  # When adding new entries keep the list in alphabetical order
>  
> -obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
>  obj-$(CONFIG_STM32_LPTIMER_CNT)	+= stm32-lptimer-cnt.o



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 05/10] counter: 104-quad-8: Documentation: Add Generic Counter sysfs documentation
  2018-06-21 21:08 ` [PATCH v7 05/10] counter: 104-quad-8: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
@ 2018-06-22 16:59   ` Jonathan Cameron
  0 siblings, 0 replies; 41+ messages in thread
From: Jonathan Cameron @ 2018-06-22 16:59 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Thu, 21 Jun 2018 17:08:08 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> This patch adds standard documentation for the Generic Counter interface
> userspace sysfs attributes of the 104-QUAD-8 driver.
> 
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
This stuff is very device specific obviously, but looks fine to me.

Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  .../ABI/testing/sysfs-bus-counter-104-quad-8  | 36 +++++++++++++++++++
>  MAINTAINERS                                   |  1 +
>  2 files changed, 37 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
> new file mode 100644
> index 000000000000..062637df3c78
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
> @@ -0,0 +1,36 @@
> +What:		/sys/bus/counter/devices/counterX/signalY/index_polarity
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Active level of index input Signal Y; irrelevant in
> +		non-synchronous load mode.
> +
> +What:		/sys/bus/counter/devices/counterX/signalY/index_polarity_available
> +What:		/sys/bus/counter/devices/counterX/signalY/synchronous_mode_available
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Discrete set of available values for the respective Signal Y
> +		configuration are listed in this file.
> +
> +What:		/sys/bus/counter/devices/counterX/signalY/synchronous_mode
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Configure the counter associated with Signal Y for
> +		non-synchronous or synchronous load mode. Synchronous load mode
> +		cannot be selected in non-quadrature (Pulse-Direction) clock
> +		mode.
> +
> +		Non-synchronous:
> +			A logic low level is the active level at this index
> +			input. The index function (as enabled via preset_enable)
> +			is performed directly on the active level of the index
> +			input.
> +
> +		Synchronous:
> +			Intended for interfacing with encoder Index output in
> +			quadrature clock mode. The active level is configured
> +			via index_polarity. The index function (as enabled via
> +			preset_enable) is performed synchronously with the
> +			quadrature clock on the active level of the index input.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4083523699f3..a06fd762f5d9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -270,6 +270,7 @@ ACCES 104-QUAD-8 DRIVER
>  M:	William Breathitt Gray <vilhelm.gray@gmail.com>
>  L:	linux-iio@vger.kernel.org
>  S:	Maintained
> +F:	Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
>  F:	Documentation/ABI/testing/sysfs-bus-iio-counter-104-quad-8
>  F:	drivers/counter/104-quad-8.c
>  



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 06/10] counter: Add STM32 Timer quadrature encoder
  2018-06-21 21:08 ` [PATCH v7 06/10] counter: Add STM32 Timer quadrature encoder William Breathitt Gray
@ 2018-06-22 17:03   ` Jonathan Cameron
  0 siblings, 0 replies; 41+ messages in thread
From: Jonathan Cameron @ 2018-06-22 17:03 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Thu, 21 Jun 2018 17:08:20 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> From: Benjamin Gaignard <benjamin.gaignard@st.com>
> 
> Implement counter part of the STM32 timer hardware block by using
> counter API. Hardware only supports X2 and X4 quadrature modes. A
> ceiling value can be set to define the maximum value reachable by the
> counter.
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> Co-authored-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  drivers/counter/Kconfig           |  10 +
>  drivers/counter/Makefile          |   1 +
>  drivers/counter/stm32-timer-cnt.c | 390 ++++++++++++++++++++++++++++++
>  3 files changed, 401 insertions(+)
>  create mode 100644 drivers/counter/stm32-timer-cnt.c
> 
> diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
> index 7646f5df76f3..fcfbaa935122 100644
> --- a/drivers/counter/Kconfig
> +++ b/drivers/counter/Kconfig
> @@ -36,4 +36,14 @@ config 104_QUAD_8
>  	  The base port addresses for the devices may be configured via the base
>  	  array module parameter.
>  
> +config STM32_TIMER_CNT
> +	tristate "STM32 Timer encoder counter driver"
> +	depends on MFD_STM32_TIMERS || COMPILE_TEST
> +	help
> +	  Select this option to enable STM32 Timer quadrature encoder
> +	  and counter driver.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called stm32-timer-cnt.
> +
>  endif # COUNTER
> diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
> index 23a4f6263e45..ff024259fb46 100644
> --- a/drivers/counter/Makefile
> +++ b/drivers/counter/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_COUNTER) += counter.o
>  counter-y := generic-counter.o
>  
>  obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
> +obj-$(CONFIG_STM32_TIMER_CNT)	+= stm32-timer-cnt.o
> diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
> new file mode 100644
> index 000000000000..0b15e729798b
> --- /dev/null
> +++ b/drivers/counter/stm32-timer-cnt.c
> @@ -0,0 +1,390 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * STM32 Timer Encoder and Counter driver
> + *
> + * Copyright (C) STMicroelectronics 2018
> + *
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
> + *

If I was being really really fussy - this blank line doesn't add
anything ;)

> + */
> +#include <linux/counter.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/types.h>
> +#include <linux/mfd/stm32-timers.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +
> +#define TIM_CCMR_CCXS	(BIT(8) | BIT(0))
> +#define TIM_CCMR_MASK	(TIM_CCMR_CC1S | TIM_CCMR_CC2S | \
> +			 TIM_CCMR_IC1F | TIM_CCMR_IC2F)
> +#define TIM_CCER_MASK	(TIM_CCER_CC1P | TIM_CCER_CC1NP | \
> +			 TIM_CCER_CC2P | TIM_CCER_CC2NP)
> +
> +struct stm32_timer_cnt {
> +	struct counter_device counter;
> +	struct regmap *regmap;
> +	struct clk *clk;
> +	u32 ceiling;
> +};
> +
> +/**
> + * stm32_count_function - enumerates stm32 timer counter encoder modes
> + * @STM32_COUNT_SLAVE_MODE_DISABLED: counts on internal clock when CEN=1
> + * @STM32_COUNT_ENCODER_MODE_1: counts TI1FP1 edges, depending on TI2FP2 level
> + * @STM32_COUNT_ENCODER_MODE_2: counts TI2FP2 edges, depending on TI1FP1 level
> + * @STM32_COUNT_ENCODER_MODE_3: counts on both TI1FP1 and TI2FP2 edges
> + */
> +enum stm32_count_function {
> +	STM32_COUNT_SLAVE_MODE_DISABLED = -1,
> +	STM32_COUNT_ENCODER_MODE_1,
> +	STM32_COUNT_ENCODER_MODE_2,
> +	STM32_COUNT_ENCODER_MODE_3,
> +};
> +
> +static enum count_function stm32_count_functions[] = {
> +	[STM32_COUNT_ENCODER_MODE_1] = COUNT_FUNCTION_QUADRATURE_X2_A,
> +	[STM32_COUNT_ENCODER_MODE_2] = COUNT_FUNCTION_QUADRATURE_X2_B,
> +	[STM32_COUNT_ENCODER_MODE_3] = COUNT_FUNCTION_QUADRATURE_X4,
> +};
> +
> +static int stm32_count_read(struct counter_device *counter,
> +			    struct counter_count *count,
> +			    struct count_read_value *val)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	u32 cnt;
> +
> +	regmap_read(priv->regmap, TIM_CNT, &cnt);
> +	count_read_value_set(val, COUNT_POSITION, &cnt);
> +
> +	return 0;
> +}
> +
> +static int stm32_count_write(struct counter_device *counter,
> +			     struct counter_count *count,
> +			     struct count_write_value *val)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	u32 cnt;
> +	int err;
> +
> +	err = count_write_value_get(&cnt, COUNT_POSITION, val);
> +	if (err)
> +		return err;
> +
> +	if (cnt > priv->ceiling)
> +		return -EINVAL;
> +
> +	return regmap_write(priv->regmap, TIM_CNT, cnt);
> +}
> +
> +static int stm32_count_function_get(struct counter_device *counter,
> +				    struct counter_count *count,
> +				    size_t *function)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	u32 smcr;
> +
> +	regmap_read(priv->regmap, TIM_SMCR, &smcr);
> +
> +	switch (smcr & TIM_SMCR_SMS) {
> +	case 1:
> +		*function = STM32_COUNT_ENCODER_MODE_1;
> +		return 0;
> +	case 2:
> +		*function = STM32_COUNT_ENCODER_MODE_2;
> +		return 0;
> +	case 3:
> +		*function = STM32_COUNT_ENCODER_MODE_3;
> +		return 0;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int stm32_count_function_set(struct counter_device *counter,
> +				    struct counter_count *count,
> +				    size_t function)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	u32 cr1, sms;
> +
> +	switch (function) {
> +	case STM32_COUNT_ENCODER_MODE_1:
> +		sms = 1;
> +		break;
> +	case STM32_COUNT_ENCODER_MODE_2:
> +		sms = 2;
> +		break;
> +	case STM32_COUNT_ENCODER_MODE_3:
> +		sms = 3;
> +		break;
> +	default:
> +		sms = 0;
> +		break;
> +	}
> +
> +	/* Store enable status */
> +	regmap_read(priv->regmap, TIM_CR1, &cr1);
> +
> +	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
> +
> +	/* TIMx_ARR register shouldn't be buffered (ARPE=0) */
> +	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, 0);
> +	regmap_write(priv->regmap, TIM_ARR, priv->ceiling);
> +
> +	regmap_update_bits(priv->regmap, TIM_SMCR, TIM_SMCR_SMS, sms);
> +
> +	/* Make sure that registers are updated */
> +	regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
> +
> +	/* Restore the enable status */
> +	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, cr1);
> +
> +	return 0;
> +}
> +
> +static ssize_t stm32_count_direction_read(struct counter_device *counter,
> +				      struct counter_count *count,
> +				      void *private, char *buf)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	const char *direction;
> +	u32 cr1;
> +
> +	regmap_read(priv->regmap, TIM_CR1, &cr1);
> +	direction = (cr1 & TIM_CR1_DIR) ? "backward" : "forward";
> +
> +	return scnprintf(buf, PAGE_SIZE, "%s\n", direction);
> +}
> +
> +static ssize_t stm32_count_ceiling_read(struct counter_device *counter,
> +					struct counter_count *count,
> +					void *private, char *buf)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	u32 arr;
> +
> +	regmap_read(priv->regmap, TIM_ARR, &arr);
> +
> +	return snprintf(buf, PAGE_SIZE, "%u\n", arr);
> +}
> +
> +static ssize_t stm32_count_ceiling_write(struct counter_device *counter,
> +					 struct counter_count *count,
> +					 void *private,
> +					 const char *buf, size_t len)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	unsigned int ceiling;
> +	int ret;
> +
> +	ret = kstrtouint(buf, 0, &ceiling);
> +	if (ret)
> +		return ret;
> +
> +	/* TIMx_ARR register shouldn't be buffered (ARPE=0) */
> +	regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, 0);
> +	regmap_write(priv->regmap, TIM_ARR, ceiling);
> +
> +	priv->ceiling = ceiling;
> +	return len;
> +}
> +
> +static ssize_t stm32_count_enable_read(struct counter_device *counter,
> +				       struct counter_count *count,
> +				       void *private, char *buf)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	u32 cr1;
> +
> +	regmap_read(priv->regmap, TIM_CR1, &cr1);
> +
> +	return scnprintf(buf, PAGE_SIZE, "%d\n", (bool)(cr1 & TIM_CR1_CEN));
> +}
> +
> +static ssize_t stm32_count_enable_write(struct counter_device *counter,
> +					struct counter_count *count,
> +					void *private,
> +					const char *buf, size_t len)
> +{
> +	struct stm32_timer_cnt *const priv = counter->priv;
> +	int err;
> +	u32 cr1;
> +	bool enable;
> +
> +	err = kstrtobool(buf, &enable);
> +	if (err)
> +		return err;
> +
> +	if (enable) {
> +		regmap_read(priv->regmap, TIM_CR1, &cr1);
> +			if (!(cr1 & TIM_CR1_CEN))
> +				clk_enable(priv->clk);
> +
> +		regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN,
> +				   TIM_CR1_CEN);
> +	} else {
> +		regmap_read(priv->regmap, TIM_CR1, &cr1);
> +		regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
> +		if (cr1 & TIM_CR1_CEN)
> +			clk_disable(priv->clk);
> +	}
> +
> +	return len;
> +}
> +
> +static const struct counter_count_ext stm32_count_ext[] = {
> +	{
> +		.name = "direction",
> +		.read = stm32_count_direction_read,
> +	},
> +	{
> +		.name = "enable",
> +		.read = stm32_count_enable_read,
> +		.write = stm32_count_enable_write
> +	},
> +	{
> +		.name = "ceiling",
> +		.read = stm32_count_ceiling_read,
> +		.write = stm32_count_ceiling_write
> +	},
> +};
> +
> +enum stm32_synapse_action {
> +	STM32_SYNAPSE_ACTION_NONE,
> +	STM32_SYNAPSE_ACTION_BOTH_EDGES
> +};
> +
> +static enum synapse_action stm32_synapse_actions[] = {
> +	[STM32_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
> +	[STM32_SYNAPSE_ACTION_BOTH_EDGES] = SYNAPSE_ACTION_BOTH_EDGES
> +};
> +
> +static int stm32_action_get(struct counter_device *counter,
> +			    struct counter_count *count,
> +			    struct counter_synapse *synapse,
> +			    size_t *action)
> +{
> +	size_t function;
> +	int err;
> +
> +	/* Default action mode (e.g. STM32_COUNT_SLAVE_MODE_DISABLED) */
> +	*action = STM32_SYNAPSE_ACTION_NONE;
> +
> +	err = stm32_count_function_get(counter, count, &function);
> +	if (err)
> +		return 0;
> +
> +	switch (function) {
> +	case STM32_COUNT_ENCODER_MODE_1:
> +		/* counts up/down on TI1FP1 edge depending on TI2FP2 level */
> +		if (synapse->signal->id == count->synapses[0].signal->id)
> +			*action = STM32_SYNAPSE_ACTION_BOTH_EDGES;
> +		break;
> +	case STM32_COUNT_ENCODER_MODE_2:
> +		/* counts up/down on TI2FP2 edge depending on TI1FP1 level */
> +		if (synapse->signal->id == count->synapses[1].signal->id)
> +			*action = STM32_SYNAPSE_ACTION_BOTH_EDGES;
> +		break;
> +	case STM32_COUNT_ENCODER_MODE_3:
> +		/* counts up/down on both TI1FP1 and TI2FP2 edges */
> +		*action = STM32_SYNAPSE_ACTION_BOTH_EDGES;
> +		break;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct counter_ops stm32_timer_cnt_ops = {
> +	.count_read = stm32_count_read,
> +	.count_write = stm32_count_write,
> +	.function_get = stm32_count_function_get,
> +	.function_set = stm32_count_function_set,
> +	.action_get = stm32_action_get,
> +};
> +
> +static struct counter_signal stm32_signals[] = {
> +	{
> +		.id = 0,
> +		.name = "Channel 1 Quadrature A"
> +	},
> +	{
> +		.id = 1,
> +		.name = "Channel 1 Quadrature B"
> +	}
> +};
> +
> +static struct counter_synapse stm32_count_synapses[] = {
> +	{
> +		.actions_list = stm32_synapse_actions,
> +		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
> +		.signal = &stm32_signals[0]
> +	},
> +	{
> +		.actions_list = stm32_synapse_actions,
> +		.num_actions = ARRAY_SIZE(stm32_synapse_actions),
> +		.signal = &stm32_signals[1]
> +	}
> +};
> +
> +static struct counter_count stm32_counts = {
> +	.id = 0,
> +	.name = "Channel 1 Count",
> +	.functions_list = stm32_count_functions,
> +	.num_functions = ARRAY_SIZE(stm32_count_functions),
> +	.synapses = stm32_count_synapses,
> +	.num_synapses = ARRAY_SIZE(stm32_count_synapses),
> +	.ext = stm32_count_ext,
> +	.num_ext = ARRAY_SIZE(stm32_count_ext)
> +};
> +
> +static int stm32_timer_cnt_probe(struct platform_device *pdev)
> +{
> +	struct stm32_timers *ddata = dev_get_drvdata(pdev->dev.parent);
> +	struct device *dev = &pdev->dev;
> +	struct stm32_timer_cnt *priv;
> +
> +	if (IS_ERR_OR_NULL(ddata))
> +		return -EINVAL;
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	priv->regmap = ddata->regmap;
> +	priv->clk = ddata->clk;
> +	priv->ceiling = ddata->max_arr;
> +
> +	priv->counter.name = dev_name(dev);
> +	priv->counter.parent = dev;
> +	priv->counter.ops = &stm32_timer_cnt_ops;
> +	priv->counter.counts = &stm32_counts;
> +	priv->counter.num_counts = 1;
> +	priv->counter.signals = stm32_signals;
> +	priv->counter.num_signals = ARRAY_SIZE(stm32_signals);
> +	priv->counter.priv = priv;
> +
> +	/* Register Counter device */
> +	return devm_counter_register(dev, &priv->counter);
> +}
> +
> +static const struct of_device_id stm32_timer_cnt_of_match[] = {
> +	{ .compatible = "st,stm32-timer-counter", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, stm32_timer_cnt_of_match);
> +
> +static struct platform_driver stm32_timer_cnt_driver = {
> +	.probe = stm32_timer_cnt_probe,
> +	.driver = {
> +		.name = "stm32-timer-counter",
> +		.of_match_table = stm32_timer_cnt_of_match,
> +	},
> +};
> +module_platform_driver(stm32_timer_cnt_driver);
> +
> +MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
> +MODULE_ALIAS("platform:stm32-timer-counter");
> +MODULE_DESCRIPTION("STMicroelectronics STM32 TIMER counter driver");
> +MODULE_LICENSE("GPL v2");



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 08/10] counter: stm32-lptimer: add counter device
  2018-06-21 21:08 ` [PATCH v7 08/10] counter: stm32-lptimer: add counter device William Breathitt Gray
@ 2018-06-22 17:06   ` Jonathan Cameron
  0 siblings, 0 replies; 41+ messages in thread
From: Jonathan Cameron @ 2018-06-22 17:06 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Thu, 21 Jun 2018 17:08:46 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> From: Fabrice Gasnier <fabrice.gasnier@st.com>
> 
> Add support for new counter device to stm32-lptimer.
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> ---
>  drivers/counter/Kconfig                       |  10 +
>  drivers/counter/Makefile                      |   1 +
>  drivers/{iio => }/counter/stm32-lptimer-cnt.c | 361 ++++++++++++++++--
>  drivers/iio/Kconfig                           |   1 -
>  drivers/iio/Makefile                          |   1 -
>  drivers/iio/counter/Kconfig                   |  17 -
>  drivers/iio/counter/Makefile                  |   7 -
>  7 files changed, 350 insertions(+), 48 deletions(-)
>  rename drivers/{iio => }/counter/stm32-lptimer-cnt.c (48%)
>  delete mode 100644 drivers/iio/counter/Kconfig
>  delete mode 100644 drivers/iio/counter/Makefile
> 
> diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
> index fcfbaa935122..fc072b97e5d2 100644
> --- a/drivers/counter/Kconfig
> +++ b/drivers/counter/Kconfig
> @@ -46,4 +46,14 @@ config STM32_TIMER_CNT
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called stm32-timer-cnt.
>  
> +config STM32_LPTIMER_CNT
> +	tristate "STM32 LP Timer encoder counter driver"
> +	depends on (MFD_STM32_LPTIMER || COMPILE_TEST) && IIO
> +	help
> +	  Select this option to enable STM32 Low-Power Timer quadrature encoder
> +	  and counter driver.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called stm32-lptimer-cnt.
> +
>  endif # COUNTER
> diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
> index ff024259fb46..8ff19b32022b 100644
> --- a/drivers/counter/Makefile
> +++ b/drivers/counter/Makefile
> @@ -9,3 +9,4 @@ counter-y := generic-counter.o
>  
>  obj-$(CONFIG_104_QUAD_8)	+= 104-quad-8.o
>  obj-$(CONFIG_STM32_TIMER_CNT)	+= stm32-timer-cnt.o
> +obj-$(CONFIG_STM32_LPTIMER_CNT)	+= stm32-lptimer-cnt.o
> diff --git a/drivers/iio/counter/stm32-lptimer-cnt.c b/drivers/counter/stm32-lptimer-cnt.c
> similarity index 48%
> rename from drivers/iio/counter/stm32-lptimer-cnt.c
> rename to drivers/counter/stm32-lptimer-cnt.c
> index 42fb8ba67090..80fc883f84e7 100644
> --- a/drivers/iio/counter/stm32-lptimer-cnt.c
> +++ b/drivers/counter/stm32-lptimer-cnt.c
> @@ -11,16 +11,18 @@
>   */
>  
>  #include <linux/bitfield.h>
> +#include <linux/counter.h>
>  #include <linux/iio/iio.h>
>  #include <linux/mfd/stm32-lptimer.h>
>  #include <linux/module.h>
>  #include <linux/platform_device.h>
>  
>  struct stm32_lptim_cnt {
> +	struct counter_device counter;
>  	struct device *dev;
>  	struct regmap *regmap;
>  	struct clk *clk;
> -	u32 preset;
> +	u32 ceiling;
>  	u32 polarity;
>  	u32 quadrature_mode;
>  };
> @@ -54,7 +56,7 @@ static int stm32_lptim_set_enable_state(struct stm32_lptim_cnt *priv,
>  	}
>  
>  	/* LP timer must be enabled before writing CMP & ARR */
> -	ret = regmap_write(priv->regmap, STM32_LPTIM_ARR, priv->preset);
> +	ret = regmap_write(priv->regmap, STM32_LPTIM_ARR, priv->ceiling);
>  	if (ret)
>  		return ret;
>  
> @@ -247,44 +249,57 @@ static const struct iio_enum stm32_lptim_cnt_polarity_en = {
>  	.set = stm32_lptim_cnt_set_polarity,
>  };
>  
> -static ssize_t stm32_lptim_cnt_get_preset(struct iio_dev *indio_dev,
> -					  uintptr_t private,
> -					  const struct iio_chan_spec *chan,
> -					  char *buf)
> +static ssize_t stm32_lptim_cnt_get_ceiling(struct stm32_lptim_cnt *priv,
> +					   char *buf)
>  {
> -	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
> -
> -	return snprintf(buf, PAGE_SIZE, "%u\n", priv->preset);
> +	return snprintf(buf, PAGE_SIZE, "%u\n", priv->ceiling);
>  }
>  
> -static ssize_t stm32_lptim_cnt_set_preset(struct iio_dev *indio_dev,
> -					  uintptr_t private,
> -					  const struct iio_chan_spec *chan,
> -					  const char *buf, size_t len)
> +static ssize_t stm32_lptim_cnt_set_ceiling(struct stm32_lptim_cnt *priv,
> +					   const char *buf, size_t len)
>  {
> -	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
>  	int ret;
>  
>  	if (stm32_lptim_is_enabled(priv))
>  		return -EBUSY;
>  
> -	ret = kstrtouint(buf, 0, &priv->preset);
> +	ret = kstrtouint(buf, 0, &priv->ceiling);
>  	if (ret)
>  		return ret;
>  
> -	if (priv->preset > STM32_LPTIM_MAX_ARR)
> +	if (priv->ceiling > STM32_LPTIM_MAX_ARR)
>  		return -EINVAL;
>  
>  	return len;
>  }
>  
> +static ssize_t stm32_lptim_cnt_get_preset_iio(struct iio_dev *indio_dev,
> +					      uintptr_t private,
> +					      const struct iio_chan_spec *chan,
> +					      char *buf)
> +{
> +	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
> +
> +	return stm32_lptim_cnt_get_ceiling(priv, buf);
> +}
> +
> +static ssize_t stm32_lptim_cnt_set_preset_iio(struct iio_dev *indio_dev,
> +					      uintptr_t private,
> +					      const struct iio_chan_spec *chan,
> +					      const char *buf, size_t len)
> +{
> +	struct stm32_lptim_cnt *priv = iio_priv(indio_dev);
> +
> +	return stm32_lptim_cnt_set_ceiling(priv, buf, len);
> +}
> +
>  /* LP timer with encoder */
>  static const struct iio_chan_spec_ext_info stm32_lptim_enc_ext_info[] = {
>  	{
>  		.name = "preset",
>  		.shared = IIO_SEPARATE,
> -		.read = stm32_lptim_cnt_get_preset,
> -		.write = stm32_lptim_cnt_set_preset,
> +		.read = stm32_lptim_cnt_get_preset_iio,
> +		.write = stm32_lptim_cnt_set_preset_iio,
>  	},
>  	IIO_ENUM("polarity", IIO_SEPARATE, &stm32_lptim_cnt_polarity_en),
>  	IIO_ENUM_AVAILABLE("polarity", &stm32_lptim_cnt_polarity_en),
> @@ -309,8 +324,8 @@ static const struct iio_chan_spec_ext_info stm32_lptim_cnt_ext_info[] = {
>  	{
>  		.name = "preset",
>  		.shared = IIO_SEPARATE,
> -		.read = stm32_lptim_cnt_get_preset,
> -		.write = stm32_lptim_cnt_set_preset,
> +		.read = stm32_lptim_cnt_get_preset_iio,
> +		.write = stm32_lptim_cnt_set_preset_iio,
>  	},
>  	IIO_ENUM("polarity", IIO_SEPARATE, &stm32_lptim_cnt_polarity_en),
>  	IIO_ENUM_AVAILABLE("polarity", &stm32_lptim_cnt_polarity_en),
> @@ -327,11 +342,293 @@ static const struct iio_chan_spec stm32_lptim_cnt_channels = {
>  	.indexed = 1,
>  };
>  
> +/**
> + * stm32_lptim_cnt_function - enumerates stm32 LPTimer counter & encoder modes
> + * @STM32_LPTIM_COUNTER_INCREASE: up count on IN1 rising, falling or both edges
> + * @STM32_LPTIM_ENCODER_BOTH_EDGE: count on both edges (IN1 & IN2 quadrature)
> + */
> +enum stm32_lptim_cnt_function {
> +	STM32_LPTIM_COUNTER_INCREASE,
> +	STM32_LPTIM_ENCODER_BOTH_EDGE,
> +};
> +
> +static enum count_function stm32_lptim_cnt_functions[] = {
> +	[STM32_LPTIM_COUNTER_INCREASE] = COUNT_FUNCTION_INCREASE,
> +	[STM32_LPTIM_ENCODER_BOTH_EDGE] = COUNT_FUNCTION_QUADRATURE_X4,
> +};
> +
> +enum stm32_lptim_synapse_action {
> +	STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE,
> +	STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE,
> +	STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES,
> +	STM32_LPTIM_SYNAPSE_ACTION_NONE,
> +};
> +
> +static enum synapse_action stm32_lptim_cnt_synapse_actions[] = {
> +	/* Index must match with stm32_lptim_cnt_polarity[] (priv->polarity) */
> +	[STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE] = SYNAPSE_ACTION_RISING_EDGE,
> +	[STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE] = SYNAPSE_ACTION_FALLING_EDGE,
> +	[STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES] = SYNAPSE_ACTION_BOTH_EDGES,
> +	[STM32_LPTIM_SYNAPSE_ACTION_NONE] = SYNAPSE_ACTION_NONE,
> +};
> +
> +static int stm32_lptim_cnt_read(struct counter_device *counter,
> +				struct counter_count *count,
> +				struct count_read_value *val)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +	u32 cnt;
> +	int ret;
> +
> +	ret = regmap_read(priv->regmap, STM32_LPTIM_CNT, &cnt);
> +	if (ret)
> +		return ret;
> +
> +	count_read_value_set(val, COUNT_POSITION, &cnt);
> +
> +	return 0;
> +}
> +
> +static int stm32_lptim_cnt_function_get(struct counter_device *counter,
> +					struct counter_count *count,
> +					size_t *function)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +
> +	if (!priv->quadrature_mode) {
> +		*function = STM32_LPTIM_COUNTER_INCREASE;
> +		return 0;
> +	}
> +
> +	if (priv->polarity == STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES) {
> +		*function = STM32_LPTIM_ENCODER_BOTH_EDGE;
> +		return 0;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int stm32_lptim_cnt_function_set(struct counter_device *counter,
> +					struct counter_count *count,
> +					size_t function)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +
> +	if (stm32_lptim_is_enabled(priv))
> +		return -EBUSY;
> +
> +	switch (function) {
> +	case STM32_LPTIM_COUNTER_INCREASE:
> +		priv->quadrature_mode = 0;
> +		return 0;
> +	case STM32_LPTIM_ENCODER_BOTH_EDGE:
> +		priv->quadrature_mode = 1;
> +		priv->polarity = STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES;
> +		return 0;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static ssize_t stm32_lptim_cnt_enable_read(struct counter_device *counter,
> +					   struct counter_count *count,
> +					   void *private, char *buf)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +	int ret;
> +
> +	ret = stm32_lptim_is_enabled(priv);
> +	if (ret < 0)
> +		return ret;
> +
> +	return scnprintf(buf, PAGE_SIZE, "%u\n", ret);
> +}
> +
> +static ssize_t stm32_lptim_cnt_enable_write(struct counter_device *counter,
> +					    struct counter_count *count,
> +					    void *private,
> +					    const char *buf, size_t len)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +	bool enable;
> +	int ret;
> +
> +	ret = kstrtobool(buf, &enable);
> +	if (ret)
> +		return ret;
> +
> +	/* Check nobody uses the timer, or already disabled/enabled */
> +	ret = stm32_lptim_is_enabled(priv);
> +	if ((ret < 0) || (!ret && !enable))
> +		return ret;
> +	if (enable && ret)
> +		return -EBUSY;
> +
> +	ret = stm32_lptim_setup(priv, enable);
> +	if (ret)
> +		return ret;
> +
> +	ret = stm32_lptim_set_enable_state(priv, enable);
> +	if (ret)
> +		return ret;
> +
> +	return len;
> +}
> +
> +static ssize_t stm32_lptim_cnt_ceiling_read(struct counter_device *counter,
> +					    struct counter_count *count,
> +					    void *private, char *buf)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +
> +	return stm32_lptim_cnt_get_ceiling(priv, buf);
> +}
> +
> +static ssize_t stm32_lptim_cnt_ceiling_write(struct counter_device *counter,
> +					     struct counter_count *count,
> +					     void *private,
> +					     const char *buf, size_t len)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +
> +	return stm32_lptim_cnt_set_ceiling(priv, buf, len);
> +}
> +
> +static const struct counter_count_ext stm32_lptim_cnt_ext[] = {
> +	{
> +		.name = "enable",
> +		.read = stm32_lptim_cnt_enable_read,
> +		.write = stm32_lptim_cnt_enable_write
> +	},
> +	{
> +		.name = "ceiling",
> +		.read = stm32_lptim_cnt_ceiling_read,
> +		.write = stm32_lptim_cnt_ceiling_write
> +	},
> +};
> +
> +static int stm32_lptim_cnt_action_get(struct counter_device *counter,
> +				      struct counter_count *count,
> +				      struct counter_synapse *synapse,
> +				      size_t *action)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +	size_t function;
> +	int err;
> +
> +	err = stm32_lptim_cnt_function_get(counter, count, &function);
> +	if (err)
> +		return err;
> +
> +	switch (function) {
> +	case STM32_LPTIM_COUNTER_INCREASE:
> +		/* LP Timer acts as up-counter on input 1 */
> +		if (synapse->signal->id == count->synapses[0].signal->id)
> +			*action = priv->polarity;
> +		else
> +			*action = STM32_LPTIM_SYNAPSE_ACTION_NONE;
> +		return 0;
> +	case STM32_LPTIM_ENCODER_BOTH_EDGE:
> +		*action = priv->polarity;
> +		return 0;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int stm32_lptim_cnt_action_set(struct counter_device *counter,
> +				      struct counter_count *count,
> +				      struct counter_synapse *synapse,
> +				      size_t action)
> +{
> +	struct stm32_lptim_cnt *const priv = counter->priv;
> +	size_t function;
> +	int err;
> +
> +	if (stm32_lptim_is_enabled(priv))
> +		return -EBUSY;
> +
> +	err = stm32_lptim_cnt_function_get(counter, count, &function);
> +	if (err)
> +		return err;
> +
> +	/* only set polarity when in counter mode (on input 1) */
> +	if (function == STM32_LPTIM_COUNTER_INCREASE
> +	    && synapse->signal->id == count->synapses[0].signal->id) {
> +		switch (action) {
> +		case STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE:
> +		case STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE:
> +		case STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES:
> +			priv->polarity = action;
> +			return 0;
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static const struct counter_ops stm32_lptim_cnt_ops = {
> +	.count_read = stm32_lptim_cnt_read,
> +	.function_get = stm32_lptim_cnt_function_get,
> +	.function_set = stm32_lptim_cnt_function_set,
> +	.action_get = stm32_lptim_cnt_action_get,
> +	.action_set = stm32_lptim_cnt_action_set,
> +};
> +
> +static struct counter_signal stm32_lptim_cnt_signals[] = {
> +	{
> +		.id = 0,
> +		.name = "Channel 1 Quadrature A"
> +	},
> +	{
> +		.id = 1,
> +		.name = "Channel 1 Quadrature B"
> +	}
> +};
> +
> +static struct counter_synapse stm32_lptim_cnt_synapses[] = {
> +	{
> +		.actions_list = stm32_lptim_cnt_synapse_actions,
> +		.num_actions = ARRAY_SIZE(stm32_lptim_cnt_synapse_actions),
> +		.signal = &stm32_lptim_cnt_signals[0]
> +	},
> +	{
> +		.actions_list = stm32_lptim_cnt_synapse_actions,
> +		.num_actions = ARRAY_SIZE(stm32_lptim_cnt_synapse_actions),
> +		.signal = &stm32_lptim_cnt_signals[1]
> +	}
> +};
> +
> +/* LP timer with encoder */
> +static struct counter_count stm32_lptim_enc_counts = {
> +	.id = 0,
> +	.name = "LPTimer Count",
> +	.functions_list = stm32_lptim_cnt_functions,
> +	.num_functions = ARRAY_SIZE(stm32_lptim_cnt_functions),
> +	.synapses = stm32_lptim_cnt_synapses,
> +	.num_synapses = ARRAY_SIZE(stm32_lptim_cnt_synapses),
> +	.ext = stm32_lptim_cnt_ext,
> +	.num_ext = ARRAY_SIZE(stm32_lptim_cnt_ext)
> +};
> +
> +/* LP timer without encoder (counter only) */
> +static struct counter_count stm32_lptim_in1_counts = {
> +	.id = 0,
> +	.name = "LPTimer Count",
> +	.functions_list = stm32_lptim_cnt_functions,
> +	.num_functions = 1,
> +	.synapses = stm32_lptim_cnt_synapses,
> +	.num_synapses = 1,
> +	.ext = stm32_lptim_cnt_ext,
> +	.num_ext = ARRAY_SIZE(stm32_lptim_cnt_ext)
> +};
> +
>  static int stm32_lptim_cnt_probe(struct platform_device *pdev)
>  {
>  	struct stm32_lptimer *ddata = dev_get_drvdata(pdev->dev.parent);
>  	struct stm32_lptim_cnt *priv;
>  	struct iio_dev *indio_dev;
> +	int ret;
>  
>  	if (IS_ERR_OR_NULL(ddata))
>  		return -EINVAL;
> @@ -344,8 +641,9 @@ static int stm32_lptim_cnt_probe(struct platform_device *pdev)
>  	priv->dev = &pdev->dev;
>  	priv->regmap = ddata->regmap;
>  	priv->clk = ddata->clk;
> -	priv->preset = STM32_LPTIM_MAX_ARR;
> +	priv->ceiling = STM32_LPTIM_MAX_ARR;
>  
> +	/* Initialize IIO device */
>  	indio_dev->name = dev_name(&pdev->dev);
>  	indio_dev->dev.parent = &pdev->dev;
>  	indio_dev->dev.of_node = pdev->dev.of_node;
> @@ -356,9 +654,28 @@ static int stm32_lptim_cnt_probe(struct platform_device *pdev)
>  		indio_dev->channels = &stm32_lptim_cnt_channels;
>  	indio_dev->num_channels = 1;
>  
> +	/* Initialize Counter device */
> +	priv->counter.name = dev_name(&pdev->dev);
> +	priv->counter.parent = &pdev->dev;
> +	priv->counter.ops = &stm32_lptim_cnt_ops;
> +	if (ddata->has_encoder) {
> +		priv->counter.counts = &stm32_lptim_enc_counts;
> +		priv->counter.num_signals = ARRAY_SIZE(stm32_lptim_cnt_signals);
> +	} else {
> +		priv->counter.counts = &stm32_lptim_in1_counts;
> +		priv->counter.num_signals = 1;
> +	}
> +	priv->counter.num_counts = 1;
> +	priv->counter.signals = stm32_lptim_cnt_signals;
> +	priv->counter.priv = priv;
> +
>  	platform_set_drvdata(pdev, priv);
>  
> -	return devm_iio_device_register(&pdev->dev, indio_dev);
> +	ret = devm_iio_device_register(&pdev->dev, indio_dev);
> +	if (ret)
> +		return ret;
> +
> +	return devm_counter_register(&pdev->dev, &priv->counter);
>  }
>  
>  static const struct of_device_id stm32_lptim_cnt_of_match[] = {
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index d08aeb41cd07..ac764840483a 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -74,7 +74,6 @@ source "drivers/iio/afe/Kconfig"
>  source "drivers/iio/amplifiers/Kconfig"
>  source "drivers/iio/chemical/Kconfig"
>  source "drivers/iio/common/Kconfig"
> -source "drivers/iio/counter/Kconfig"
>  source "drivers/iio/dac/Kconfig"
>  source "drivers/iio/dummy/Kconfig"
>  source "drivers/iio/frequency/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index cb5993251381..bff682ad1cfb 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -20,7 +20,6 @@ obj-y += amplifiers/
>  obj-y += buffer/
>  obj-y += chemical/
>  obj-y += common/
> -obj-y += counter/
>  obj-y += dac/
>  obj-y += dummy/
>  obj-y += gyro/
> diff --git a/drivers/iio/counter/Kconfig b/drivers/iio/counter/Kconfig
> deleted file mode 100644
> index eeb358122cbe..000000000000
> --- a/drivers/iio/counter/Kconfig
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -#
> -# Counter devices
> -#
> -# When adding new entries keep the list in alphabetical order
> -
> -menu "Counters"
> -
> -config STM32_LPTIMER_CNT
> -	tristate "STM32 LP Timer encoder counter driver"
> -	depends on MFD_STM32_LPTIMER || COMPILE_TEST
> -	help
> -	  Select this option to enable STM32 Low-Power Timer quadrature encoder
> -	  and counter driver.
> -
> -	  To compile this driver as a module, choose M here: the
> -	  module will be called stm32-lptimer-cnt.
> -endmenu
> diff --git a/drivers/iio/counter/Makefile b/drivers/iio/counter/Makefile
> deleted file mode 100644
> index 93933ba49280..000000000000
> --- a/drivers/iio/counter/Makefile
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -#
> -# Makefile for IIO counter devices
> -#
> -
> -# When adding new entries keep the list in alphabetical order
> -
> -obj-$(CONFIG_STM32_LPTIMER_CNT)	+= stm32-lptimer-cnt.o



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 00/10] Introduce the Counter subsystem
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (9 preceding siblings ...)
  2018-06-21 21:09 ` [PATCH v7 10/10] iio: counter: Add deprecation markings for IIO Counter attributes William Breathitt Gray
@ 2018-06-22 17:10 ` Jonathan Cameron
  2018-07-02 18:13 ` David Lechner
  11 siblings, 0 replies; 41+ messages in thread
From: Jonathan Cameron @ 2018-06-22 17:10 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, mark.rutland, devicetree, lars, benjamin.gaignard,
	linux-iio, linux-kernel, robh+dt, jic23, pmeerw, knaack.h,
	fabrice.gasnier, linux-arm-kernel

On Thu, 21 Jun 2018 17:06:46 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> Changes in v7:
>  - Use git-format-patch "-M" switch option to format renames properly
>    (apologies to Jonathan for reviewing delete/add pairs in past revs)
>  - Remove superfluous license boilerplate in favor of SPDX lines
>  - Rename functions to match <noun>_<action> naming convention; e.g.
>    signal_read_value_set, count_read_value_set, etc.
>  - Rename COUNT_POSITION_UNSIGNED to COUNT_POSITION, and remove
>    COUNT_POSITION_SIGNED
>  - Inline local variables that are only used once
>  - Remove COUNT_FUNCTION_QUADRATURE_X2_RISING and
>    COUNT_FUNCTION_QUADRATURE_X2_FALLING; these can be reintroduced when
>    a practical use-case is determined
>  - Explicitly free allocated attribute pointers on error in
>    counter_device_groups_prepare
>  - Remove pretty tab alignment for symbol declarations in counter.h
>  - Fix kernel-doc syntax typos ("groups_list" and "groups" missing ':')
>  - Clarify in kernel-doc comments the use of "val" parameter for the
>    signal_read, count_read, and count_write callbacks
>  - Cleanup Generic Counter attributes documentation (explain preset
>    registers, remove superfluous text, etc.)
>  - Cleanup Generic Counter driver API documentation (improve formatting
>    by reorganizing options into intended sections, fix typos, etc.)
>  - Utilize register defines to remove dependence on magic numbers in
>    104-QUAD-8 counter driver
>  - Update Kconfig description for the 104-QUAD-8 counter driver to
>    describe its Generic Counter interface
>  - Remove "mode" wording from STM32 Timer dt-bindings documentation;
>    STM32 Timer features a proper quadrature encoder counter device
>  - Fix typo in STM32 Timer documentation: IN1/IN2 pins are CH1/CH2 pins
> 
> Hi Greg,
> 
> This patchset is stabilizing so I hope you can take a look over it and
> advise. This patchset introduces the Counter subsystem and the Generic
> Counter driver API.
> 
> Last year, the STM32 LPTimer IIO driver authored by Fabrice Gasnier
> opened up a discussion about the architecture of the IIO Counter
> interface. The IIO Counter interface was developed to provide support
> for the 104-QUAD-8 IIO driver -- several new IIO attributes were
> implemented to support the functionality of the 104-QUAD-8 device. When
> the STM32 LPTimer IIO driver was introduced, it too attempted to utilize
> the IIO Counter interface to support the counter functionality of the
> STM32 LPTimer device.
> 
> However, there were some difficulties with the IIO Counter interface.
> For example, the 104-QUAD-8 device features a pulse-direction counter
> and quadrature encoder counter (which can be toggled via the
> quadrature_mode attribute), as well as three quadrature encoder modes
> (x1, x2, and x4) which are set via the existing IIO scale attribute.
> While this method works for the 104-QUAD-8, the STM32 LPTimer featured a
> slightly different Quadrature x2 mode with different state machine
> behavior -- as such there is ambiguity over what behavior "quadrature
> x2" represents in the IIO Counter interface.
> 
> I decided to strip down these devices to arrive at the core essence of
> what constitutes a "counter device" and therefore design a "generic
> counter" abstraction to better represent these devices and prevent the
> ambiguity we discovered with the existing IIO Counter interface. This
> abstraction became the Generic Counter paradigm, which is explained in
> detail within the Documentation/driver-api/generic-counter.rst file
> introduced by this patchset.
> 
> Initially we attempted to further extend the IIO Counter interface in
> order to integrate the Generic Counter API as part of the IIO subsystem,
> but the outcome wasn't as clean as we desired. The results of our
> efforts proved to grow increasingly complicated, sparsed with hacks, and
> more often than not fought with the IIO subsystem rather than
> complemented it. I decided to separate the Generic Counter API from the
> IIO subsystem, and give it its own Counter subsystem in which to reside.
> This allowed us to streamline development and avoid jeopardizing the
> integrity of the IIO subsystem (we no longer have to bend the IIO API to
> support our needs, but can instead implement the necessary
> functionalities in the Counter subsystem as required).
> 
> The Counter subsystem has three consuming drivers thus far: two ported
> from the IIO subsystem (104-QUAD-8 and STM32 LPTimer counter) and one
> unique to the Counter subsystem (STM32 Timer counter). In userspace, the
> Generic Counter interface is rather intuitive:
> 
>     * /sys/bus/counter/devices/
>       - enumerated directories for counter devices
>     * /sys/bus/counter/devices/counterX/
>       - attributes for counterX where X is the enumeration ID
>     * /sys/bus/counter/devices/counterX/signalY
>       - attributes for signal Y where Y is the enumeration ID
>     * /sys/bus/counter/devices/counterX/countY
>       - attributes for count Y where Y is the enumeration ID
> 
> Although at this point the Counter subsystem is functionally separate
> from the IIO subsystem, I believe it would be prudent to merge this
> introduction patchset via the IIO tree due to the historical context of
> these counter drivers and the development of this patchset. Are there
> any additions or changes you believe I should make to this patchset
> going forward?
> 

I'm fine with this approach if Greg doesn't mind.  I've explicitly
given reviewed-by / acks where I normally would just sign off whilst
applying to make it clear I'm happy if we do decide on a different
route.  Has the side effect that I know which ones I liked last time
on a slow brewing complex set like this one.

Anyhow, we'll figure out the long term plan after these are in.
I'm happy with continuing to route through the IIO tree as this isn't
(I think) going to be a particularly busy as subsystems go.

Other options are fine with me as well!

Well done on getting it to this state.

Jonathan

> Sincerely,
> 
> William Breathitt Gray
> 
> Benjamin Gaignard (2):
>   counter: Add STM32 Timer quadrature encoder
>   dt-bindings: counter: Document stm32 quadrature encoder
> 
> Fabrice Gasnier (2):
>   counter: stm32-lptimer: add counter device
>   dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move
> 
> William Breathitt Gray (6):
>   counter: Introduce the Generic Counter interface
>   counter: Documentation: Add Generic Counter sysfs documentation
>   docs: Add Generic Counter interface documentation
>   counter: 104-quad-8: Add Generic Counter interface support
>   counter: 104-quad-8: Documentation: Add Generic Counter sysfs
>     documentation
>   iio: counter: Add deprecation markings for IIO Counter attributes
> 
>  Documentation/ABI/testing/sysfs-bus-counter   |  230 +++
>  .../ABI/testing/sysfs-bus-counter-104-quad-8  |   36 +
>  Documentation/ABI/testing/sysfs-bus-iio       |    8 +
>  .../testing/sysfs-bus-iio-counter-104-quad-8  |   16 +
>  .../{iio => }/counter/stm32-lptimer-cnt.txt   |    0
>  .../bindings/counter/stm32-timer-cnt.txt      |   31 +
>  .../devicetree/bindings/mfd/stm32-lptimer.txt |    2 +-
>  .../devicetree/bindings/mfd/stm32-timers.txt  |    7 +
>  Documentation/driver-api/generic-counter.rst  |  342 ++++
>  Documentation/driver-api/index.rst            |    1 +
>  MAINTAINERS                                   |   14 +-
>  drivers/Kconfig                               |    2 +
>  drivers/Makefile                              |    1 +
>  drivers/{iio => }/counter/104-quad-8.c        |  782 ++++++++-
>  drivers/counter/Kconfig                       |   59 +
>  drivers/{iio => }/counter/Makefile            |    6 +-
>  drivers/counter/generic-counter.c             | 1519 +++++++++++++++++
>  drivers/{iio => }/counter/stm32-lptimer-cnt.c |  361 +++-
>  drivers/counter/stm32-timer-cnt.c             |  390 +++++
>  drivers/iio/Kconfig                           |    1 -
>  drivers/iio/Makefile                          |    1 -
>  drivers/iio/counter/Kconfig                   |   34 -
>  include/linux/counter.h                       |  534 ++++++
>  23 files changed, 4292 insertions(+), 85 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-counter
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
>  rename Documentation/devicetree/bindings/{iio => }/counter/stm32-lptimer-cnt.txt (100%)
>  create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>  create mode 100644 Documentation/driver-api/generic-counter.rst
>  rename drivers/{iio => }/counter/104-quad-8.c (44%)
>  create mode 100644 drivers/counter/Kconfig
>  rename drivers/{iio => }/counter/Makefile (52%)
>  create mode 100644 drivers/counter/generic-counter.c
>  rename drivers/{iio => }/counter/stm32-lptimer-cnt.c (48%)
>  create mode 100644 drivers/counter/stm32-timer-cnt.c
>  delete mode 100644 drivers/iio/counter/Kconfig
>  create mode 100644 include/linux/counter.h
> 



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 00/10] Introduce the Counter subsystem
  2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
                   ` (10 preceding siblings ...)
  2018-06-22 17:10 ` [PATCH v7 00/10] Introduce the Counter subsystem Jonathan Cameron
@ 2018-07-02 18:13 ` David Lechner
  2018-07-03  2:48   ` William Breathitt Gray
  11 siblings, 1 reply; 41+ messages in thread
From: David Lechner @ 2018-07-02 18:13 UTC (permalink / raw)
  To: William Breathitt Gray, gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On 06/21/2018 04:06 PM, William Breathitt Gray wrote:
> I decided to strip down these devices to arrive at the core essence of
> what constitutes a "counter device" and therefore design a "generic
> counter" abstraction to better represent these devices and prevent the
> ambiguity we discovered with the existing IIO Counter interface. This
> abstraction became the Generic Counter paradigm, which is explained in
> detail within the Documentation/driver-api/generic-counter.rst file
> introduced by this patchset.

I'm curious if you have given any thought to the time aspect of counters.
I am interested in the rate at which the counters are counting (e.g. how
many counts per second). I realize that you can calculate this in
userspace or in the kernel using the system timer, but it is not very
accurate since Linux is not a realtime OS. So, I would like to get the
rate directly from the hardware. For example, the TI eQEP[1], like the
one found in BeagleBones, has a couple ways of measuring time (see link
for details).

[1]: http://www.ti.com/lit/ug/sprug05a/sprug05a.pdf


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7, 02/10] counter: Documentation: Add Generic Counter sysfs documentation
  2018-06-21 21:07 ` [PATCH v7 02/10] counter: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
@ 2018-07-02 19:11   ` David Lechner
  2018-07-03 14:04     ` William Breathitt Gray
  0 siblings, 1 reply; 41+ messages in thread
From: David Lechner @ 2018-07-02 19:11 UTC (permalink / raw)
  To: William Breathitt Gray, gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
> This patch adds standard documentation for the userspace sysfs
> attributes of the Generic Counter interface.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
>   Documentation/ABI/testing/sysfs-bus-counter | 230 ++++++++++++++++++++
>   MAINTAINERS                                 |   1 +
>   2 files changed, 231 insertions(+)
>   create mode 100644 Documentation/ABI/testing/sysfs-bus-counter
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter
> new file mode 100644
> index 000000000000..0bb0dce67bf8
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-counter
> @@ -0,0 +1,230 @@
> +What:		/sys/bus/counter/devices/counterX/countY/count
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Count data of Count Y represented as a string.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/ceiling
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Count value ceiling for Count Y. This is the upper limit for the
> +		respective counter.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/floor
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Count value floor for Count Y. This is the lower limit for the
> +		respective counter.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/count_mode
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Count mode for channel Y. The ceiling and floor values for
> +		Count Y are used by the count mode where required. The following
> +		count modes are available:
> +
> +		Normal:
> +			Counting is continuous in either direction.
> +
> +		Range Limit:
> +			An upper or lower limit is set, mimicking limit switches
> +			in the mechanical counterpart. The upper limit is set to
> +			the Count Y ceiling value, while the lower limit is set
> +			to the Count Y floor value. The counter freezes at
> +			count = ceiling when counting up, and at count = floor
> +			when counting down. At either of these limits, the
> +			counting is resumed only when the count direction is
> +			reversed.
> +
> +		Non-Recycle:
> +			The counter is disabled whenever a counter overflow or
> +			underflow takes place. The counter is re-enabled when a
> +			new count value is loaded to the counter via a preset
> +			operation or direct write.
> +
> +		Modulo-N:
> +			A count value boundary is set between the Count Y floor
> +			value and the Count Y ceiling value. The counter is
> +			reset to the Cunt Y floor value at count = ceiling when
> +			counting up, while the counter is set to the Count Y
> +			ceiling value at count = floor when counting down; the
> +			counter does not freeze at the boundary points, but
> +			counts continuously throughout.
> +

This might be a bit misleading since the values returned are all lower case,
e.g. "rising edge", whereas they are listed here in Title Case.

> +What:		/sys/bus/counter/devices/counterX/countY/count_mode_available
> +What:		/sys/bus/counter/devices/counterX/countY/error_noise_available
> +What:		/sys/bus/counter/devices/counterX/countY/function_available
> +What:		/sys/bus/counter/devices/counterX/countY/signalZ_action_available
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Discrete set of available values for the respective Count Y
> +		configuration are listed in this file. Values are delineated by
> +		newline characters.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/direction
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute that indicates the count direction of Count
> +		Y. Two count directions are available: forward and backward.
> +
> +		Some counter devices are able to determine the direction of
> +		their counting. For example, quadrature encoding counters can
> +		determine the direction of movement by evaluating the leading
> +		phase of the respective A and B quadrature encoding signals.
> +		This attribute exposes such count directions.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/enable
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Whether channel Y counter is enabled. Valid attribute values are
> +		boolean.
> +
> +		This attribute is intended to serve as a pause/unpause mechanism
> +		for Count Y. Suppose a counter device is used to count the total
> +		movement of a conveyor belt: this attribute allows an operator
> +		to temporarily pause the counter, service the conveyor belt,
> +		and then finally unpause the counter to continue where it had
> +		left off.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/error_noise
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute that indicates whether excessive noise is
> +		present at the channel Y counter inputs.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/function
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Count function mode of Count Y; count function evaluation is
> +		triggered by conditions specified by the Count Y signalZ_action
> +		attributes. The following count functions are available:
> +
> +		Increase:
> +			Accumulated count is incremented.
> +
> +		Decrease:
> +			Accumulated count is decremented.
> +
> +		Pulse-Direction:
> +			Rising edges on signal A updates the respective count.
> +			The input level of signal B determines direction.
> +
> +		Quadrature x1 A:
> +			If direction is forward, rising edges on quadrature pair
> +			signal A updates the respective count; if the direction
> +			is backward, falling edges on quadrature pair signal A
> +			updates the respective count. Quadrature encoding
> +			determines the direction.
> +
> +		Quadrature x1 B:
> +			If direction is forward, rising edges on quadrature pair
> +			signal B updates the respective count; if the direction
> +			is backward, falling edges on quadrature pair signal B
> +			updates the respective count. Quadrature encoding
> +			determines the direction.
> +
> +		Quadrature x2 A:
> +			Any state transition on quadrature pair signal A updates
> +			the respective count. Quadrature encoding determines the
> +			direction.
> +
> +		Quadrature x2 B:
> +			Any state transition on quadrature pair signal B updates
> +			the respective count. Quadrature encoding determines the
> +			direction.
> +
> +		Quadrature x4:
> +			Any state transition on either quadrature pair signals
> +			updates	the respective count. Quadrature encoding
> +			determines the direction.
> +
Same here about lower case vs. Title Case.

> +What:		/sys/bus/counter/devices/counterX/countY/name
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute that indicates the device-specific name of
> +		Count Y. If possible, this should match the name of the
> +		respective channel as it appears in the device datasheet.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/preset
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		If the counter device supports preset registers -- registers
> +		used to load counter channels to a set count upon device-defined
> +		preset operation trigger events -- the preset count for channel
> +		Y is provided by this attribute.

Should this be presetZ in case a device has more than one preset?

> +
> +What:		/sys/bus/counter/devices/counterX/countY/preset_enable
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Whether channel Y counter preset operation is enabled. Valid
> +		attribute values are boolean.
> +
> +What:		/sys/bus/counter/devices/counterX/countY/signalZ_action
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Action mode of Count Y for Signal Z. This attribute indicates
> +		the condition of Signal Z that triggers the count function
> +		evaluation for Count Y. The following action modes are
> +		available:
> +
> +		None:
> +			Signal does not trigger the count function. In
> +			Pulse-Direction count function mode, this Signal is
> +			evaluated as Direction.
> +
> +		Rising Edge:
> +			Low state transitions to high state.
> +
> +		Falling Edge:
> +			High state transitions to low state.
> +
> +		Both Edges:
> +			Any state transition.

And again here (Title Case/lower case)

> +
> +What:		/sys/bus/counter/devices/counterX/name
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute that indicates the device-specific name of
> +		the Counter. This should match the name of the device as it
> +		appears in its respective datasheet.
> +
> +What:		/sys/bus/counter/devices/counterX/num_counts
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute that indicates the total number of Counts
> +		belonging to the Counter.
> +
> +What:		/sys/bus/counter/devices/counterX/num_signals
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute that indicates the total number of Signals
> +		belonging to the Counter.
> +
> +What:		/sys/bus/counter/devices/counterX/signalY/signal
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Signal data of Signal Y represented as a string.

I guess the actual value returned depends on the type of signal? Would we
need /sys/bus/counter/devices/counterX/signalY/type to indicate this so we
know how to interpret the value?

> +
> +What:		/sys/bus/counter/devices/counterX/signalY/name
> +KernelVersion:	4.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Read-only attribute that indicates the device-specific name of
> +		Signal Y. If possible, this should match the name of the
> +		respective signal as it appears in the device datasheet.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f6e995c142ed..f8a47fd197a1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3692,6 +3692,7 @@ COUNTER SUBSYSTEM
>   M:	William Breathitt Gray <vilhelm.gray@gmail.com>
>   L:	linux-iio@vger.kernel.org
>   S:	Maintained
> +F:	Documentation/ABI/testing/sysfs-bus-counter*
>   F:	drivers/counter/
>   F:	include/linux/counter.h
>   
> 


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,03/10] docs: Add Generic Counter interface documentation
  2018-06-21 21:07 ` [PATCH v7 03/10] docs: Add Generic Counter interface documentation William Breathitt Gray
  2018-06-22 16:51   ` Jonathan Cameron
@ 2018-07-02 19:37   ` David Lechner
  2018-07-03 14:16     ` William Breathitt Gray
  2018-07-02 19:42   ` David Lechner
  2 siblings, 1 reply; 41+ messages in thread
From: David Lechner @ 2018-07-02 19:37 UTC (permalink / raw)
  To: William Breathitt Gray, gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
> +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/sys-bus-counter-generic-sysfs 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.
> +

Have you considered a character device in addition to the sysfs interface?

I basically have many of the same concerns that resulted in a char dev for
gpio[1].

- With sysfs, you *can* technically poll for events, but then you have to
   seek and read or re-open the file.
- File permissions are annoying if you want a non root user to be able to
   use the device.
- A single program can't claim exclusive access to a device.
- There is no automatic cleanup if a userspace program accessing the device
    crashes.

[1]: https://www.elinux.org/images/7/74/Elce2017_new_GPIO_interface.pdf

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,03/10] docs: Add Generic Counter interface documentation
  2018-06-21 21:07 ` [PATCH v7 03/10] docs: Add Generic Counter interface documentation William Breathitt Gray
  2018-06-22 16:51   ` Jonathan Cameron
  2018-07-02 19:37   ` [v7,03/10] " David Lechner
@ 2018-07-02 19:42   ` David Lechner
  2018-07-03 14:21     ` William Breathitt Gray
  2 siblings, 1 reply; 41+ messages in thread
From: David Lechner @ 2018-07-02 19:42 UTC (permalink / raw)
  To: William Breathitt Gray, gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
> +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/sys-bus-counter-generic-sysfs 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.

I don't actually see any mention of the Synapses in the sysfs documentation.
But configfs my be better suited to configuring Synapses anyway, e.g. one
would symlink a Signal to a Counter to make the connection.



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,07/10] dt-bindings: counter: Document stm32 quadrature encoder
  2018-06-21 21:08 ` [PATCH v7 07/10] dt-bindings: counter: Document stm32 " William Breathitt Gray
@ 2018-07-02 19:56   ` David Lechner
  2018-07-05 21:13   ` [PATCH v7 07/10] " Rob Herring
  1 sibling, 0 replies; 41+ messages in thread
From: David Lechner @ 2018-07-02 19:56 UTC (permalink / raw)
  To: William Breathitt Gray, gregkh
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On 06/21/2018 04:08 PM, William Breathitt Gray wrote:
> From: Benjamin Gaignard <benjamin.gaignard@st.com>
> 
> Add bindings for STM32 Timer quadrature encoder.
> It is a sub-node of STM32 Timer which implement the
> quadratic encoder part of the hardware.

quadradic? or quadrature?

> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
>   .../bindings/counter/stm32-timer-cnt.txt      | 31 +++++++++++++++++++
>   .../devicetree/bindings/mfd/stm32-timers.txt  |  7 +++++
>   2 files changed, 38 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
> 
> diff --git a/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
> new file mode 100644
> index 000000000000..c52fcdd4bf6c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
> @@ -0,0 +1,31 @@
> +STMicroelectronics STM32 Timer quadrature encoder
> +
> +STM32 Timer provides quadrature encoder to detect
> +angular position and direction of rotary elements,
> +from IN1 and IN2 input signals.
> +
> +Must be a sub-node of an STM32 Timer device tree node.
> +See ../mfd/stm32-timers.txt for details about the parent node.
> +
> +Required properties:
> +- compatible:		Must be "st,stm32-timer-counter".
> +- pinctrl-names: 	Set to "default".
> +- pinctrl-0: 		List of phandles pointing to pin configuration nodes,
> +			to set CH1/CH2 pins in mode of operation for STM32
> +			Timer input on external pin.
> +
> +Example:
> +	timers@40010000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "st,stm32-timers";
> +		reg = <0x40010000 0x400>;
> +		clocks = <&rcc 0 160>;
> +		clock-names = "int";
> +
> +		counter {
> +			compatible = "st,stm32-timer-counter";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&tim1_in_pins>;
> +		};
> +	};
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> index 1db6e0057a63..ff9c14ada30b 100644
> --- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -23,6 +23,7 @@ Optional parameters:
>   Optional subnodes:
>   - pwm:			See ../pwm/pwm-stm32.txt
>   - timer:		See ../iio/timer/stm32-timer-trigger.txt
> +- counter:		See ../counter/stm32-timer-cnt.txt
>   
>   Example:
>   	timers@40010000 {
> @@ -43,4 +44,10 @@ Example:
>   			compatible = "st,stm32-timer-trigger";
>   			reg = <0>;
>   		};
> +
> +		counter {
> +			compatible = "st,stm32-timer-counter";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&tim1_in_pins>;
> +		};
>   	};
> 


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 00/10] Introduce the Counter subsystem
  2018-07-02 18:13 ` David Lechner
@ 2018-07-03  2:48   ` William Breathitt Gray
  2018-07-06 17:21     ` Jonathan Cameron
  0 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-03  2:48 UTC (permalink / raw)
  To: David Lechner
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Mon, Jul 02, 2018 at 01:13:40PM -0500, David Lechner wrote:
>On 06/21/2018 04:06 PM, William Breathitt Gray wrote:
>> I decided to strip down these devices to arrive at the core essence of
>> what constitutes a "counter device" and therefore design a "generic
>> counter" abstraction to better represent these devices and prevent the
>> ambiguity we discovered with the existing IIO Counter interface. This
>> abstraction became the Generic Counter paradigm, which is explained in
>> detail within the Documentation/driver-api/generic-counter.rst file
>> introduced by this patchset.
>
>I'm curious if you have given any thought to the time aspect of counters.
>I am interested in the rate at which the counters are counting (e.g. how
>many counts per second). I realize that you can calculate this in
>userspace or in the kernel using the system timer, but it is not very
>accurate since Linux is not a realtime OS. So, I would like to get the
>rate directly from the hardware. For example, the TI eQEP[1], like the
>one found in BeagleBones, has a couple ways of measuring time (see link
>for details).
>
>[1]: http://www.ti.com/lit/ug/sprug05a/sprug05a.pdf

Ah yes, I see you initially attempted adding a frequency channel type to
the IIO code. I agree with you that this calculation is best kept away
from the operating system, not just because of the realtime requirement
considerations, but also because the hardware likely knows best its own
data, so let's expose it!

Regarding the Generic Counter interface, a frequency attribute can be
added quite easily in a technical sense, so this discussion should be
focused more on the warrant for exposing this data. I understand from
the discussion thread on your initial patch submission that you're
working with hot-swappable encoder wheels and would like to expose a
counting rate since you have trouble otherwise knowing the number of
counts equal to one revolution due to the various possible encoder
wheels that could be installed -- do I understand this correctly?

Luckily the Generic Counter interface is a more abstract paradigm, so
the hot-swappable encoder wheels should not be a problem for us as long
as we nail down a consistent and thorough definition for this attribute.
To that end, since the Generic Counter paradigm is designed to abstract
away specifics of counter devices in order to present the final data of
interest to users (e.g. the count value, the mode of operation, etc.),
let's make sure frequency is actually what we want to expose and not
just a middle-step datum on the path to the final result.

What is the real life use-case for this information (are you tracking
position)? Does the relevant hardware report the number of counts equal
to one revolution, or are you calculating this from frequency? Are you
using this frequency to simply track the number of revolutions? Should
revolution count also be exposed? Is frequency useful for other
applications on its own (perhaps velocity of an automobile device
equipped with an encoder wheel for some reason or other)?

Once we figure out how this data is used, we can determine the best
design and place to introduce it into the Generic Counter interface,
then move on to integration from there.

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7, 02/10] counter: Documentation: Add Generic Counter sysfs documentation
  2018-07-02 19:11   ` [v7, " David Lechner
@ 2018-07-03 14:04     ` William Breathitt Gray
  0 siblings, 0 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-03 14:04 UTC (permalink / raw)
  To: David Lechner
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Mon, Jul 02, 2018 at 02:11:35PM -0500, David Lechner wrote:
>On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
>> +What:		/sys/bus/counter/devices/counterX/countY/count_mode
>> +KernelVersion:	4.19
>> +Contact:	linux-iio@vger.kernel.org
>> +Description:
>> +		Count mode for channel Y. The ceiling and floor values for
>> +		Count Y are used by the count mode where required. The following
>> +		count modes are available:
>> +
>> +		Normal:
>> +			Counting is continuous in either direction.
>> +
>> +		Range Limit:
>> +			An upper or lower limit is set, mimicking limit switches
>> +			in the mechanical counterpart. The upper limit is set to
>> +			the Count Y ceiling value, while the lower limit is set
>> +			to the Count Y floor value. The counter freezes at
>> +			count = ceiling when counting up, and at count = floor
>> +			when counting down. At either of these limits, the
>> +			counting is resumed only when the count direction is
>> +			reversed.
>> +
>> +		Non-Recycle:
>> +			The counter is disabled whenever a counter overflow or
>> +			underflow takes place. The counter is re-enabled when a
>> +			new count value is loaded to the counter via a preset
>> +			operation or direct write.
>> +
>> +		Modulo-N:
>> +			A count value boundary is set between the Count Y floor
>> +			value and the Count Y ceiling value. The counter is
>> +			reset to the Cunt Y floor value at count = ceiling when
>> +			counting up, while the counter is set to the Count Y
>> +			ceiling value at count = floor when counting down; the
>> +			counter does not freeze at the boundary points, but
>> +			counts continuously throughout.
>> +
>
>This might be a bit misleading since the values returned are all lower case,
>e.g. "rising edge", whereas they are listed here in Title Case.

Fair point, the options explicitly listed in the documentation should
match how they appear on the system. I'll make sure to consolidate these
and the others you mentioned in the next revision.

>> +What:		/sys/bus/counter/devices/counterX/countY/preset
>> +KernelVersion:	4.19
>> +Contact:	linux-iio@vger.kernel.org
>> +Description:
>> +		If the counter device supports preset registers -- registers
>> +		used to load counter channels to a set count upon device-defined
>> +		preset operation trigger events -- the preset count for channel
>> +		Y is provided by this attribute.
>
>Should this be presetZ in case a device has more than one preset?

I suppose it could be possible for a device to feature more than one
preset register for a count. However, in those cases a simple numbering
scheme such as presetZ would be ambigious: which preset register is
evaluated at which point?

I suspect in these kind of devices the preset registers are designated
specific triggers; for example, perhaps preset0 is evaluated when the
count reaches a ceiling, while preset1 is evaluated when a count reaches
a floor. In those sort of cases, it may be better to be more explicit
and define them as preset_ceiling and preset_floor (or something
similar) to make their behavior and use more apparent.

Alternatively, if the multiple presets are configurable, then there may
be value with a presetZ scheme if we have a respective presetZ_op
attribute (or similar) to expose the preset operation trigger condition
to the user. I haven't personally encountered devices like this, but I
can see it as possible, so we can consider this design once we try to
add support for a device that requires it.

>> +What:		/sys/bus/counter/devices/counterX/signalY/signal
>> +KernelVersion:	4.19
>> +Contact:	linux-iio@vger.kernel.org
>> +Description:
>> +		Signal data of Signal Y represented as a string.
>
>I guess the actual value returned depends on the type of signal? Would we
>need /sys/bus/counter/devices/counterX/signalY/type to indicate this so we
>know how to interpret the value?

I'm not sure how useful such an attribute would be. If we're using some
sort of generic utility to list out counter device information, then it
can print out the signal data directly because it's reported as a
character string. On the other hand, if the utility is specific for your
particular device, it should already know the format of the signal data
to parse at the very least from the respective documentation.

I don't believe adding this attribute would be technically difficult,
but I would hold off on adding it until we see a situation that requires
it (perhaps a device with multiple signal sources of different types for
example).

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,03/10] docs: Add Generic Counter interface documentation
  2018-07-02 19:37   ` [v7,03/10] " David Lechner
@ 2018-07-03 14:16     ` William Breathitt Gray
  2018-07-04 17:23       ` Linus Walleij
  0 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-03 14:16 UTC (permalink / raw)
  To: David Lechner
  Cc: gregkh, linus.walleij, jic23, linux-arm-kernel, devicetree,
	linux-kernel, linux-iio, fabrice.gasnier, benjamin.gaignard,
	robh+dt, knaack.h, lars, pmeerw, mark.rutland

On Mon, Jul 02, 2018 at 02:37:53PM -0500, David Lechner wrote:
>On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
>> +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/sys-bus-counter-generic-sysfs 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.
>> +
>
>Have you considered a character device in addition to the sysfs interface?
>
>I basically have many of the same concerns that resulted in a char dev for
>gpio[1].
>
>- With sysfs, you *can* technically poll for events, but then you have to
>   seek and read or re-open the file.
>- File permissions are annoying if you want a non root user to be able to
>   use the device.
>- A single program can't claim exclusive access to a device.
>- There is no automatic cleanup if a userspace program accessing the device
>    crashes.
>
>[1]: https://www.elinux.org/images/7/74/Elce2017_new_GPIO_interface.pdf

Those look like good technical reasons for implementing a character
device for the Generic Counter interface. I chose to implement the sysfs
interface because I was using the IIO code as a reference, but I
personally don't have much opposition to a character device in addition.

I'd like to get Jonathan's opinion on this as well if possible -- I
vaguely recall us considering this option briefly last year when the
Generic Counter interface was still in its beginnings. I've CC'd Linus
Walleij as well for input as the GPIO maintainer.

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,03/10] docs: Add Generic Counter interface documentation
  2018-07-02 19:42   ` David Lechner
@ 2018-07-03 14:21     ` William Breathitt Gray
  0 siblings, 0 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-03 14:21 UTC (permalink / raw)
  To: David Lechner
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Mon, Jul 02, 2018 at 02:42:06PM -0500, David Lechner wrote:
>On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
>> +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/sys-bus-counter-generic-sysfs 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.
>
>I don't actually see any mention of the Synapses in the sysfs documentation.
>But configfs my be better suited to configuring Synapses anyway, e.g. one
>would symlink a Signal to a Counter to make the connection.

I expect in a future patch to add a synapses directory to the count
directories which will have symlinks to the respective associated
signals. I've postponed this development for now to keep the
introduction patchset simple, and also because the current users have
little use for this feature at the moment, but it is indeed planned for
the future.

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,03/10] docs: Add Generic Counter interface documentation
  2018-07-03 14:16     ` William Breathitt Gray
@ 2018-07-04 17:23       ` Linus Walleij
  2018-07-06 17:15         ` Jonathan Cameron
  0 siblings, 1 reply; 41+ messages in thread
From: Linus Walleij @ 2018-07-04 17:23 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: David Lechner, Greg KH, Jonathan Cameron, Linux ARM,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel, linux-iio, Fabrice Gasnier, Benjamin Gaignard,
	Rob Herring, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald,
	Mark Rutland

On Tue, Jul 3, 2018 at 4:16 PM William Breathitt Gray
<vilhelm.gray@gmail.com> wrote:
> On Mon, Jul 02, 2018 at 02:37:53PM -0500, David Lechner wrote:
> >On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
> >> +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/sys-bus-counter-generic-sysfs 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.
> >> +
> >
> >Have you considered a character device in addition to the sysfs interface?
> >
> >I basically have many of the same concerns that resulted in a char dev for
> >gpio[1].
> >
> >- With sysfs, you *can* technically poll for events, but then you have to
> >   seek and read or re-open the file.
> >- File permissions are annoying if you want a non root user to be able to
> >   use the device.
> >- A single program can't claim exclusive access to a device.
> >- There is no automatic cleanup if a userspace program accessing the device
> >    crashes.
> >
> >[1]: https://www.elinux.org/images/7/74/Elce2017_new_GPIO_interface.pdf
>
> Those look like good technical reasons for implementing a character
> device for the Generic Counter interface. I chose to implement the sysfs
> interface because I was using the IIO code as a reference, but I
> personally don't have much opposition to a character device in addition.

IIO is also using a character device for outputting events and sensor
data. In IIO sysfs is only used for configuring what events and
data should come out of the character device.

> I'd like to get Jonathan's opinion on this as well if possible -- I
> vaguely recall us considering this option briefly last year when the
> Generic Counter interface was still in its beginnings. I've CC'd Linus
> Walleij as well for input as the GPIO maintainer.

The GPIO character device was based on the IIO character device.

We have one TODO item: to merge the timestamping format
between GPIO and IIO and use the same sysfs file for configuring
the time base.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 07/10] dt-bindings: counter: Document stm32 quadrature encoder
  2018-06-21 21:08 ` [PATCH v7 07/10] dt-bindings: counter: Document stm32 " William Breathitt Gray
  2018-07-02 19:56   ` [v7,07/10] " David Lechner
@ 2018-07-05 21:13   ` Rob Herring
  1 sibling, 0 replies; 41+ messages in thread
From: Rob Herring @ 2018-07-05 21:13 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, knaack.h, lars,
	pmeerw, mark.rutland

On Thu, Jun 21, 2018 at 05:08:34PM -0400, William Breathitt Gray wrote:
> From: Benjamin Gaignard <benjamin.gaignard@st.com>
> 
> Add bindings for STM32 Timer quadrature encoder.
> It is a sub-node of STM32 Timer which implement the
> quadratic encoder part of the hardware.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
>  .../bindings/counter/stm32-timer-cnt.txt      | 31 +++++++++++++++++++
>  .../devicetree/bindings/mfd/stm32-timers.txt  |  7 +++++
>  2 files changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt

Acked-by: Rob Herring <robh@kernel.org> 


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 09/10] dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move
  2018-06-21 21:08 ` [PATCH v7 09/10] dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move William Breathitt Gray
@ 2018-07-05 21:13   ` Rob Herring
  0 siblings, 0 replies; 41+ messages in thread
From: Rob Herring @ 2018-07-05 21:13 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, knaack.h, lars,
	pmeerw, mark.rutland

On Thu, Jun 21, 2018 at 05:08:57PM -0400, William Breathitt Gray wrote:
> From: Fabrice Gasnier <fabrice.gasnier@st.com>
> 
> The STM32 LP Timer counter driver now resides under the Counter
> subsystem. This patch adjusts dt-bindings to account for the STM32
> lptimer driver move.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
>  .../devicetree/bindings/{iio => }/counter/stm32-lptimer-cnt.txt | 0
>  Documentation/devicetree/bindings/mfd/stm32-lptimer.txt         | 2 +-
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename Documentation/devicetree/bindings/{iio => }/counter/stm32-lptimer-cnt.txt (100%)

Acked-by: Rob Herring <robh@kernel.org> 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,03/10] docs: Add Generic Counter interface documentation
  2018-07-04 17:23       ` Linus Walleij
@ 2018-07-06 17:15         ` Jonathan Cameron
  2018-07-06 18:25           ` David Lechner
  0 siblings, 1 reply; 41+ messages in thread
From: Jonathan Cameron @ 2018-07-06 17:15 UTC (permalink / raw)
  To: Linus Walleij
  Cc: William Breathitt Gray, David Lechner, Greg KH, Jonathan Cameron,
	Linux ARM,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel, linux-iio, Fabrice Gasnier, Benjamin Gaignard,
	Rob Herring, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald,
	Mark Rutland

On Wed, 4 Jul 2018 19:23:26 +0200
Linus Walleij <linus.walleij@linaro.org> wrote:

> On Tue, Jul 3, 2018 at 4:16 PM William Breathitt Gray
> <vilhelm.gray@gmail.com> wrote:
> > On Mon, Jul 02, 2018 at 02:37:53PM -0500, David Lechner wrote:  
> > >On 06/21/2018 04:07 PM, William Breathitt Gray wrote:  
> > >> +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/sys-bus-counter-generic-sysfs 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.
> > >> +  
> > >
> > >Have you considered a character device in addition to the sysfs interface?
> > >
> > >I basically have many of the same concerns that resulted in a char dev for
> > >gpio[1].
> > >
> > >- With sysfs, you *can* technically poll for events, but then you have to
> > >   seek and read or re-open the file.

For this to be relevant we need some type of self clocking sampling of a counter,
so far this hasn't really been true for William's devices - they tend to have
internal monitoring and you just 'ask' them when you want to know the rotation.
Sure if we have 'events' such as soft limit switches in the hardware, then
we'd want some sort of event chrdev (personally I think these should be separate
from the main data flow - but that's a detail).

> > >- File permissions are annoying if you want a non root user to be able to
> > >   use the device.

They aren't a whole lot different for a chrdev.  In both cases you can allow
a non root user write access if you want to.

> > >- A single program can't claim exclusive access to a device.

Agreed.  Though that only matters for control, why do you care if someone
else can read.  In IIO we get around this by 'generally' blocking settings
changes that will a process that is sampling data via the chrdev.
It's not a hard and fast rule though.  I really don't like configuration
via chrdevs as for complex devices you end up with a non self describing
interface with a lot of complexity.

The exceptions are things like the media controller frameworks, but they
are very very heavyweight for an simple devices like counters.

> > >- There is no automatic cleanup if a userspace program accessing the device
> > >    crashes.

For these devices, the question is what sort of cleanup makes sense?

Often they are freerunning so the most you could do is power down if you knew
no one cared, but for an encoder you may well want to continue tracking even
if no one is looking right now.

I can think of reasons you 'might' want to tidy up, but we'd need real
driver code to show the necessity of this one.

> > >
> > >[1]: https://www.elinux.org/images/7/74/Elce2017_new_GPIO_interface.pdf  
> >
> > Those look like good technical reasons for implementing a character
> > device for the Generic Counter interface. I chose to implement the sysfs
> > interface because I was using the IIO code as a reference, but I
> > personally don't have much opposition to a character device in addition.  
> 
> IIO is also using a character device for outputting events and sensor
> data. In IIO sysfs is only used for configuring what events and
> data should come out of the character device.

Yes, with the addition that we typically provide data readback as well.
For some simple devices which are slow and are actually polled to get
a reading, there is not a lot of point in implementing the chrdev route
so in IIO it is optional.
> 
> > I'd like to get Jonathan's opinion on this as well if possible -- I
> > vaguely recall us considering this option briefly last year when the
> > Generic Counter interface was still in its beginnings. I've CC'd Linus
> > Walleij as well for input as the GPIO maintainer.  

I'm not against it, but I do want to see use cases that are not
satisfied by sysfs first.

So far we've no seen them but sounds like you might have one David!

Jonathan

> 
> The GPIO character device was based on the IIO character device.
> 
> We have one TODO item: to merge the timestamping format
> between GPIO and IIO and use the same sysfs file for configuring
> the time base.
> 
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 00/10] Introduce the Counter subsystem
  2018-07-03  2:48   ` William Breathitt Gray
@ 2018-07-06 17:21     ` Jonathan Cameron
  2018-07-06 18:22       ` David Lechner
  0 siblings, 1 reply; 41+ messages in thread
From: Jonathan Cameron @ 2018-07-06 17:21 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: David Lechner, gregkh, jic23, linux-arm-kernel, devicetree,
	linux-kernel, linux-iio, fabrice.gasnier, benjamin.gaignard,
	robh+dt, knaack.h, lars, pmeerw, mark.rutland

On Mon, 2 Jul 2018 22:48:35 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> On Mon, Jul 02, 2018 at 01:13:40PM -0500, David Lechner wrote:
> >On 06/21/2018 04:06 PM, William Breathitt Gray wrote:  
> >> I decided to strip down these devices to arrive at the core essence of
> >> what constitutes a "counter device" and therefore design a "generic
> >> counter" abstraction to better represent these devices and prevent the
> >> ambiguity we discovered with the existing IIO Counter interface. This
> >> abstraction became the Generic Counter paradigm, which is explained in
> >> detail within the Documentation/driver-api/generic-counter.rst file
> >> introduced by this patchset.  
> >
> >I'm curious if you have given any thought to the time aspect of counters.
> >I am interested in the rate at which the counters are counting (e.g. how
> >many counts per second). I realize that you can calculate this in
> >userspace or in the kernel using the system timer, but it is not very
> >accurate since Linux is not a realtime OS. So, I would like to get the
> >rate directly from the hardware. For example, the TI eQEP[1], like the
> >one found in BeagleBones, has a couple ways of measuring time (see link
> >for details).
> >
> >[1]: http://www.ti.com/lit/ug/sprug05a/sprug05a.pdf  

Cool in eQEP if that is what you are targetting - been wanting to see
nice kernel support implemented for that for a long time, but never
got the spare cycles to do it myself!

> 
> Ah yes, I see you initially attempted adding a frequency channel type to
> the IIO code. I agree with you that this calculation is best kept away
> from the operating system, not just because of the realtime requirement
> considerations, but also because the hardware likely knows best its own
> data, so let's expose it!
> 
> Regarding the Generic Counter interface, a frequency attribute can be
> added quite easily in a technical sense, so this discussion should be
> focused more on the warrant for exposing this data. I understand from
> the discussion thread on your initial patch submission that you're
> working with hot-swappable encoder wheels and would like to expose a
> counting rate since you have trouble otherwise knowing the number of
> counts equal to one revolution due to the various possible encoder
> wheels that could be installed -- do I understand this correctly?
> 
> Luckily the Generic Counter interface is a more abstract paradigm, so
> the hot-swappable encoder wheels should not be a problem for us as long
> as we nail down a consistent and thorough definition for this attribute.
> To that end, since the Generic Counter paradigm is designed to abstract
> away specifics of counter devices in order to present the final data of
> interest to users (e.g. the count value, the mode of operation, etc.),
> let's make sure frequency is actually what we want to expose and not
> just a middle-step datum on the path to the final result.
> 
> What is the real life use-case for this information (are you tracking
> position)? Does the relevant hardware report the number of counts equal
> to one revolution, or are you calculating this from frequency? Are you
> using this frequency to simply track the number of revolutions? Should
> revolution count also be exposed? Is frequency useful for other
> applications on its own (perhaps velocity of an automobile device
> equipped with an encoder wheel for some reason or other)?
> 
> Once we figure out how this data is used, we can determine the best
> design and place to introduce it into the Generic Counter interface,
> then move on to integration from there.

Great - as long as this fits reasonably well in ABI wise (whatever the
details) sounds like we don't need to solve it today.  I'm anxious not
to delay merging this counter subsystem for another cycle.

Jonathan

> 
> William Breathitt Gray
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 00/10] Introduce the Counter subsystem
  2018-07-06 17:21     ` Jonathan Cameron
@ 2018-07-06 18:22       ` David Lechner
  2018-07-06 19:20         ` William Breathitt Gray
  0 siblings, 1 reply; 41+ messages in thread
From: David Lechner @ 2018-07-06 18:22 UTC (permalink / raw)
  To: Jonathan Cameron, William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On 07/06/2018 12:21 PM, Jonathan Cameron wrote:
> On Mon, 2 Jul 2018 22:48:35 -0400
> William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> 
>> On Mon, Jul 02, 2018 at 01:13:40PM -0500, David Lechner wrote:
>>> On 06/21/2018 04:06 PM, William Breathitt Gray wrote:
>>>> I decided to strip down these devices to arrive at the core essence of
>>>> what constitutes a "counter device" and therefore design a "generic
>>>> counter" abstraction to better represent these devices and prevent the
>>>> ambiguity we discovered with the existing IIO Counter interface. This
>>>> abstraction became the Generic Counter paradigm, which is explained in
>>>> detail within the Documentation/driver-api/generic-counter.rst file
>>>> introduced by this patchset.
>>>
>>> I'm curious if you have given any thought to the time aspect of counters.
>>> I am interested in the rate at which the counters are counting (e.g. how
>>> many counts per second). I realize that you can calculate this in
>>> userspace or in the kernel using the system timer, but it is not very
>>> accurate since Linux is not a realtime OS. So, I would like to get the
>>> rate directly from the hardware. For example, the TI eQEP[1], like the
>>> one found in BeagleBones, has a couple ways of measuring time (see link
>>> for details).
>>>
>>> [1]: http://www.ti.com/lit/ug/sprug05a/sprug05a.pdf
> 
> Cool in eQEP if that is what you are targetting - been wanting to see
> nice kernel support implemented for that for a long time, but never
> got the spare cycles to do it myself!
> 
>>
>> Ah yes, I see you initially attempted adding a frequency channel type to
>> the IIO code. I agree with you that this calculation is best kept away
>> from the operating system, not just because of the realtime requirement
>> considerations, but also because the hardware likely knows best its own
>> data, so let's expose it!
>>
>> Regarding the Generic Counter interface, a frequency attribute can be
>> added quite easily in a technical sense, so this discussion should be
>> focused more on the warrant for exposing this data. I understand from
>> the discussion thread on your initial patch submission that you're
>> working with hot-swappable encoder wheels and would like to expose a
>> counting rate since you have trouble otherwise knowing the number of
>> counts equal to one revolution due to the various possible encoder
>> wheels that could be installed -- do I understand this correctly?
>>
>> Luckily the Generic Counter interface is a more abstract paradigm, so
>> the hot-swappable encoder wheels should not be a problem for us as long
>> as we nail down a consistent and thorough definition for this attribute.
>> To that end, since the Generic Counter paradigm is designed to abstract
>> away specifics of counter devices in order to present the final data of
>> interest to users (e.g. the count value, the mode of operation, etc.),
>> let's make sure frequency is actually what we want to expose and not
>> just a middle-step datum on the path to the final result.
>>
>> What is the real life use-case for this information (are you tracking
>> position)?

We are attempting to control the speed of the motors well enough to make
a balancing (inverted pendulum) robot and also synchronize two motors
when driving a robot (e.g. if one gets "stuck", the other slows down and
waits for the first to catch up).

>> Does the relevant hardware report the number of counts equal
>> to one revolution, or are you calculating this from frequency?

Not exactly. For the most part, the motors are the same, so we assume
that as default, but have a way for changing the parameters from
userspace.

>> Are you
>> using this frequency to simply track the number of revolutions?

No, we are using it to calculate the rotational speed of the motor.

>> Should
>> revolution count also be exposed?

I don't think so. The raw count value is good enough.

>> Is frequency useful for other
>> applications on its own (perhaps velocity of an automobile device
>> equipped with an encoder wheel for some reason or other)?

Since we are just dealing with counters here, I think we should call
it "rate" instead of "frequency". At least that seems to be the common
name in industrial automation.

Another possible use case for "rate" would be flow meters. Some
flow meters generate a pulse every X gallons. Assuming that the
counter also has a rate output, then you can scale the rate (e.g.
counts/second) into flow in gallons per minute.

>>
>> Once we figure out how this data is used, we can determine the best
>> design and place to introduce it into the Generic Counter interface,
>> then move on to integration from there.
> 
> Great - as long as this fits reasonably well in ABI wise (whatever the
> details) sounds like we don't need to solve it today.  I'm anxious not
> to delay merging this counter subsystem for another cycle.

Certainly don't delay things on account of me. I'm just trying to get
a feel for where things are headed since I missed the earlier discussions.
I don't see any major problems with the current state of things.

Once this lands, I may have a go at the eQEP and see how it looks.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [v7,03/10] docs: Add Generic Counter interface documentation
  2018-07-06 17:15         ` Jonathan Cameron
@ 2018-07-06 18:25           ` David Lechner
  0 siblings, 0 replies; 41+ messages in thread
From: David Lechner @ 2018-07-06 18:25 UTC (permalink / raw)
  To: Jonathan Cameron, Linus Walleij
  Cc: William Breathitt Gray, Greg KH, Jonathan Cameron, Linux ARM,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel, linux-iio, Fabrice Gasnier, Benjamin Gaignard,
	Rob Herring, Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald,
	Mark Rutland

On 07/06/2018 12:15 PM, Jonathan Cameron wrote:
> On Wed, 4 Jul 2018 19:23:26 +0200
> Linus Walleij <linus.walleij@linaro.org> wrote:
> 
>> On Tue, Jul 3, 2018 at 4:16 PM William Breathitt Gray
>> <vilhelm.gray@gmail.com> wrote:
>>> On Mon, Jul 02, 2018 at 02:37:53PM -0500, David Lechner wrote:
>>>> On 06/21/2018 04:07 PM, William Breathitt Gray wrote:
>>>>> +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/sys-bus-counter-generic-sysfs 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.
>>>>> +
>>>>
>>>> Have you considered a character device in addition to the sysfs interface?
>>>>
>>>> I basically have many of the same concerns that resulted in a char dev for
>>>> gpio[1].
>>>>
>>>> - With sysfs, you *can* technically poll for events, but then you have to
>>>>    seek and read or re-open the file.
> 
> For this to be relevant we need some type of self clocking sampling of a counter,
> so far this hasn't really been true for William's devices - they tend to have
> internal monitoring and you just 'ask' them when you want to know the rotation.
> Sure if we have 'events' such as soft limit switches in the hardware, then
> we'd want some sort of event chrdev (personally I think these should be separate
> from the main data flow - but that's a detail).
> 
>>>> - File permissions are annoying if you want a non root user to be able to
>>>>    use the device.
> 
> They aren't a whole lot different for a chrdev.  In both cases you can allow
> a non root user write access if you want to.
> 
>>>> - A single program can't claim exclusive access to a device.
> 
> Agreed.  Though that only matters for control, why do you care if someone
> else can read.  In IIO we get around this by 'generally' blocking settings
> changes that will a process that is sampling data via the chrdev.
> It's not a hard and fast rule though.  I really don't like configuration
> via chrdevs as for complex devices you end up with a non self describing
> interface with a lot of complexity.
> 
> The exceptions are things like the media controller frameworks, but they
> are very very heavyweight for an simple devices like counters.
> 
>>>> - There is no automatic cleanup if a userspace program accessing the device
>>>>     crashes.
> 
> For these devices, the question is what sort of cleanup makes sense?
> 
> Often they are freerunning so the most you could do is power down if you knew
> no one cared, but for an encoder you may well want to continue tracking even
> if no one is looking right now.
> 
> I can think of reasons you 'might' want to tidy up, but we'd need real
> driver code to show the necessity of this one.
> 
>>>>
>>>> [1]: https://www.elinux.org/images/7/74/Elce2017_new_GPIO_interface.pdf
>>>
>>> Those look like good technical reasons for implementing a character
>>> device for the Generic Counter interface. I chose to implement the sysfs
>>> interface because I was using the IIO code as a reference, but I
>>> personally don't have much opposition to a character device in addition.
>>
>> IIO is also using a character device for outputting events and sensor
>> data. In IIO sysfs is only used for configuring what events and
>> data should come out of the character device.
> 
> Yes, with the addition that we typically provide data readback as well.
> For some simple devices which are slow and are actually polled to get
> a reading, there is not a lot of point in implementing the chrdev route
> so in IIO it is optional.
>>
>>> I'd like to get Jonathan's opinion on this as well if possible -- I
>>> vaguely recall us considering this option briefly last year when the
>>> Generic Counter interface was still in its beginnings. I've CC'd Linus
>>> Walleij as well for input as the GPIO maintainer.
> 
> I'm not against it, but I do want to see use cases that are not
> satisfied by sysfs first.
> 
> So far we've no seen them but sounds like you might have one David!
> 

Basically, we are implementing a counter in the PRU on TI Sitara, so
we can make it do just about whatever we want. Although, I'm trying to
keep it similar to the eQEP.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 00/10] Introduce the Counter subsystem
  2018-07-06 18:22       ` David Lechner
@ 2018-07-06 19:20         ` William Breathitt Gray
  0 siblings, 0 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-06 19:20 UTC (permalink / raw)
  To: David Lechner
  Cc: Jonathan Cameron, gregkh, jic23, linux-arm-kernel, devicetree,
	linux-kernel, linux-iio, fabrice.gasnier, benjamin.gaignard,
	robh+dt, knaack.h, lars, pmeerw, mark.rutland

On Fri, Jul 06, 2018 at 01:22:57PM -0500, David Lechner wrote:
>On 07/06/2018 12:21 PM, Jonathan Cameron wrote:
>> On Mon, 2 Jul 2018 22:48:35 -0400
>> William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
>>> Is frequency useful for other
>>> applications on its own (perhaps velocity of an automobile device
>>> equipped with an encoder wheel for some reason or other)?
>
>Since we are just dealing with counters here, I think we should call
>it "rate" instead of "frequency". At least that seems to be the common
>name in industrial automation.
>
>Another possible use case for "rate" would be flow meters. Some
>flow meters generate a pulse every X gallons. Assuming that the
>counter also has a rate output, then you can scale the rate (e.g.
>counts/second) into flow in gallons per minute.
>
>>>
>>> Once we figure out how this data is used, we can determine the best
>>> design and place to introduce it into the Generic Counter interface,
>>> then move on to integration from there.
>> 
>> Great - as long as this fits reasonably well in ABI wise (whatever the
>> details) sounds like we don't need to solve it today.  I'm anxious not
>> to delay merging this counter subsystem for another cycle.
>
>Certainly don't delay things on account of me. I'm just trying to get
>a feel for where things are headed since I missed the earlier discussions.
>I don't see any major problems with the current state of things.
>
>Once this lands, I may have a go at the eQEP and see how it looks.

No worries, it looks like your application would be served well by the
Generic Counter interface, and exposing a "rate" value would be a simple
feature to add. However, since this patchset has been stabilizing over
the past few revisions, I want to postpone the addition of new features
until this interface and its current feature set is merged.

David, once this introduction patchset has been merged, submit to me a
patch adding the "rate" functionality feature and we'll continue
discussing it there.

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-06-21 21:07 ` [PATCH v7 01/10] counter: Introduce the Generic Counter interface William Breathitt Gray
@ 2018-07-07 15:16   ` Greg KH
  2018-07-09 17:40     ` William Breathitt Gray
  2018-07-18  3:49   ` Andrew Morton
  1 sibling, 1 reply; 41+ messages in thread
From: Greg KH @ 2018-07-07 15:16 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On Thu, Jun 21, 2018 at 05:07:08PM -0400, William Breathitt Gray wrote:
> This patch introduces the Generic Counter interface for supporting
> counter devices.
> 
> In the context of the Generic Counter interface, a counter is defined as
> a device that reports one or more "counts" based on the state changes of
> one or more "signals" as evaluated by a defined "count function."
> 
> Driver callbacks should be provided to communicate with the device: to
> read and write various Signals and Counts, and to set and get the
> "action mode" and "count function" for various Synapses and Counts
> respectively.
> 
> To support a counter device, a driver must first allocate the available
> Counter Signals via counter_signal structures. These Signals should
> be stored as an array and set to the signals array member of an
> allocated counter_device structure before the Counter is registered to
> the system.
> 
> Counter Counts may be allocated via counter_count structures, and
> respective Counter Signal associations (Synapses) made via
> counter_synapse structures. Associated counter_synapse structures are
> stored as an array and set to the the synapses array member of the
> 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.
> 
> A counter device is registered to the system by passing the respective
> initialized counter_device structure to the counter_register function;
> similarly, the counter_unregister function unregisters the respective
> Counter. The devm_counter_register and devm_counter_unregister functions
> serve as device memory-managed versions of the counter_register and
> counter_unregister functions respectively.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
>  MAINTAINERS                       |    7 +
>  drivers/Kconfig                   |    2 +
>  drivers/Makefile                  |    1 +
>  drivers/counter/Kconfig           |   18 +
>  drivers/counter/Makefile          |    8 +
>  drivers/counter/generic-counter.c | 1519 +++++++++++++++++++++++++++++
>  include/linux/counter.h           |  534 ++++++++++
>  7 files changed, 2089 insertions(+)
>  create mode 100644 drivers/counter/Kconfig
>  create mode 100644 drivers/counter/Makefile
>  create mode 100644 drivers/counter/generic-counter.c
>  create mode 100644 include/linux/counter.h

First cut of review, does counter.h really have to be that big?  It
feels like some of the "internal" functions and structures could be
local to drivers/counter/ right?


> +menuconfig COUNTER
> +	tristate "Counter support"
> +	help
> +	  Provides Generic Counter interface support for counter devices.
> +
> +	  Counter devices are prevalent within a diverse spectrum of industries.
> +	  The ubiquitous presence of these devices necessitates a common
> +	  interface and standard of interaction and exposure. This driver API
> +	  attempts to resolve the issue of duplicate code found among existing
> +	  counter device drivers by providing a generic counter interface for
> +	  consumption. The Generic Counter interface enables drivers to support
> +	  and expose a common set of components and functionality present in
> +	  counter devices.

No need to explain an "API" in a Kconfig help text, which is for a user
of the kernel, not for someone writing kernel code.  Odds are individual
drivers will need to select this, or are you going to depend on this
option?


> diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
> new file mode 100644
> index 000000000000..ad1ba7109cdc
> --- /dev/null
> +++ b/drivers/counter/Makefile
> @@ -0,0 +1,8 @@
> +#
> +# Makefile for Counter devices
> +#
> +
> +# When adding new entries keep the list in alphabetical order

Why does it matter?  :)

> +
> +obj-$(CONFIG_COUNTER) += counter.o
> +counter-y := generic-counter.o

Why not just call your .c file, "counter.c" to keep this simple?

> diff --git a/drivers/counter/generic-counter.c b/drivers/counter/generic-counter.c
> new file mode 100644
> index 000000000000..483826c8ce01
> --- /dev/null
> +++ b/drivers/counter/generic-counter.c
> @@ -0,0 +1,1519 @@
> +// SPDX-License-Identifier: GPL-2.0-only

Please use the normal SPDX identifiers we are using, as described in the
kernel documentation.  We aren't ready to use the "new" ones just yet.

> +/*
> + * Generic Counter interface
> + * Copyright (C) 2017 William Breathitt Gray

It's 2018 now :)

> + */
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/fs.h>
> +#include <linux/gfp.h>
> +#include <linux/idr.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/printk.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/sysfs.h>
> +#include <linux/types.h>
> +
> +#include <linux/counter.h>

Why a blank line?

> +
> +const char *const count_direction_str[2] = {
> +	[COUNT_DIRECTION_FORWARD] = "forward",
> +	[COUNT_DIRECTION_BACKWARD] = "backward"
> +};
> +EXPORT_SYMBOL(count_direction_str);

I have to ask, for all of these, why not EXPORT_SYMBOL_GPL()?


> +
> +const char *const count_mode_str[4] = {
> +	[COUNT_MODE_NORMAL] = "normal",
> +	[COUNT_MODE_RANGE_LIMIT] = "range limit",
> +	[COUNT_MODE_NON_RECYCLE] = "non-recycle",
> +	[COUNT_MODE_MODULO_N] = "modulo-n"
> +};
> +EXPORT_SYMBOL(count_mode_str);

And why do you need to export strings?



> +
> +ssize_t counter_signal_enum_read(struct counter_device *counter,
> +				 struct counter_signal *signal, void *priv,
> +				 char *buf)
> +{
> +	const struct counter_signal_enum_ext *const e = priv;
> +	int err;
> +	size_t index;
> +
> +	if (!e->get)
> +		return -EINVAL;

How can e->get not be set?  Shouldn't you just not have called into this
if so?

> +
> +	err = e->get(counter, signal, &index);
> +	if (err)
> +		return err;
> +
> +	if (index >= e->num_items)
> +		return -EINVAL;
> +
> +	return scnprintf(buf, PAGE_SIZE, "%s\n", e->items[index]);

No need to do the scnprintf() crud, it's a sysfs file, a simple
sprintf() works just fine.  Yeah, it makes people nervous, and it should :)


> +}
> +EXPORT_SYMBOL(counter_signal_enum_read);

sysfs attribute files really should be EXPORT_SYMBOL_GPL() please.

> +
> +ssize_t counter_signal_enum_write(struct counter_device *counter,
> +				  struct counter_signal *signal, void *priv,
> +				  const char *buf, size_t len)
> +{
> +	const struct counter_signal_enum_ext *const e = priv;
> +	ssize_t index;
> +	int err;
> +
> +	if (!e->set)
> +		return -EINVAL;

Again, how can this be true?


> +
> +	index = __sysfs_match_string(e->items, e->num_items, buf);
> +	if (index < 0)
> +		return index;
> +
> +	err = e->set(counter, signal, index);
> +	if (err)
> +		return err;
> +
> +	return len;
> +}
> +EXPORT_SYMBOL(counter_signal_enum_write);
> +
> +ssize_t counter_signal_enum_available_read(struct counter_device *counter,
> +					   struct counter_signal *signal,
> +					   void *priv, char *buf)
> +{
> +	const struct counter_signal_enum_ext *const e = priv;
> +	size_t i;
> +	size_t len = 0;
> +
> +	if (!e->num_items)
> +		return 0;
> +
> +	for (i = 0; i < e->num_items; i++)
> +		len += scnprintf(buf + len, PAGE_SIZE - len, "%s\n",
> +			e->items[i]);

a list of items?  In sysfs?  Are you _SURE_ you want to do that?

> +
> +	return len;
> +}
> +EXPORT_SYMBOL(counter_signal_enum_available_read);
> +
> +ssize_t counter_count_enum_read(struct counter_device *counter,
> +				struct counter_count *count, void *priv,
> +				char *buf)
> +{
> +	const struct counter_count_enum_ext *const e = priv;
> +	int err;
> +	size_t index;
> +
> +	if (!e->get)
> +		return -EINVAL;


Same comment everywhere for this...

let's skip lower in the files...

> +static int counter_attribute_create(
> +	struct counter_device_attr_group *const group,
> +	const char *const prefix,
> +	const char *const name,
> +	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
> +			char *buf),
> +	ssize_t (*store)(struct device *dev, struct device_attribute *attr,
> +			 const char *buf, size_t len),

Typedefs for these function pointers are good to have.

> +	void *const component)

That's a crazy list of parameters...


> +{
> +	struct counter_device_attr *counter_attr;
> +	struct device_attribute *dev_attr;
> +	int err;
> +	struct list_head *const attr_list = &group->attr_list;
> +
> +	/* Allocate a Counter device attribute */
> +	counter_attr = kzalloc(sizeof(*counter_attr), GFP_KERNEL);
> +	if (!counter_attr)
> +		return -ENOMEM;
> +	dev_attr = &counter_attr->dev_attr;
> +
> +	sysfs_attr_init(&dev_attr->attr);
> +
> +	/* Configure device attribute */
> +	dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, name);
> +	if (!dev_attr->attr.name) {
> +		err = -ENOMEM;
> +		goto err_free_counter_attr;
> +	}
> +	if (show) {
> +		dev_attr->attr.mode |= 0444;
> +		dev_attr->show = show;
> +	}
> +	if (store) {
> +		dev_attr->attr.mode |= 0200;
> +		dev_attr->store = store;
> +	}
> +
> +	/* Store associated Counter component with attribute */
> +	counter_attr->component = component;
> +
> +	/* Keep track of the attribute for later cleanup */
> +	list_add(&counter_attr->l, attr_list);
> +	group->num_attr++;

So you are dynamically creating sysfs attributes?  Why not just have one
big group and only enable them if needed?  That would make things a lot
simpler, right?

> +struct signal_comp_t {

"_t"???

> +	struct counter_signal	*signal;
> +};
> +
> +static ssize_t counter_signal_show(struct device *dev,
> +				   struct device_attribute *attr, char *buf)
> +{
> +	struct counter_device *const counter = dev_get_drvdata(dev);
> +	const struct counter_device_attr *const devattr = to_counter_attr(attr);
> +	const struct signal_comp_t *const component = devattr->component;
> +	struct counter_signal *const signal = component->signal;
> +	int err;
> +	struct signal_read_value val = { .buf = buf };
> +
> +	err = counter->ops->signal_read(counter, signal, &val);
> +	if (err)
> +		return err;
> +
> +	return val.len;
> +}
> +
> +struct name_comp_t {

"_t"???

Same for the rest of this file...

> diff --git a/include/linux/counter.h b/include/linux/counter.h
> new file mode 100644
> index 000000000000..88fc82ee30a7
> --- /dev/null
> +++ b/include/linux/counter.h
> @@ -0,0 +1,534 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */

Same identifier issue.

> +/*
> + * Counter interface
> + * Copyright (C) 2017 William Breathitt Gray

2018!

And again, it looks like this file can be a lot smaller, but I don't see
a user of it just yet, so I don't really know...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-07-07 15:16   ` Greg KH
@ 2018-07-09 17:40     ` William Breathitt Gray
  2018-07-09 18:54       ` Greg KH
  0 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-09 17:40 UTC (permalink / raw)
  To: Greg KH
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On Sat, Jul 07, 2018 at 05:16:22PM +0200, Greg KH wrote:
>On Thu, Jun 21, 2018 at 05:07:08PM -0400, William Breathitt Gray wrote:
>> This patch introduces the Generic Counter interface for supporting
>> counter devices.
>> 
>> In the context of the Generic Counter interface, a counter is defined as
>> a device that reports one or more "counts" based on the state changes of
>> one or more "signals" as evaluated by a defined "count function."
>> 
>> Driver callbacks should be provided to communicate with the device: to
>> read and write various Signals and Counts, and to set and get the
>> "action mode" and "count function" for various Synapses and Counts
>> respectively.
>> 
>> To support a counter device, a driver must first allocate the available
>> Counter Signals via counter_signal structures. These Signals should
>> be stored as an array and set to the signals array member of an
>> allocated counter_device structure before the Counter is registered to
>> the system.
>> 
>> Counter Counts may be allocated via counter_count structures, and
>> respective Counter Signal associations (Synapses) made via
>> counter_synapse structures. Associated counter_synapse structures are
>> stored as an array and set to the the synapses array member of the
>> 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.
>> 
>> A counter device is registered to the system by passing the respective
>> initialized counter_device structure to the counter_register function;
>> similarly, the counter_unregister function unregisters the respective
>> Counter. The devm_counter_register and devm_counter_unregister functions
>> serve as device memory-managed versions of the counter_register and
>> counter_unregister functions respectively.
>> 
>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>> ---
>>  MAINTAINERS                       |    7 +
>>  drivers/Kconfig                   |    2 +
>>  drivers/Makefile                  |    1 +
>>  drivers/counter/Kconfig           |   18 +
>>  drivers/counter/Makefile          |    8 +
>>  drivers/counter/generic-counter.c | 1519 +++++++++++++++++++++++++++++
>>  include/linux/counter.h           |  534 ++++++++++
>>  7 files changed, 2089 insertions(+)
>>  create mode 100644 drivers/counter/Kconfig
>>  create mode 100644 drivers/counter/Makefile
>>  create mode 100644 drivers/counter/generic-counter.c
>>  create mode 100644 include/linux/counter.h
>
>First cut of review, does counter.h really have to be that big?  It
>feels like some of the "internal" functions and structures could be
>local to drivers/counter/ right?

Most of the functions and structures in counter.h are used by driver
callbacks to interact with the Generic Counter interface, and thus need
to be exposed. There are some helper functions (for example, the
counter_count_enum_read and counter_count_enum_write functions) which
are not expected to be used directly by drivers, but as prepackaged
functionality to populate macros (COUNTER_COUNT_ENUM in this case); in
these cases, it is still necessary to expose these functions because the
exposed macros are dependent on them.

However, having such a large header file can be difficult for a human to
parse and debug. Would it make sense for me to break this single large
header file into several smaller header files by categories (e.g.
counter_signal.h, counter_count.h, counter_count_enum.h, etc.), and
use include lines to form a more concise counter.h header file?

>> +menuconfig COUNTER
>> +	tristate "Counter support"
>> +	help
>> +	  Provides Generic Counter interface support for counter devices.
>> +
>> +	  Counter devices are prevalent within a diverse spectrum of industries.
>> +	  The ubiquitous presence of these devices necessitates a common
>> +	  interface and standard of interaction and exposure. This driver API
>> +	  attempts to resolve the issue of duplicate code found among existing
>> +	  counter device drivers by providing a generic counter interface for
>> +	  consumption. The Generic Counter interface enables drivers to support
>> +	  and expose a common set of components and functionality present in
>> +	  counter devices.
>
>No need to explain an "API" in a Kconfig help text, which is for a user
>of the kernel, not for someone writing kernel code.  Odds are individual
>drivers will need to select this, or are you going to depend on this
>option?

I'm not sure if there will be situation where a user will want to
compile generic-counter.c without a counter device driver, so we can go
with the select style for now unless a need comes up for depend. I'll
simplify the Kconfig text according.

>> diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile
>> new file mode 100644
>> index 000000000000..ad1ba7109cdc
>> --- /dev/null
>> +++ b/drivers/counter/Makefile
>> @@ -0,0 +1,8 @@
>> +#
>> +# Makefile for Counter devices
>> +#
>> +
>> +# When adding new entries keep the list in alphabetical order
>
>Why does it matter?  :)

Fair point, I'll take this comment out.

>> +
>> +obj-$(CONFIG_COUNTER) += counter.o
>> +counter-y := generic-counter.o
>
>Why not just call your .c file, "counter.c" to keep this simple?

This is a hold over from when counter.c was composed of multiple files.
I'll rename generic-counter.c to counter.c in order to simplify this
line.

>> diff --git a/drivers/counter/generic-counter.c b/drivers/counter/generic-counter.c
>> new file mode 100644
>> index 000000000000..483826c8ce01
>> --- /dev/null
>> +++ b/drivers/counter/generic-counter.c
>> @@ -0,0 +1,1519 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>
>Please use the normal SPDX identifiers we are using, as described in the
>kernel documentation.  We aren't ready to use the "new" ones just yet.
>
>> +/*
>> + * Generic Counter interface
>> + * Copyright (C) 2017 William Breathitt Gray
>
>It's 2018 now :)

No problem, I'll update the year text as well as the SPDX identifiers
throughout the files in this patchset.

>> + */
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/fs.h>
>> +#include <linux/gfp.h>
>> +#include <linux/idr.h>
>> +#include <linux/init.h>
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/printk.h>
>> +#include <linux/slab.h>
>> +#include <linux/string.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/types.h>
>> +
>> +#include <linux/counter.h>
>
>Why a blank line?

I'll clean this up.

>> +
>> +const char *const count_direction_str[2] = {
>> +	[COUNT_DIRECTION_FORWARD] = "forward",
>> +	[COUNT_DIRECTION_BACKWARD] = "backward"
>> +};
>> +EXPORT_SYMBOL(count_direction_str);
>
>I have to ask, for all of these, why not EXPORT_SYMBOL_GPL()?

This was an oversight: I intend for all of these to be
EXPORT_SYMBOL_GPL. I'll fix these in the next revision.

>> +
>> +const char *const count_mode_str[4] = {
>> +	[COUNT_MODE_NORMAL] = "normal",
>> +	[COUNT_MODE_RANGE_LIMIT] = "range limit",
>> +	[COUNT_MODE_NON_RECYCLE] = "non-recycle",
>> +	[COUNT_MODE_MODULO_N] = "modulo-n"
>> +};
>> +EXPORT_SYMBOL(count_mode_str);
>
>And why do you need to export strings?

The idea is to provide a lookup table of string constants so that driver
callbacks return consistent count_mode values to userspace. The
count_mode sysfs attribute is implemented via a counter_count_enum_ext
structure which takes an array of possible string options available, so
that is why this particular string array is exported. The driver
callbacks interact only with the index defines (COUNT_MODE_NORMAL,
COUNT_MODE_RANGE_LIMIT, etc.), while the respective string constants are
found in the array and supplied to/from userspace via the predefined
Generic Counter counter_count_enum_read/counter_count_enum_write
functions.

>> +
>> +ssize_t counter_signal_enum_read(struct counter_device *counter,
>> +				 struct counter_signal *signal, void *priv,
>> +				 char *buf)
>> +{
>> +	const struct counter_signal_enum_ext *const e = priv;
>> +	int err;
>> +	size_t index;
>> +
>> +	if (!e->get)
>> +		return -EINVAL;
>
>How can e->get not be set?  Shouldn't you just not have called into this
>if so?

e->get is a callback provided by the driver and may not be set. This
configuration is possible if the device does not provide a read
functionality for its options, but does permit write operations for
those options.

counter_signal_enum_read is used as a helper function to build the
COUNTER_SIGNAL_ENUM macro (as the read callback). Since
COUNTER_SIGNAL_ENUM is intended to be general, the
counter_signal_enum_read is set as the read callback unconditionally --
this means e->get can't be checked before but must instead be checked
from within to handle cases where the device does not support reads.

>> +
>> +	err = e->get(counter, signal, &index);
>> +	if (err)
>> +		return err;
>> +
>> +	if (index >= e->num_items)
>> +		return -EINVAL;
>> +
>> +	return scnprintf(buf, PAGE_SIZE, "%s\n", e->items[index]);
>
>No need to do the scnprintf() crud, it's a sysfs file, a simple
>sprintf() works just fine.  Yeah, it makes people nervous, and it should :)

Okay, I'll use sprintf in these situations.

>> +}
>> +EXPORT_SYMBOL(counter_signal_enum_read);
>
>sysfs attribute files really should be EXPORT_SYMBOL_GPL() please.
>
>> +
>> +ssize_t counter_signal_enum_write(struct counter_device *counter,
>> +				  struct counter_signal *signal, void *priv,
>> +				  const char *buf, size_t len)
>> +{
>> +	const struct counter_signal_enum_ext *const e = priv;
>> +	ssize_t index;
>> +	int err;
>> +
>> +	if (!e->set)
>> +		return -EINVAL;
>
>Again, how can this be true?

This is the same situation as counter_signal_enum_read, but for write
operations instead of reads.

>> +
>> +	index = __sysfs_match_string(e->items, e->num_items, buf);
>> +	if (index < 0)
>> +		return index;
>> +
>> +	err = e->set(counter, signal, index);
>> +	if (err)
>> +		return err;
>> +
>> +	return len;
>> +}
>> +EXPORT_SYMBOL(counter_signal_enum_write);
>> +
>> +ssize_t counter_signal_enum_available_read(struct counter_device *counter,
>> +					   struct counter_signal *signal,
>> +					   void *priv, char *buf)
>> +{
>> +	const struct counter_signal_enum_ext *const e = priv;
>> +	size_t i;
>> +	size_t len = 0;
>> +
>> +	if (!e->num_items)
>> +		return 0;
>> +
>> +	for (i = 0; i < e->num_items; i++)
>> +		len += scnprintf(buf + len, PAGE_SIZE - len, "%s\n",
>> +			e->items[i]);
>
>a list of items?  In sysfs?  Are you _SURE_ you want to do that?

I'm modeling this behavior on the IIO *_available sysfs attributes. I
realize sysfs attributes are suppose to display only a single piece of
information, but I believe this is acceptable in this case due the
existing usage present in IIO. I'm open to a different design, but I
think a list is the most straight-forward way to expose the available
options provided by the device.

>> +
>> +	return len;
>> +}
>> +EXPORT_SYMBOL(counter_signal_enum_available_read);
>> +
>> +ssize_t counter_count_enum_read(struct counter_device *counter,
>> +				struct counter_count *count, void *priv,
>> +				char *buf)
>> +{
>> +	const struct counter_count_enum_ext *const e = priv;
>> +	int err;
>> +	size_t index;
>> +
>> +	if (!e->get)
>> +		return -EINVAL;
>
>
>Same comment everywhere for this...
>
>let's skip lower in the files...
>
>> +static int counter_attribute_create(
>> +	struct counter_device_attr_group *const group,
>> +	const char *const prefix,
>> +	const char *const name,
>> +	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
>> +			char *buf),
>> +	ssize_t (*store)(struct device *dev, struct device_attribute *attr,
>> +			 const char *buf, size_t len),
>
>Typedefs for these function pointers are good to have.
>
>> +	void *const component)
>
>That's a crazy list of parameters...

These are a bit verbose, so I'll rework it with some typedefs to
simplify this parameter list.

>> +{
>> +	struct counter_device_attr *counter_attr;
>> +	struct device_attribute *dev_attr;
>> +	int err;
>> +	struct list_head *const attr_list = &group->attr_list;
>> +
>> +	/* Allocate a Counter device attribute */
>> +	counter_attr = kzalloc(sizeof(*counter_attr), GFP_KERNEL);
>> +	if (!counter_attr)
>> +		return -ENOMEM;
>> +	dev_attr = &counter_attr->dev_attr;
>> +
>> +	sysfs_attr_init(&dev_attr->attr);
>> +
>> +	/* Configure device attribute */
>> +	dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, name);
>> +	if (!dev_attr->attr.name) {
>> +		err = -ENOMEM;
>> +		goto err_free_counter_attr;
>> +	}
>> +	if (show) {
>> +		dev_attr->attr.mode |= 0444;
>> +		dev_attr->show = show;
>> +	}
>> +	if (store) {
>> +		dev_attr->attr.mode |= 0200;
>> +		dev_attr->store = store;
>> +	}
>> +
>> +	/* Store associated Counter component with attribute */
>> +	counter_attr->component = component;
>> +
>> +	/* Keep track of the attribute for later cleanup */
>> +	list_add(&counter_attr->l, attr_list);
>> +	group->num_attr++;
>
>So you are dynamically creating sysfs attributes?  Why not just have one
>big group and only enable them if needed?  That would make things a lot
>simpler, right?

Counter device drivers are permitted to supply their own extension
structures to enable the configuration of various miscellaneous features
provided by the device; since these may be extensions are unique to each
driver, the respective sysfs attributes must be dynamically generated
because they are not known by the Generic Counter system beforehand.

In order to avoid code duplication, I also leverage this function to
generate the standard Generic Counter interface sysfs attributes as
well; that's why you see all components end up here regardless of
whether they are standard or extensions.

>> +struct signal_comp_t {
>
>"_t"???

These are helper containers to hold component-relevant data to pass down
when using the generic counter_attribute_create to generate the sysfs
attributes. The *_t naming convention may not be appropriate for this
case, so I can rename them to *_container or something along those
lines.

>> +	struct counter_signal	*signal;
>> +};
>> +
>> +static ssize_t counter_signal_show(struct device *dev,
>> +				   struct device_attribute *attr, char *buf)
>> +{
>> +	struct counter_device *const counter = dev_get_drvdata(dev);
>> +	const struct counter_device_attr *const devattr = to_counter_attr(attr);
>> +	const struct signal_comp_t *const component = devattr->component;
>> +	struct counter_signal *const signal = component->signal;
>> +	int err;
>> +	struct signal_read_value val = { .buf = buf };
>> +
>> +	err = counter->ops->signal_read(counter, signal, &val);
>> +	if (err)
>> +		return err;
>> +
>> +	return val.len;
>> +}
>> +
>> +struct name_comp_t {
>
>"_t"???
>
>Same for the rest of this file...
>
>> diff --git a/include/linux/counter.h b/include/linux/counter.h
>> new file mode 100644
>> index 000000000000..88fc82ee30a7
>> --- /dev/null
>> +++ b/include/linux/counter.h
>> @@ -0,0 +1,534 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>
>Same identifier issue.
>
>> +/*
>> + * Counter interface
>> + * Copyright (C) 2017 William Breathitt Gray
>
>2018!
>
>And again, it looks like this file can be a lot smaller, but I don't see
>a user of it just yet, so I don't really know...
>
>thanks,
>
>greg k-h

I'll make the updates noted in a version 8 submission, but I'll wait to
submit it until you have a chance to review the rest of this current
patchset. The counter device drivers in this directory (104-quad-8.c,
stm32-lptimer-cnt.c, stm32-timer-cnt.c) should give you an idea of how
the counter.h file is used at the moment.

Thank you,

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-07-09 17:40     ` William Breathitt Gray
@ 2018-07-09 18:54       ` Greg KH
  2018-07-09 18:56         ` William Breathitt Gray
  0 siblings, 1 reply; 41+ messages in thread
From: Greg KH @ 2018-07-09 18:54 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On Mon, Jul 09, 2018 at 01:40:36PM -0400, William Breathitt Gray wrote:
> I'll make the updates noted in a version 8 submission, but I'll wait to
> submit it until you have a chance to review the rest of this current
> patchset. The counter device drivers in this directory (104-quad-8.c,
> stm32-lptimer-cnt.c, stm32-timer-cnt.c) should give you an idea of how
> the counter.h file is used at the moment.

Please do not wait for me, I will not have a chance to review the other
patches anytime soon.

greg k-h

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-07-09 18:54       ` Greg KH
@ 2018-07-09 18:56         ` William Breathitt Gray
  0 siblings, 0 replies; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-09 18:56 UTC (permalink / raw)
  To: Greg KH
  Cc: jic23, linux-arm-kernel, devicetree, linux-kernel, linux-iio,
	fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h, lars,
	pmeerw, mark.rutland

On Mon, Jul 09, 2018 at 08:54:17PM +0200, Greg KH wrote:
>On Mon, Jul 09, 2018 at 01:40:36PM -0400, William Breathitt Gray wrote:
>> I'll make the updates noted in a version 8 submission, but I'll wait to
>> submit it until you have a chance to review the rest of this current
>> patchset. The counter device drivers in this directory (104-quad-8.c,
>> stm32-lptimer-cnt.c, stm32-timer-cnt.c) should give you an idea of how
>> the counter.h file is used at the moment.
>
>Please do not wait for me, I will not have a chance to review the other
>patches anytime soon.
>
>greg k-h

All right, I'll go ahead and proceed with these changes for now then.

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-06-21 21:07 ` [PATCH v7 01/10] counter: Introduce the Generic Counter interface William Breathitt Gray
  2018-07-07 15:16   ` Greg KH
@ 2018-07-18  3:49   ` Andrew Morton
  2018-07-21 16:26     ` William Breathitt Gray
  1 sibling, 1 reply; 41+ messages in thread
From: Andrew Morton @ 2018-07-18  3:49 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Thu, 21 Jun 2018 17:07:08 -0400 William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> This patch introduces the Generic Counter interface for supporting
> counter devices.
> 

+EXPORT_SYMBOL(count_direction_str);
+EXPORT_SYMBOL(count_mode_str);
+EXPORT_SYMBOL(counter_signal_enum_read);
+EXPORT_SYMBOL(counter_signal_enum_write);
+EXPORT_SYMBOL(counter_signal_enum_available_read);
+EXPORT_SYMBOL(counter_count_enum_read);
+EXPORT_SYMBOL(counter_count_enum_write);
+EXPORT_SYMBOL(counter_count_enum_available_read);
+EXPORT_SYMBOL(counter_device_enum_read);
+EXPORT_SYMBOL(counter_device_enum_write);
+EXPORT_SYMBOL(counter_device_enum_available_read);
+EXPORT_SYMBOL(signal_read_value_set);
+EXPORT_SYMBOL(count_read_value_set);
+EXPORT_SYMBOL(count_write_value_get);
+EXPORT_SYMBOL(counter_register);
+EXPORT_SYMBOL(counter_unregister);
+EXPORT_SYMBOL(devm_counter_register);
+EXPORT_SYMBOL(devm_counter_unregister);

The naming is a bit chaotic.  Most of the symbols start with counter_,
which is good.  But a handful do not.

Also, symbols called signal_* make my head spin - Linux already has a
firmly ingrained notion of what a signal is, and this ain't it ;)
Although the kernel tends to use sig_ for signals-as-an-IPC-thing.

Also, many many drivers deal with signals-as-an-electrical-thing - is
it appropriate for this particular driver to take that namespace?


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-07-18  3:49   ` Andrew Morton
@ 2018-07-21 16:26     ` William Breathitt Gray
  2018-07-22  5:41       ` Andrew Morton
  0 siblings, 1 reply; 41+ messages in thread
From: William Breathitt Gray @ 2018-07-21 16:26 UTC (permalink / raw)
  To: Andrew Morton
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Tue, Jul 17, 2018 at 08:49:54PM -0700, Andrew Morton wrote:
>On Thu, 21 Jun 2018 17:07:08 -0400 William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
>
>> This patch introduces the Generic Counter interface for supporting
>> counter devices.
>> 
>
>+EXPORT_SYMBOL(count_direction_str);
>+EXPORT_SYMBOL(count_mode_str);
>+EXPORT_SYMBOL(counter_signal_enum_read);
>+EXPORT_SYMBOL(counter_signal_enum_write);
>+EXPORT_SYMBOL(counter_signal_enum_available_read);
>+EXPORT_SYMBOL(counter_count_enum_read);
>+EXPORT_SYMBOL(counter_count_enum_write);
>+EXPORT_SYMBOL(counter_count_enum_available_read);
>+EXPORT_SYMBOL(counter_device_enum_read);
>+EXPORT_SYMBOL(counter_device_enum_write);
>+EXPORT_SYMBOL(counter_device_enum_available_read);
>+EXPORT_SYMBOL(signal_read_value_set);
>+EXPORT_SYMBOL(count_read_value_set);
>+EXPORT_SYMBOL(count_write_value_get);
>+EXPORT_SYMBOL(counter_register);
>+EXPORT_SYMBOL(counter_unregister);
>+EXPORT_SYMBOL(devm_counter_register);
>+EXPORT_SYMBOL(devm_counter_unregister);
>
>The naming is a bit chaotic.  Most of the symbols start with counter_,
>which is good.  But a handful do not.

I can prefix these exported symbols with "counter_" to help make it
clear they all belong to the Generic Counter API. I'll keep the devm_*
symbols the same to match the naming convention in the other subsystems
I see (watchdog, IIO, GPIO, etc.).

>
>Also, symbols called signal_* make my head spin - Linux already has a
>firmly ingrained notion of what a signal is, and this ain't it ;)
>Although the kernel tends to use sig_ for signals-as-an-IPC-thing.
>
>Also, many many drivers deal with signals-as-an-electrical-thing - is
>it appropriate for this particular driver to take that namespace?

In the context of the Generic Counter paradigm, a "Signal" is an
abstraction for the stream of data that is fed to the counter device for
evaluation (triggering updates for the readable "Count"). In many cases
a "Signal" correlates with a physical electrical line (for example the A
and B electrical lines for a quadrature encoder), but this isn't a hard
requirement as the paradigm permits more abstract data streams.

I decided on "Signal" to match the naming convention that appears in the
datasheets of many counter devices, but "Line" may be a decent
alternative name we could use to indicate a counter device input data
stream.

I'd like to get some other opinions as well before I make a naming
change to "Signal" -- whether to stay with "Signal," switch to "Line," or
rename to something else. For what it's worth, I think it's unlikely for
a counter device driver author to confuse a Counter Signal with the
Linux OS signal within the context of the Generic Counter paradigm and
their respective counter device datasheet.

William Breathitt Gray

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
  2018-07-21 16:26     ` William Breathitt Gray
@ 2018-07-22  5:41       ` Andrew Morton
  0 siblings, 0 replies; 41+ messages in thread
From: Andrew Morton @ 2018-07-22  5:41 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: gregkh, jic23, linux-arm-kernel, devicetree, linux-kernel,
	linux-iio, fabrice.gasnier, benjamin.gaignard, robh+dt, knaack.h,
	lars, pmeerw, mark.rutland

On Sat, 21 Jul 2018 12:26:10 -0400 William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> >Also, many many drivers deal with signals-as-an-electrical-thing - is
> >it appropriate for this particular driver to take that namespace?
> 
> In the context of the Generic Counter paradigm, a "Signal" is an
> abstraction for the stream of data that is fed to the counter device for
> evaluation (triggering updates for the readable "Count"). In many cases
> a "Signal" correlates with a physical electrical line (for example the A
> and B electrical lines for a quadrature encoder), but this isn't a hard
> requirement as the paradigm permits more abstract data streams.
> 
> I decided on "Signal" to match the naming convention that appears in the
> datasheets of many counter devices, but "Line" may be a decent
> alternative name we could use to indicate a counter device input data
> stream.
> 
> I'd like to get some other opinions as well before I make a naming
> change to "Signal" -- whether to stay with "Signal," switch to "Line," or
> rename to something else. For what it's worth, I think it's unlikely for
> a counter device driver author to confuse a Counter Signal with the
> Linux OS signal within the context of the Generic Counter paradigm and
> their respective counter device datasheet.

gc_signal_* would be better.  That retains "signal", but makes
it clear that the symbols belong to generic counter.

^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2018-07-22  5:41 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-21 21:06 [PATCH v7 00/10] Introduce the Counter subsystem William Breathitt Gray
2018-06-21 21:07 ` [PATCH v7 01/10] counter: Introduce the Generic Counter interface William Breathitt Gray
2018-07-07 15:16   ` Greg KH
2018-07-09 17:40     ` William Breathitt Gray
2018-07-09 18:54       ` Greg KH
2018-07-09 18:56         ` William Breathitt Gray
2018-07-18  3:49   ` Andrew Morton
2018-07-21 16:26     ` William Breathitt Gray
2018-07-22  5:41       ` Andrew Morton
2018-06-21 21:07 ` [PATCH v7 02/10] counter: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
2018-07-02 19:11   ` [v7, " David Lechner
2018-07-03 14:04     ` William Breathitt Gray
2018-06-21 21:07 ` [PATCH v7 03/10] docs: Add Generic Counter interface documentation William Breathitt Gray
2018-06-22 16:51   ` Jonathan Cameron
2018-07-02 19:37   ` [v7,03/10] " David Lechner
2018-07-03 14:16     ` William Breathitt Gray
2018-07-04 17:23       ` Linus Walleij
2018-07-06 17:15         ` Jonathan Cameron
2018-07-06 18:25           ` David Lechner
2018-07-02 19:42   ` David Lechner
2018-07-03 14:21     ` William Breathitt Gray
2018-06-21 21:07 ` [PATCH v7 04/10] counter: 104-quad-8: Add Generic Counter interface support William Breathitt Gray
2018-06-22 16:57   ` Jonathan Cameron
2018-06-21 21:08 ` [PATCH v7 05/10] counter: 104-quad-8: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
2018-06-22 16:59   ` Jonathan Cameron
2018-06-21 21:08 ` [PATCH v7 06/10] counter: Add STM32 Timer quadrature encoder William Breathitt Gray
2018-06-22 17:03   ` Jonathan Cameron
2018-06-21 21:08 ` [PATCH v7 07/10] dt-bindings: counter: Document stm32 " William Breathitt Gray
2018-07-02 19:56   ` [v7,07/10] " David Lechner
2018-07-05 21:13   ` [PATCH v7 07/10] " Rob Herring
2018-06-21 21:08 ` [PATCH v7 08/10] counter: stm32-lptimer: add counter device William Breathitt Gray
2018-06-22 17:06   ` Jonathan Cameron
2018-06-21 21:08 ` [PATCH v7 09/10] dt-bindings: counter: Adjust dt-bindings for STM32 lptimer move William Breathitt Gray
2018-07-05 21:13   ` Rob Herring
2018-06-21 21:09 ` [PATCH v7 10/10] iio: counter: Add deprecation markings for IIO Counter attributes William Breathitt Gray
2018-06-22 17:10 ` [PATCH v7 00/10] Introduce the Counter subsystem Jonathan Cameron
2018-07-02 18:13 ` David Lechner
2018-07-03  2:48   ` William Breathitt Gray
2018-07-06 17:21     ` Jonathan Cameron
2018-07-06 18:22       ` David Lechner
2018-07-06 19:20         ` 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).