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.
>
Documentation?
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.
> Signed-off-by: David Lechner <[email protected]>
> ---
> drivers/iio/industrialio-core.c | 1 +
> include/uapi/linux/iio/types.h | 1 +
> tools/iio/iio_event_monitor.c | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 19bdf3d2962a..f3c2c9e4b997 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -85,6 +85,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_COUNT] = "count",
> [IIO_INDEX] = "index",
> [IIO_GRAVITY] = "gravity",
> + [IIO_FREQUENCY] = "frequency",
> };
>
> static const char * const iio_modifier_names[] = {
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 4213cdf88e3c..9fee86e2046f 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -44,6 +44,7 @@ enum iio_chan_type {
> IIO_COUNT,
> IIO_INDEX,
> IIO_GRAVITY,
> + IIO_FREQUENCY,
> };
>
> enum iio_modifier {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index b61245e1181d..c3ef20057d52 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -58,6 +58,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_PH] = "ph",
> [IIO_UVINDEX] = "uvindex",
> [IIO_GRAVITY] = "gravity",
> + [IIO_FREQUENCY] = "frequency",
> };
>
> static const char * const iio_ev_type_text[] = {
>
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.
>>
>
> Documentation?
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.
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.
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.
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.
>
>> Signed-off-by: David Lechner <[email protected]>
>> ---
>> drivers/iio/industrialio-core.c | 1 +
>> include/uapi/linux/iio/types.h | 1 +
>> tools/iio/iio_event_monitor.c | 1 +
>> 3 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
>> index 19bdf3d2962a..f3c2c9e4b997 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -85,6 +85,7 @@ static const char * const iio_chan_type_name_spec[] = {
>> [IIO_COUNT] = "count",
>> [IIO_INDEX] = "index",
>> [IIO_GRAVITY] = "gravity",
>> + [IIO_FREQUENCY] = "frequency",
>> };
>>
>> static const char * const iio_modifier_names[] = {
>> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
>> index 4213cdf88e3c..9fee86e2046f 100644
>> --- a/include/uapi/linux/iio/types.h
>> +++ b/include/uapi/linux/iio/types.h
>> @@ -44,6 +44,7 @@ enum iio_chan_type {
>> IIO_COUNT,
>> IIO_INDEX,
>> IIO_GRAVITY,
>> + IIO_FREQUENCY,
>> };
>>
>> enum iio_modifier {
>> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
>> index b61245e1181d..c3ef20057d52 100644
>> --- a/tools/iio/iio_event_monitor.c
>> +++ b/tools/iio/iio_event_monitor.c
>> @@ -58,6 +58,7 @@ static const char * const iio_chan_type_name_spec[] = {
>> [IIO_PH] = "ph",
>> [IIO_UVINDEX] = "uvindex",
>> [IIO_GRAVITY] = "gravity",
>> + [IIO_FREQUENCY] = "frequency",
>> };
>>
>> static const char * const iio_ev_type_text[] = {
>>
>
On Sun, 1 Jul 2018 17:24:34 -0500
David Lechner <[email protected]> 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.
> >>
> >
> > Documentation?
>
> I take it that you mean Documentation/ABI/testing/sysfs-bus-iio? Or
> somewhere else too?
Yes.
>
> >
> > 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?
https://lkml.org/lkml/2018/6/21/659
>
> 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
well).
Jonathan
>
> >
> >> Signed-off-by: David Lechner <[email protected]>
> >> ---
> >> drivers/iio/industrialio-core.c | 1 +
> >> include/uapi/linux/iio/types.h | 1 +
> >> tools/iio/iio_event_monitor.c | 1 +
> >> 3 files changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> >> index 19bdf3d2962a..f3c2c9e4b997 100644
> >> --- a/drivers/iio/industrialio-core.c
> >> +++ b/drivers/iio/industrialio-core.c
> >> @@ -85,6 +85,7 @@ static const char * const iio_chan_type_name_spec[] = {
> >> [IIO_COUNT] = "count",
> >> [IIO_INDEX] = "index",
> >> [IIO_GRAVITY] = "gravity",
> >> + [IIO_FREQUENCY] = "frequency",
> >> };
> >>
> >> static const char * const iio_modifier_names[] = {
> >> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> >> index 4213cdf88e3c..9fee86e2046f 100644
> >> --- a/include/uapi/linux/iio/types.h
> >> +++ b/include/uapi/linux/iio/types.h
> >> @@ -44,6 +44,7 @@ enum iio_chan_type {
> >> IIO_COUNT,
> >> IIO_INDEX,
> >> IIO_GRAVITY,
> >> + IIO_FREQUENCY,
> >> };
> >>
> >> enum iio_modifier {
> >> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> >> index b61245e1181d..c3ef20057d52 100644
> >> --- a/tools/iio/iio_event_monitor.c
> >> +++ b/tools/iio/iio_event_monitor.c
> >> @@ -58,6 +58,7 @@ static const char * const iio_chan_type_name_spec[] = {
> >> [IIO_PH] = "ph",
> >> [IIO_UVINDEX] = "uvindex",
> >> [IIO_GRAVITY] = "gravity",
> >> + [IIO_FREQUENCY] = "frequency",
> >> };
> >>
> >> static const char * const iio_ev_type_text[] = {
> >>
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/02/2018 08:03 AM, Jonathan Cameron wrote:
> On Sun, 1 Jul 2018 17:24:34 -0500
> David Lechner <[email protected]> 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.
>>>>
>>>
>>> Documentation?
>>
>> I take it that you mean Documentation/ABI/testing/sysfs-bus-iio? Or
>> somewhere else too?
>
> Yes.
>
>>
>>>
>>> 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.
>
> https://lkml.org/lkml/2018/6/21/659
>
>>
>> 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
> well).
>
Agreed. Let's drop this patch.