linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michael.Hennerich@analog.com, jic23@kernel.org, knaack.h@gmx.de,
	pmeerw@pmeerw.net, gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale
Date: Mon, 14 Nov 2016 11:25:22 +0100	[thread overview]
Message-ID: <42b352e0-ea7a-677f-f683-ab370ad47dd5@metafoo.de> (raw)
In-Reply-To: <20161112142245.GA2214@Socrates-DK>

On 11/12/2016 03:22 PM, Eva Rachel Retuya wrote:
> Hello, 
> 
> Thanks for explaining it. Now I understand better why read_raw is
> formatted in that manner. I have some questions in-line:
> 
> On Fri, Nov 11, 2016 at 03:18:37PM +0100, Lars-Peter Clausen wrote:
>> On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote:
>>> Eliminate the non-standard attribute in_voltage_range and move its
>>> functionality under the scale attribute. read_raw() has been taken care
>>> of previously so only write_raw() is handled here.
>>>
>>> Additionally, rename the attribute in_voltage_range_available into
>>> in_voltage_scale_available.
>>>
>>> Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
>>> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
>>
>> Hi,
>>
>> Thanks for the patch. Unfortunately this is not quite this straight forward.
>>
>> The scale is what you multiply the raw with to get the value in the standard
>> IIO unit. Range as implemented in this driver is the maximum output voltage.
>>
>> To get the scale we need to look at the transfer function of the ADC [1].
>> The transfer function tells us that 1 LSB is 305uV for the 10V range and
>> 152uV for the 5V range.
> 
> Instead of 10000 and 5000, these will be the values for the
> scale_available attribute?

Yes. But these are slightly truncated values, we should try to minimize the
rounding error introduced by those scales by making them as accurate as
possible. The exact values are 5/2**16 and 2.5/2**16. Neither of which we
can express accurately. But we should use at least 6 digits and also round
to the closest rather than truncating.

> 
>>
>> More specifically this is $RANGE*2/2**16 (times two since the ADC is bipolar).
>>
>> Since the default unit for IIO is mV for voltages we need to multiply this
>> by 1000.
>>
>> The other thing we need to handle is the case where the RANGE pin is not
>> connected to a GPIO but either hardwired to 1 or 0. Which we need to handle
>> somehow.
> 
> Will this be on the same patch or a separate one? Can you please give a
> hint on how to check if it is hardwired?

The current driver checks if the GPIO is set and if it is not it does not
register the range attribute. As a first step we could mimic this behavior,
but long term we should find a way to discover the setting of the hardwired
pin and report the scale accordingly.

  reply	other threads:[~2016-11-14 10:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11  6:34 [PATCH 0/2] staging: iio: ad7606: move driver out of staging Eva Rachel Retuya
2016-11-11  6:34 ` [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale Eva Rachel Retuya
2016-11-11 14:18   ` Lars-Peter Clausen
2016-11-12 14:22     ` Eva Rachel Retuya
2016-11-14 10:25       ` Lars-Peter Clausen [this message]
2016-11-12 14:24     ` Jonathan Cameron
2016-11-14 10:30       ` Lars-Peter Clausen
2016-11-14 17:26         ` Jonathan Cameron
2016-11-14 16:58       ` Linus Walleij
2016-11-14 18:53         ` Lars-Peter Clausen
2016-11-14 22:15           ` Jonathan Cameron
2016-11-14 23:12           ` Linus Walleij
2016-11-19 12:32             ` Jonathan Cameron
2016-11-11  6:34 ` [PATCH 2/2] staging: iio: ad7606: move out of staging Eva Rachel Retuya
2016-11-11 14:22   ` Lars-Peter Clausen
2016-11-12 14:26     ` Jonathan Cameron
2016-11-12 14:32       ` Eva Rachel Retuya
2016-11-12 14:42         ` Jonathan Cameron
2016-11-11 16:10   ` kbuild test robot

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=42b352e0-ea7a-677f-f683-ab370ad47dd5@metafoo.de \
    --to=lars@metafoo.de \
    --cc=Michael.Hennerich@analog.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.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;
as well as URLs for NNTP newsgroup(s).