All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Thomas.Betker@rohde-schwarz.com
Cc: "Lars-Peter Clausen" <lars@metafoo.de>,
	linux-iio@vger.kernel.org,
	"Michal Simek" <michal.simek@xilinx.com>,
	"Sören Brinkmann" <soren.brinkmann@xilinx.com>
Subject: Re: [Patch 0/5] iio: adc: xilinx: Fix some minor issues
Date: Sat, 18 Apr 2015 20:26:30 +0100	[thread overview]
Message-ID: <5532AFE6.5080407@kernel.org> (raw)
In-Reply-To: <OF5342D15E.A4BDD05D-ONC1257E29.00294BA0-C1257E29.002B4FCC@rohde-schwarz.com>

On 16/04/15 08:53, Thomas.Betker@rohde-schwarz.com wrote:
> Hello Jonathan:
> 
>>> About [5]: This may be a matter of debate on the IIO list, but I 
> didn't 
>>> get the impression that extensions are intended to be used that way.
>>>     .extend_name = "vccint" means that the sysfs node names are 
>>> in_voltage0_vccint_raw/_scale, which is a bit unexpected. I would 
>>> rather see them called just in_voltage0_*, and reserve extensions for 
>>> things like in_voltage0_lowest_* and in_voltage0_highest_* 
> (MIN_VCCINT, 
>>> MAX_VCCINT) -- that's what we do in our project.
>>
>> It was always intended for labelling of channels with well defined
>> purposes.  That is ones that are hard wired to something rather than
>> simply exposed for general purpose use.  I'm guessing vccint is
>> the internal supply voltage, in which case that was pretty much
>> the intended use.
>>
>> The datasheet name is only really there for binding consumers to 
> individual
>> channels.  The thought being that you'd probably be sat there with a 
> circuit
>> diagram in front of you specifying what is connected to which precise 
> pin
>> of the ADC...
>>
>> So I think the original approach is more in keeping with the intent.
> 
> Okay, got it. It means that our application needs to remember that it's 
> sometimes voltage%d_%s instead of just voltage%d, but we can do that.
> 
>> The lowest/highest versions are interesting. Right now, the extended 
> name
>> is the only way to specify them, but somehow it feels like we ought
>> to have something better.... We could treat them as a filter or simply
>> another aspect of the channel (like _scale etc), but that's also a 
> little
>> ugly. Will think about this and see if anyone else has a better 
> suggestion!
> 
> With hwmon, we would have inX_input, inX_lowest, inX_highest (in fact, we 
> had, as Xilinx XADC used to be hwmon -- just to explain where I'm coming 
> from). So it made sense to me to use .extended_name = "lowest" to have 
> in_voltageX_lowest_raw/_scale in addition to in_voltageX_raw/_scale (same 
> index X). I understand that I may have read too much into the IIO code 
> here, though, and if there's a better way to do this, I will gladly use 
> it.
Hmm, we could as new info_mask elements (like _raw, _scale etc).
The nasty corner case is that we might also read them as part of a buffer
read.  To do that they will need to be separate 'channels' in their own
right. 

I'm not entirely sure right now if you can distinguish channels purely on
the basis of extended name (and different scan index values), but that
might work, though would be a bit ugly.  There is certainly no fundamental
reason you can't do this..

Hmm. Lars, any thoughts?


> 
> Best regards,
> Thomas Betker
> 


  reply	other threads:[~2015-04-18 19:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15 19:11 [Patch 0/5] iio: adc: xilinx: Fix some minor issues Thomas Betker
2015-04-15 19:11 ` [PATCH 1/5] iio: adc: xilinx: Fix register addresses Thomas Betker
2015-04-19 12:48   ` Jonathan Cameron
2015-04-15 19:11 ` [PATCH 2/5] iio: adc: xilinx: Fix "vccaux" channel .address Thomas Betker
2015-04-19 12:51   ` Jonathan Cameron
2015-04-15 19:11 ` [PATCH 3/5] iio: adc: xilinx: Fix VREFP scale Thomas Betker
2015-04-19 12:51   ` Jonathan Cameron
2015-06-26 21:55   ` Hartmut Knaack
2015-06-30 10:56     ` Thomas.Betker
2015-07-01 18:30       ` Hartmut Knaack
2015-07-03  7:52         ` Thomas.Betker
2015-04-15 19:11 ` [PATCH 4/5] iio: adc: xilinx: Fix VREFN sign Thomas Betker
2015-04-19 12:52   ` Jonathan Cameron
2015-04-15 19:11 ` [PATCH 5/5] iio: adc: xilinx: Set .datasheet_name instead of .extend_name Thomas Betker
2015-04-15 20:54 ` [Patch 0/5] iio: adc: xilinx: Fix some minor issues Jonathan Cameron
2015-04-16  6:20   ` Lars-Peter Clausen
2015-04-16  8:03     ` Thomas.Betker
2015-04-16  7:53   ` Thomas.Betker
2015-04-18 19:26     ` Jonathan Cameron [this message]
2015-04-20  8:34       ` Thomas.Betker
2015-04-21 19:35         ` 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=5532AFE6.5080407@kernel.org \
    --to=jic23@kernel.org \
    --cc=Thomas.Betker@rohde-schwarz.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --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.