linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Olivier MOYSAN <olivier.moysan@foss.st.com>
To: "Nuno Sá" <noname.nuno@gmail.com>,
	fabrice.gasnier@foss.st.com,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>
Cc: Nuno Sa <nuno.sa@analog.com>, <linux-iio@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 8/8] iio: adc: stm32-dfsdm: add scaling support to dfsdm
Date: Wed, 26 Jun 2024 18:15:15 +0200	[thread overview]
Message-ID: <7125491f-880c-486e-b417-8fc1e0c20c88@foss.st.com> (raw)
In-Reply-To: <c2d746c73f7450dd10c0a0b229b3672e44fe583a.camel@gmail.com>

Hi Nuno,

On 6/26/24 10:59, Nuno Sá wrote:
> Hi Olivier,
> 
> One thing that I just noticed...
> 
> On Tue, 2024-06-25 at 17:07 +0200, Olivier Moysan wrote:
>> Add scaling support to STM32 DFSDM.
>>
>> When used in an analog context, a DFSDM filter typically converts the data
>> from a sigma delta modulator. The IIO device associated to the DFSDM
>> filter provides these data as raw data.
>> The IIO device can provide scaling information (voltage and offset) to
>> allow conversion of raw data into physical values.
>>
>> With the new binding based on IIO backend framework, the sigma delta
>> modulators are defined as backends providing scaling information.
>>
>> The scaling is not supported with legacy binding.
>>
>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>> Acked-by: Nuno Sa <nuno.sa@analog.com>
>> ---
>>
> 
> ...
> 
>> +
>> +	case IIO_CHAN_INFO_SCALE:
>> +		/*
>> +		 * Scale is expressed in mV.
>> +		 * When fast mode is disabled, actual resolution may be lower
>> +		 * than 2^n, where n = realbits - 1.
>> +		 * This leads to underestimating the input voltage.
>> +		 * To compensate this deviation, the voltage reference can be
>> +		 * corrected with a factor = realbits resolution / actual max
>> +		 */
>> +		if (adc->backend[idx]) {
>> +			iio_backend_read_raw(adc->backend[idx], chan, val,
>> val2, mask);
> 
> Eve if it does not matter for your usecase, you should still do error handling
> as iio_backend_read_raw() can return an error.
> 

Ack. On the same occasion, I will switch to a dedicated API.

Olivier

>> +			*val = div_u64((u64)*val * (u64)BIT(DFSDM_DATA_RES -
>> 1), max);
>> +			*val2 = chan->scan_type.realbits;
>> +			if (chan->differential)
>> +				*val *= 2;
>> +		}
>> +		return IIO_VAL_FRACTIONAL_LOG2;
>> +
>> +	case IIO_CHAN_INFO_OFFSET:
>> +		/*
>> +		 * DFSDM output data are in the range [-2^n, 2^n],
>> +		 * with n = realbits - 1.
>> +		 * - Differential modulator:
>> +		 * Offset correspond to SD modulator offset.
>> +		 * - Single ended modulator:
>> +		 * Input is in [0V, Vref] range,
>> +		 * where 0V corresponds to -2^n, and Vref to 2^n.
>> +		 * Add 2^n to offset. (i.e. middle of input range)
>> +		 * offset = offset(sd) * vref / res(sd) * max / vref.
>> +		 */
>> +		if (adc->backend[idx]) {
>> +			iio_backend_read_raw(adc->backend[idx], chan, val,
>> val2, mask);
> 
> Same...
> 
> - Nuno Sá


      reply	other threads:[~2024-06-26 16:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25 15:07 [PATCH v2 0/8] iio: adc: dfsdm: add scaling support Olivier Moysan
2024-06-25 15:07 ` [PATCH v2 4/8] dt-bindings: iio: dfsdm: move to backend framework Olivier Moysan
2024-06-28 21:35   ` Rob Herring
2024-07-03  8:28     ` Olivier MOYSAN
2024-06-25 15:07 ` [PATCH v2 6/8] iio: adc: stm32-dfsdm: adopt generic channels bindings Olivier Moysan
2024-06-29 19:03   ` Jonathan Cameron
2024-06-25 15:07 ` [PATCH v2 8/8] iio: adc: stm32-dfsdm: add scaling support to dfsdm Olivier Moysan
2024-06-26  8:59   ` Nuno Sá
2024-06-26 16:15     ` Olivier MOYSAN [this message]

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=7125491f-880c-486e-b417-8fc1e0c20c88@foss.st.com \
    --to=olivier.moysan@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=noname.nuno@gmail.com \
    --cc=nuno.sa@analog.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 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).