linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Olivier MOYSAN <olivier.moysan@foss.st.com>
To: "Nuno Sá" <noname.nuno@gmail.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: <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 8/8] iio: adc: stm32-dfsdm: add scaling support to dfsdm
Date: Thu, 20 Jun 2024 16:15:30 +0200	[thread overview]
Message-ID: <a76e16bc-bcb6-48eb-b6f7-2e4e68ded32b@foss.st.com> (raw)
In-Reply-To: <a0bd26a9e159e54f1b6effcdd45756ecfddf973f.camel@gmail.com>

Hi Nuno,

On 6/19/24 07:47, Nuno Sá wrote:
> On Tue, 2024-06-18 at 18:08 +0200, Olivier Moysan wrote:
>> Add scaling support to STM32 DFSDM.
>>
>> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
>> ---
> 
> Just some general comments...
> 
> Acked-by: Nuno Sa <nuno.sa@analog.com>
> 
>>   drivers/iio/adc/Kconfig           |  1 +
>>   drivers/iio/adc/stm32-dfsdm-adc.c | 94 ++++++++++++++++++++++++++++++-
>>   2 files changed, 92 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index f3dfdaa80678..858ae8161fa4 100644
>>
> 
> ...
> 
>> @@ -1301,6 +1339,8 @@ static int stm32_dfsdm_read_raw(struct iio_dev *indio_dev,
>>   		ret = stm32_dfsdm_single_conv(indio_dev, chan, val);
>>   		if (adc->hwc)
>>   			iio_hw_consumer_disable(adc->hwc);
>> +		if (adc->backend[idx])
>> +			iio_backend_disable(&indio_dev->dev, adc->backend[idx]);
>>   		if (ret < 0) {
>>   			dev_err(&indio_dev->dev,
>>   				"%s: Conversion failed (channel %d)\n",
>> @@ -1320,6 +1360,45 @@ static int stm32_dfsdm_read_raw(struct iio_dev *indio_dev,
>>   		*val = adc->sample_freq;
>>   
>>   		return IIO_VAL_INT;
>> +
>> +	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 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], val, val2, mask);
>> +
> 
> This is something that I've been thinking about since the beginning of backends
> support. Basically having the "catch all" read_raw()/write_raw() or more dedicated
> interfaces. For example, in your usecase I think it would make more sense to have
> dedicated API's like iio_backend_read_scale() and iio_backend_read_offset() as you're
> extending that functionality. Calling iio_backend_read_raw() seems a bit weird to me.
> 
> OTOH, iio_backend_read_raw() could be useful in cases where frontends call
> iio_backend_extend_chan_spec() and may get some functionality they are not aware of.
> And so, in the default: statement this "catch all" API could be used.
> 
> Anyways, this are really minor (likely pedantic) details and you kind of came first
> and made the decision for me. As I don't really have strong feelings about it, I'm
> fine with it as-is.
> 

My first idea was to stick to IIO read_raw API ('struct iio_chan_spec 
const *chan' should at least be added to prototype as you pointed it 
out). But I agree that iio_backend_read_raw() is not explicit regarding 
the requested info.
I consider using the existing API iio_backend_ext_info_get() for v2, as 
you suggested.

BRs
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], val, val2, mask);
>> +
>> +			*val = div_u64((u64)max * *val, BIT(*val2 - 1));
>> +			if (!chan->differential)
>> +				*val += max;
>> +		}
>> +		return IIO_VAL_INT;
>>   	}
>>   
>>   	return -EINVAL;
>> @@ -1449,7 +1528,15 @@ static int stm32_dfsdm_adc_chan_init_one(struct iio_dev
>> *indio_dev, struct iio_c
>>   	 * IIO_CHAN_INFO_RAW: used to compute regular conversion
>>   	 * IIO_CHAN_INFO_OVERSAMPLING_RATIO: used to set oversampling
>>   	 */
>> -	ch->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
>> +	if (child) {
>> +		ch->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
>> +					BIT(IIO_CHAN_INFO_SCALE) |
>> +					BIT(IIO_CHAN_INFO_OFFSET);
> 
> Not sure if the above SCALE and OFFSET are solely properties if the backend. If so,
> you could maybe use iio_backend_extend_chan_spec().
> 
> - Nuno Sá
> 

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

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18 16:08 [PATCH 0/8] iio: adc: dfsdm: add scaling support Olivier Moysan
2024-06-18 16:08 ` [PATCH 1/8] iio: add read raw service to iio backend framework Olivier Moysan
2024-06-19  5:25   ` Nuno Sá
2024-06-18 16:08 ` [PATCH 2/8] iio: add enable and disable services " Olivier Moysan
2024-06-19  5:21   ` Nuno Sá
2024-06-19 15:59     ` Olivier MOYSAN
2024-06-20 10:07       ` Nuno Sá
2024-06-23 13:56         ` Jonathan Cameron
2024-06-24  8:13           ` Nuno Sá
2024-06-18 16:08 ` [PATCH 3/8] iio: add child nodes support in " Olivier Moysan
2024-06-19  5:31   ` Nuno Sá
2024-06-19 16:00     ` Olivier MOYSAN
2024-06-23 13:59   ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 4/8] dt-bindings: iio: dfsdm: move to " Olivier Moysan
2024-06-18 18:10   ` Conor Dooley
2024-06-20  8:03     ` Olivier MOYSAN
2024-06-20  8:51       ` Conor Dooley
2024-06-23 15:01   ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 5/8] dt-bindings: iio: add sigma delta modulator backend Olivier Moysan
2024-06-18 18:13   ` Conor Dooley
2024-06-25  9:26     ` Olivier MOYSAN
2024-06-18 16:08 ` [PATCH 6/8] iio: adc: stm32-dfsdm: adopt generic channels bindings Olivier Moysan
2024-06-23 15:01   ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 7/8] iio: add sd modulator generic iio backend Olivier Moysan
2024-06-23 15:11   ` Jonathan Cameron
2024-06-24 12:43     ` Olivier MOYSAN
2024-06-24 15:22       ` Nuno Sá
2024-06-24 16:26         ` Olivier MOYSAN
2024-06-25 12:14           ` Nuno Sá
2024-06-24 17:41       ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 8/8] iio: adc: stm32-dfsdm: add scaling support to dfsdm Olivier Moysan
2024-06-19  5:47   ` Nuno Sá
2024-06-20 14:15     ` Olivier MOYSAN [this message]
2024-06-23 15:21   ` Jonathan Cameron
2024-06-25  9:39     ` Olivier MOYSAN

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=a76e16bc-bcb6-48eb-b6f7-2e4e68ded32b@foss.st.com \
    --to=olivier.moysan@foss.st.com \
    --cc=alexandre.torgue@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 \
    /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).