[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8454842b-6fdf-4b4e-b424-d622301906a6@baylibre.com>
Date: Tue, 16 Sep 2025 13:25:04 -0500
From: David Lechner <dlechner@...libre.com>
To: Marilene Andrade Garcia <marilene.agarcia@...il.com>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Cc: Kim Seer Paller <kimseer.paller@...log.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Jonathan Cameron <jic23@...nel.org>, Nuno Sá
<nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Marcelo Schmitt <marcelo.schmitt1@...il.com>,
Marcelo Schmitt <Marcelo.Schmitt@...log.com>,
Ceclan Dumitru <dumitru.ceclan@...log.com>,
Jonathan Santos <Jonathan.Santos@...log.com>,
Dragos Bogdan <dragos.bogdan@...log.com>
Subject: Re: [PATCH v11 2/3] iio: adc: max14001: New driver
On 9/16/25 1:04 PM, David Lechner wrote:
> On 9/15/25 5:16 PM, Marilene Andrade Garcia wrote:
...
>> +static const struct iio_chan_spec max14001_channel[] = {
>> + {
>> + .type = IIO_VOLTAGE,
>> + .indexed = 1,
>> + .channel = 0,
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
>> + BIT(IIO_CHAN_INFO_AVERAGE_RAW) |
>
> I think there was some discussion about this last time [1] that it
> would actually make sense to have the average as a separate channel.
>
> There are a few reasons for this. If we add buffered read support
> later, we could only read the average in a buffered read if it is
> a separate channel. And the average channel should have an extra
> control that is either the -3 dB low pass filter point (using existing
> ABI) or the averaging window size (potentially new ABI).
>
> If we don't care about ever reading the filtered and not filtered
> value at the same time, we could just have a single channel and only
> ever read from the FADC register and ignore the ADC register.
>
> In either case, we would not need IIO_CHAN_INFO_AVERAGE_RAW.
>
> [1]: https://lore.kernel.org/linux-iio/20250903171105.00003dcd@huawei.com/
>
I thought about this some more while I was eating lunch and
I think I like the second option the best. We keep things simple
with just one channel for now. And if anyone ever does need to
read both filtered and unfiltered at the same time, we can add
it, but if that never happens, then we won't have wasted time
implementing it.
Powered by blists - more mailing lists