From: Xander Huff <xander.huff@ni.com>
To: Lars-Peter Clausen <lars@metafoo.de>,
Jonathan Cameron <jic23@kernel.org>,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org
Cc: michal.simek@xilinx.com, soren.brinkmann@xilinx.com,
knaack.h@gmx.de, pmeerw@pmeerw.net, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-iio@vger.kernel.org,
ben.shelton@ni.com, joshc@ni.com, joe.hershberger@ni.com
Subject: Re: [PATCH 2/2] iio: adc: xilinx-xadc: Add xlnx,extend-name as an optional argument for aux channels
Date: Tue, 26 May 2015 14:05:59 -0500 [thread overview]
Message-ID: <5564C417.3010707@ni.com> (raw)
In-Reply-To: <55643F20.4080306@metafoo.de>
On 5/26/2015 4:38 AM, Lars-Peter Clausen wrote:
> On 05/23/2015 01:23 PM, Jonathan Cameron wrote:
>> On 19/05/15 18:53, Lars-Peter Clausen wrote:
>>> On 05/08/2015 12:44 AM, Xander Huff wrote:
>>>> To better facilitate user-mode access to optional aux channels, allow
>>>> device trees to specify a custom extended name for defined channels.
>>>
>>> Hi,
>>>
>>> 'extend-name' is kind of a IIO specific term. I think a better name in the
>>> devicetree context would be 'label'. That's used everywhere else when giving
>>> a short description string to a node.
>>>
>> Hi Lars,
>>
>> What do you think of the general idea? I'm unconvinced we want to do this in
>> channel naming.
>> Perhaps we want an additional attribute giving access to this sort of
>> 'semantic' information?
>
> I'm not convinced about it either. My gut feeling is that this is not the right
> approach, but I don't really have any better ideas at the moment.
>
> Xander can you give a short description of how this information will be used by
> an application? Would having a label property for the channel also work for you
> (e.g. in_voltage0_label)?
>
> - Lars
>
We use 10 of the optional aux channels available in the XADC and have them wired
up to specific power supplies. For example, channel 9 is connected to the
current of a 6V power supply and channel 12 is connected to the voltage of that
same supply, channel 4 is connected to the current of a 3.3V power supply and
channel 5 is connected to its voltage.
Without adding extended names to distinguish these aux channels, the handles
available inside /sys/bus/iio/devices/[device] are generic: in_voltage10_raw,
in_voltage10_scale, for example. If I added the label 'user5v_v', then these
handles would be in_voltage10_user5v_v_raw and in_voltage10_user5v_v_scale. This
makes it a lot easier to get started and let the handles describe themselves,
rather than having to look up which channels are connected to which things.
As far as using 'label' instead of 'extend-name', that's fine with me. I've
already sent out a v2 using 'label' instead.
--
Xander Huff
Staff Software Engineer
National Instruments
WARNING: multiple messages have this Message-ID (diff)
From: xander.huff@ni.com (Xander Huff)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] iio: adc: xilinx-xadc: Add xlnx,extend-name as an optional argument for aux channels
Date: Tue, 26 May 2015 14:05:59 -0500 [thread overview]
Message-ID: <5564C417.3010707@ni.com> (raw)
In-Reply-To: <55643F20.4080306@metafoo.de>
On 5/26/2015 4:38 AM, Lars-Peter Clausen wrote:
> On 05/23/2015 01:23 PM, Jonathan Cameron wrote:
>> On 19/05/15 18:53, Lars-Peter Clausen wrote:
>>> On 05/08/2015 12:44 AM, Xander Huff wrote:
>>>> To better facilitate user-mode access to optional aux channels, allow
>>>> device trees to specify a custom extended name for defined channels.
>>>
>>> Hi,
>>>
>>> 'extend-name' is kind of a IIO specific term. I think a better name in the
>>> devicetree context would be 'label'. That's used everywhere else when giving
>>> a short description string to a node.
>>>
>> Hi Lars,
>>
>> What do you think of the general idea? I'm unconvinced we want to do this in
>> channel naming.
>> Perhaps we want an additional attribute giving access to this sort of
>> 'semantic' information?
>
> I'm not convinced about it either. My gut feeling is that this is not the right
> approach, but I don't really have any better ideas at the moment.
>
> Xander can you give a short description of how this information will be used by
> an application? Would having a label property for the channel also work for you
> (e.g. in_voltage0_label)?
>
> - Lars
>
We use 10 of the optional aux channels available in the XADC and have them wired
up to specific power supplies. For example, channel 9 is connected to the
current of a 6V power supply and channel 12 is connected to the voltage of that
same supply, channel 4 is connected to the current of a 3.3V power supply and
channel 5 is connected to its voltage.
Without adding extended names to distinguish these aux channels, the handles
available inside /sys/bus/iio/devices/[device] are generic: in_voltage10_raw,
in_voltage10_scale, for example. If I added the label 'user5v_v', then these
handles would be in_voltage10_user5v_v_raw and in_voltage10_user5v_v_scale. This
makes it a lot easier to get started and let the handles describe themselves,
rather than having to look up which channels are connected to which things.
As far as using 'label' instead of 'extend-name', that's fine with me. I've
already sent out a v2 using 'label' instead.
--
Xander Huff
Staff Software Engineer
National Instruments
WARNING: multiple messages have this Message-ID (diff)
From: Xander Huff <xander.huff-acOepvfBmUk@public.gmane.org>
To: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>,
Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Cc: michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
knaack.h-Mmb7MZpHnFY@public.gmane.org,
pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ben.shelton-acOepvfBmUk@public.gmane.org,
joshc-acOepvfBmUk@public.gmane.org,
joe.hershberger-acOepvfBmUk@public.gmane.org
Subject: Re: [PATCH 2/2] iio: adc: xilinx-xadc: Add xlnx,extend-name as an optional argument for aux channels
Date: Tue, 26 May 2015 14:05:59 -0500 [thread overview]
Message-ID: <5564C417.3010707@ni.com> (raw)
In-Reply-To: <55643F20.4080306-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
On 5/26/2015 4:38 AM, Lars-Peter Clausen wrote:
> On 05/23/2015 01:23 PM, Jonathan Cameron wrote:
>> On 19/05/15 18:53, Lars-Peter Clausen wrote:
>>> On 05/08/2015 12:44 AM, Xander Huff wrote:
>>>> To better facilitate user-mode access to optional aux channels, allow
>>>> device trees to specify a custom extended name for defined channels.
>>>
>>> Hi,
>>>
>>> 'extend-name' is kind of a IIO specific term. I think a better name in the
>>> devicetree context would be 'label'. That's used everywhere else when giving
>>> a short description string to a node.
>>>
>> Hi Lars,
>>
>> What do you think of the general idea? I'm unconvinced we want to do this in
>> channel naming.
>> Perhaps we want an additional attribute giving access to this sort of
>> 'semantic' information?
>
> I'm not convinced about it either. My gut feeling is that this is not the right
> approach, but I don't really have any better ideas at the moment.
>
> Xander can you give a short description of how this information will be used by
> an application? Would having a label property for the channel also work for you
> (e.g. in_voltage0_label)?
>
> - Lars
>
We use 10 of the optional aux channels available in the XADC and have them wired
up to specific power supplies. For example, channel 9 is connected to the
current of a 6V power supply and channel 12 is connected to the voltage of that
same supply, channel 4 is connected to the current of a 3.3V power supply and
channel 5 is connected to its voltage.
Without adding extended names to distinguish these aux channels, the handles
available inside /sys/bus/iio/devices/[device] are generic: in_voltage10_raw,
in_voltage10_scale, for example. If I added the label 'user5v_v', then these
handles would be in_voltage10_user5v_v_raw and in_voltage10_user5v_v_scale. This
makes it a lot easier to get started and let the handles describe themselves,
rather than having to look up which channels are connected to which things.
As far as using 'label' instead of 'extend-name', that's fine with me. I've
already sent out a v2 using 'label' instead.
--
Xander Huff
Staff Software Engineer
National Instruments
next prev parent reply other threads:[~2015-05-26 19:05 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 22:44 [PATCH 1/2] devicetree: xilinx-xadc: Add optional xlnx,extend-name property Xander Huff
2015-05-07 22:44 ` Xander Huff
2015-05-07 22:44 ` [PATCH 1/2] devicetree: xilinx-xadc: Add optional xlnx, extend-name property Xander Huff
2015-05-07 22:44 ` [PATCH 2/2] iio: adc: xilinx-xadc: Add xlnx,extend-name as an optional argument for aux channels Xander Huff
2015-05-07 22:44 ` Xander Huff
2015-05-07 22:44 ` [PATCH 2/2] iio: adc: xilinx-xadc: Add xlnx, extend-name " Xander Huff
2015-05-19 17:53 ` [PATCH 2/2] iio: adc: xilinx-xadc: Add xlnx,extend-name " Lars-Peter Clausen
2015-05-19 17:53 ` Lars-Peter Clausen
2015-05-19 17:53 ` Lars-Peter Clausen
2015-05-20 15:22 ` [PATCH v2 1/2] devicetree: xilinx-xadc: Add optional label property Xander Huff
2015-05-20 15:22 ` Xander Huff
2015-05-20 15:22 ` Xander Huff
2015-05-20 15:22 ` [PATCH v2 2/2] iio: adc: xilinx-xadc: Add label as an optional argument for aux channels Xander Huff
2015-05-20 15:22 ` Xander Huff
2015-05-20 15:22 ` Xander Huff
2015-06-07 16:49 ` Jonathan Cameron
2015-06-07 16:49 ` Jonathan Cameron
2015-06-07 16:49 ` Jonathan Cameron
2015-06-08 13:49 ` Josh Cartwright
2015-06-08 13:49 ` Josh Cartwright
2015-06-08 13:49 ` Josh Cartwright
2015-06-14 11:20 ` Jonathan Cameron
2015-06-14 11:20 ` Jonathan Cameron
2015-06-14 11:20 ` Jonathan Cameron
2015-05-23 11:23 ` [PATCH 2/2] iio: adc: xilinx-xadc: Add xlnx,extend-name " Jonathan Cameron
2015-05-23 11:23 ` Jonathan Cameron
2015-05-23 11:23 ` Jonathan Cameron
2015-05-26 9:38 ` Lars-Peter Clausen
2015-05-26 9:38 ` Lars-Peter Clausen
2015-05-26 9:38 ` Lars-Peter Clausen
2015-05-26 19:05 ` Xander Huff [this message]
2015-05-26 19:05 ` Xander Huff
2015-05-26 19:05 ` Xander Huff
2015-05-08 18:43 ` [PATCH 1/2] devicetree: xilinx-xadc: Add optional xlnx,extend-name property Jonathan Cameron
2015-05-08 18:43 ` Jonathan Cameron
2015-05-08 18:43 ` [PATCH 1/2] devicetree: xilinx-xadc: Add optional xlnx, extend-name property 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=5564C417.3010707@ni.com \
--to=xander.huff@ni.com \
--cc=ben.shelton@ni.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jic23@kernel.org \
--cc=joe.hershberger@ni.com \
--cc=joshc@ni.com \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=michal.simek@xilinx.com \
--cc=pawel.moll@arm.com \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
--cc=soren.brinkmann@xilinx.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.