From: "Sricharan" <sricharan@codeaurora.org>
To: "'Phani A, Rama Krishna'" <rphani@codeaurora.org>,
linux-iio@vger.kernel.org, jic23@kernel.org
Cc: linux-arm-msm@vger.kernel.org, smohanad@codeaurora.org,
mgautam@codeaurora.org, 'Hartmut Knaack' <knaack.h@gmx.de>,
'Lars-Peter Clausen' <lars@metafoo.de>,
'Peter Meerwald-Stadler' <pmeerw@pmeerw.net>,
'Julia Lawall' <Julia.Lawall@lip6.fr>,
'open list' <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling
Date: Wed, 26 Oct 2016 15:47:17 +0530 [thread overview]
Message-ID: <001c01d22f72$25990c10$70cb2430$@codeaurora.org> (raw)
In-Reply-To: <241f4520-92da-5aff-7f4f-9487d6082906@codeaurora.org>
Hi Ramakrishna,
[snip..]
>>> + u32 i = 0;
>>> +
>>> + if (!pts)
>>> + return -EINVAL;
>>> +
>>> + /* Check if table is descending or ascending */
>>> + if (tablesize > 1) {
>>> + if (pts[0].x < pts[1].x)
>>> + descending = 0;
>>> + }
>>> +
>>> + while (i < tablesize) {
>>> + if ((descending == 1) && (pts[i].x < input)) {
>>
>> Just if (descending) instead of (descending == 1) and so on for the below as well
>
> Will change in next patch.
>
>>
>>> + /* table entry is less than measured*/
>>> + /* value and table is descending, stop */
>>> + break;
>>> + } else if ((descending == 0) &&
>>> + (pts[i].x > input)) {
>>> + /* table entry is greater than measured*/
>>> + /*value and table is ascending, stop */
>>> + break;
>>> + }
>>> + i++;
>>> + }
>>> +
>>> + if (i == 0) {
>>> + *output = pts[0].y;
>>> + } else if (i == tablesize) {
>>> + *output = pts[tablesize - 1].y;
>>> + } else {
>>> + /* result is between search_index and search_index-1 */
>>> + /* interpolate linearly */
>>> + *output = (((s32)((pts[i].y - pts[i - 1].y) *
>>> + (input - pts[i - 1].x)) /
>>> + (pts[i].x - pts[i - 1].x)) +
>>> + pts[i - 1].y);
>>> + }
>>
>> hmm, so for descending, input - pts[i -1].x is negative and
>> we are adding that to pts[i-1].y, is that correct ?
>
> The formula used is to interpolate between two points using linear
>interpolation.
Right, agree. my question can be ignored.
[snip..]
>>> #define VADC_CHAN_TEMP(_dname, _pre) \
>>> - VADC_CHAN(_dname, IIO_TEMP, BIT(IIO_CHAN_INFO_PROCESSED), _pre) \
>>> + VADC_CHAN(_dname, IIO_TEMP, \
>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED), \
>>> + _pre) \
>>>
>>> #define VADC_CHAN_VOLT(_dname, _pre) \
>>> - VADC_CHAN(_dname, IIO_VOLTAGE, \
>>> - BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE), \
>>> + VADC_CHAN(_dname, IIO_VOLTAGE, \
>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED),\
>>> _pre) \
>>>
>> For this and the below changes to VADC_CHAN_VOLT to TEMP, why is that done ?
>> Now both macros are setting the same flags.
>
> For Voltage channels IIO_VOLTAGE is needed where as for Temperature
>channels IIO_TEMP is needed.
>
>>
>>> /*
>>> @@ -637,12 +811,11 @@ struct vadc_channels {
>>> VADC_CHAN_TEMP(DIE_TEMP, 0)
>>> VADC_CHAN_VOLT(REF_625MV, 0)
>>> VADC_CHAN_VOLT(REF_1250MV, 0)
>>> - VADC_CHAN_VOLT(CHG_TEMP, 0)
>>> + VADC_CHAN_TEMP(CHG_TEMP, 0)
>>> VADC_CHAN_VOLT(SPARE1, 0)
>>> VADC_CHAN_VOLT(SPARE2, 0)
>>> VADC_CHAN_VOLT(GND_REF, 0)
>>> VADC_CHAN_VOLT(VDD_VADC, 0)
>>> -
And also looks like the deletion of these and below
new lines are unnecessary ?
Regards,
Sricharan
next prev parent reply other threads:[~2016-10-26 10:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 5:27 [PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling Rama Krishna Phani A
2016-10-25 13:09 ` Sricharan
2016-10-26 9:27 ` Phani A, Rama Krishna
2016-10-26 10:17 ` Sricharan [this message]
2016-10-26 10:45 ` Phani A, Rama Krishna
2016-11-02 7:25 ` 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='001c01d22f72$25990c10$70cb2430$@codeaurora.org' \
--to=sricharan@codeaurora.org \
--cc=Julia.Lawall@lip6.fr \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgautam@codeaurora.org \
--cc=pmeerw@pmeerw.net \
--cc=rphani@codeaurora.org \
--cc=smohanad@codeaurora.org \
/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).