From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: jic23@kernel.org, benjamin.gaignard@linaro.org, knaack.h@gmx.de,
lars@metafoo.de, pmeerw@pmeerw.net
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
William Breathitt Gray <vilhelm.gray@gmail.com>
Subject: [PATCH v3 0/6] iio: Introduce the generic counter interface
Date: Thu, 5 Oct 2017 14:13:14 -0400 [thread overview]
Message-ID: <cover.1507220144.git.vilhelm.gray@gmail.com> (raw)
There have been some significant implementation changes for this version
of the patchset. Here's a brief summary of the updates:
- Inline comments throughout the industrial-counter.c file; this
should help clarify some of the code and aid in the review of the
system architecture
- Simplification of the driver API; primarily, dynamic updates to the
Counter Values, Triggers, and Signals lists are no longer allowed --
all relationships must be defined before the Counter is registered to
the system
- Dynamic component registration functions
(iio_counter_value_register, et al.) have been removed, and now the
signals, values, and triggers array members serve to register the
components; signals, values, and triggers were previously named
init_signals, init_values, and init_triggers respectively -- the
"init_" prefix was removed now that dynamic registration is no longer
allowed
- Requiring static component relationships means linked lists are no
longer necessary so all the list related code has been removed;
Signals, Triggers, and Values are now accessed directly from the
arrays supplied in the iio_counter structure
- No dynamic additions/substraction of components eliminates the need
for mutex locks, so those have been removed as well
- Previously, the entire iio_counter structure was copied and stored as
the iio_dev private data; now, only a pointer to the supplied
iio_counter structure is stored
- devm_iio_counter_register and devm_iio_counter_unregister functions
were incorporated from Benjamin Gaignard's suggestions
- Dummy counter driver provided as a reference for a simple counter
implementation utilizing the Generic Counter interface
In a previous discussion, Benjamin noted some conflicts between the
Generic Counter and the underlying IIO core code: mapping does not
always work out seemlessly and sometimes the IIO core functionality
exposure provided via iio_counter is not quite flexible enough. I intend
to address these shortcomings in the next version of this patchset
hopefully.
In particular, I'm leaning towards separating the Generic Counter
interface from the IIO core dependency entirely. Since the Generic
Counter inteface focuses on a more abstract representation of a counter
device, I don't think it provides a suitable interface to map onto IIO
core, which appears to focus more on a representation of the physical
hardware itself.
Separating Generic Counter from IIO core should allow a driver to use
the IIO core functions (iio_device_register, et al.) to represent the
physical nature of their hardware (voltages, currents, etc.), while also
utilize the Generic Counter interface to represent the abstract
relationships between those Signals and their ultimate counter Values.
In particular, I'm hoping for the Generic Counter system implementation
itself to not require all this hoop-jumping (mapping to IIO core
functions, jumping back to the parent iio_counter, handling non-matching
parameter lists between iio_counter and iio_dev, etc.); that should make
the code simpler to debug, more efficient, and more stable in the
long-run. I will consider these advantages and disadvantages before
committing to a separation however.
Regarding this version of the patchset in particular, I decided to
remove the dynamic component registration functionality since I doubt
that many devices would require such; almost all, if not all, hardware
counters I encountered have static relationships between input lines and
the count value (i.e. specific input lines correlate to specific count
registers).
The requirement that Counter component relationships are
static has opened the possibility of some optimizations in the Generic
Counter interface code:
- Signals, Triggers, and Values are provided as arrays; these arrays
could benefit from some amount of sorting based on component IDs
- Searching for a component can be more efficient in a sorted array;
currently, the code just walks down the array elements and compare
the IDs
- Similar to general searching, the arrays are initially verified to
gurantee unique IDs; currently, the code walks down the array
elements and compares the current element ID with all the elements
before and after -- this could be made more efficient with some
sorting
There are likely other areas of improvement, so let me know and I'll see
what I can do.
William Breathitt Gray (6):
iio: Implement counter channel specification and IIO_SIGNAL constant
iio: Introduce the generic counter interface
iio: Documentation: Add IIO Generic Counter sysfs documentation
docs: Add IIO Generic Counter Interface documentation
iio: Add dummy counter driver
iio: 104-quad-8: Add IIO generic counter interface support
.../testing/sysfs-bus-iio-generic-counter-sysfs | 63 ++
Documentation/driver-api/iio/generic-counter.txt | 526 ++++++++++++
MAINTAINERS | 7 +
drivers/iio/Kconfig | 8 +
drivers/iio/Makefile | 1 +
drivers/iio/counter/104-quad-8.c | 294 ++++++-
drivers/iio/counter/Kconfig | 16 +
drivers/iio/counter/Makefile | 1 +
drivers/iio/counter/dummy-counter.c | 293 +++++++
drivers/iio/industrialio-core.c | 14 +-
drivers/iio/industrialio-counter.c | 900 +++++++++++++++++++++
include/linux/iio/counter.h | 166 ++++
include/linux/iio/iio.h | 2 +
include/uapi/linux/iio/types.h | 1 +
14 files changed, 2274 insertions(+), 18 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-generic-counter-sysfs
create mode 100644 Documentation/driver-api/iio/generic-counter.txt
create mode 100644 drivers/iio/counter/dummy-counter.c
create mode 100644 drivers/iio/industrialio-counter.c
create mode 100644 include/linux/iio/counter.h
--
2.14.1
next reply other threads:[~2017-10-05 18:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 18:13 William Breathitt Gray [this message]
2017-10-05 18:13 ` [PATCH v3 1/6] iio: Implement counter channel specification and IIO_SIGNAL constant William Breathitt Gray
2017-10-08 11:57 ` Jonathan Cameron
2017-10-05 18:13 ` [PATCH v3 2/6] iio: Introduce the generic counter interface William Breathitt Gray
2017-10-08 14:30 ` Jonathan Cameron
2017-10-09 12:56 ` Benjamin Gaignard
2017-10-05 18:13 ` [PATCH v3 3/6] iio: Documentation: Add IIO Generic Counter sysfs documentation William Breathitt Gray
2017-10-08 12:10 ` Jonathan Cameron
2017-10-05 18:14 ` [PATCH v3 4/6] docs: Add IIO Generic Counter Interface documentation William Breathitt Gray
2017-10-08 13:19 ` Jonathan Cameron
2017-10-05 18:14 ` [PATCH v3 5/6] iio: Add dummy counter driver William Breathitt Gray
2017-10-08 13:41 ` Jonathan Cameron
2017-10-09 12:35 ` Benjamin Gaignard
2017-10-05 18:14 ` [PATCH v3 6/6] iio: 104-quad-8: Add IIO generic counter interface support William Breathitt Gray
2017-10-08 13:44 ` Jonathan Cameron
2017-10-08 14:38 ` [PATCH v3 0/6] iio: Introduce the generic counter interface Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1507220144.git.vilhelm.gray@gmail.com \
--to=vilhelm.gray@gmail.com \
--cc=benjamin.gaignard@linaro.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox