Re: [PATCH] iio: add channel type for frequency

From: David Lechner
Date: Mon Jul 02 2018 - 11:34:02 EST

On 07/02/2018 08:03 AM, Jonathan Cameron wrote:
On Sun, 1 Jul 2018 17:24:34 -0500
David Lechner <david@xxxxxxxxxxxxxx> wrote:

On 07/01/2018 02:18 AM, Lars-Peter Clausen wrote:
On 07/01/2018 04:59 AM, David Lechner wrote:
This adds a new type for frequency to the IIO channel type enumeration.

Units are in Hz.


I take it that you mean Documentation/ABI/testing/sysfs-bus-iio? Or
somewhere else too?


We already have the altvoltage channel type with the frequency attribute.
Difficult to say if there are any overlaps without documentation on how this
new attribute is supposed to be used.

I'm basically trying to implement a quadrature encoder in iio. I want to be
able to use it in-kernel to get a rotational speed value for a motor.

Have you seen the counters subsystem work that is pretty much ready to merge?

I hadn't seen that. Thanks. It sounds like the way to go since I am dealing with
a quadrature encoder.

The motors (and encoder wheels) are hot-swapable, so we don't know how many
counts from the quadrature encoder equals one rotation because it depends on
which motor is being used. So using IIO_ANGL_VEL doesn't work for this case.

Hmm. This always ugly when we have hotswappable external devices. Ideal is
to describe them with device tree or similar none the less as this stuff isn't
really something userspace should have to figure out.

It seems to me that the proper generic unit for "speed" from the quadrature
encoder would be counts per second, hence the suggestion of a frequency unit.

It is probably not that clear cut, as what is it frequency of? All depends on
what mode the quadrature counter is working in x4 or x1 for simplest options.

I'm not sure if voltage frequency works here since a "count" on a quadrature
encoder is derived from two different voltage signals (and may vary depending
on how the encoder determines what one count it).

Also, unrelated to my quadrature encoder project, I was thinking that
frequency counters would use this unit as well (although the voltage alt
makes more sense for this case).

There are also sound sensors that measure frequency that could use this unit.

I have not fundamental issue with having a frequency channel, but only
if we have a clear cut use case. I suspect the right option here is to
look at what extensions are needed to William's counter subsystem instead
of in IIO (which frankly failed to stretch far enough to support counters

Agreed. Let's drop this patch.