[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c6fb37b0-e904-4fbc-8666-9eb747861af9@baylibre.com>
Date: Sat, 16 Aug 2025 12:22:13 -0500
From: David Lechner <dlechner@...libre.com>
To: Ben Collins <bcollins@...ter.com>, Jonathan Cameron <jic23@...nel.org>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] iio: mcp9600: Add support for IIR filter
On 8/15/25 11:46 AM, Ben Collins wrote:
> MCP9600 supports an IIR filter with 7 levels. Add IIR attribute
> to allow get/set of this value.
>
> Signed-off-by: Ben Collins <bcollins@...ter.com>
> ---
...
> static int mcp9600_read(struct mcp9600_data *data,
> @@ -191,13 +200,36 @@ static int mcp9600_read_raw(struct iio_dev *indio_dev,
> if (ret)
> return ret;
> return IIO_VAL_INT;
> +
> case IIO_CHAN_INFO_SCALE:
> *val = 62;
> *val2 = 500000;
> return IIO_VAL_INT_PLUS_MICRO;
> +
> case IIO_CHAN_INFO_THERMOCOUPLE_TYPE:
> *val = mcp9600_tc_types[data->thermocouple_type];
> return IIO_VAL_CHAR;
> +
> + case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
> + *val = mcp_iir_coefficients_avail[data->filter_level];
We already calculated the correct values, so we should be using
those instead of made-up values.
And the suggestion of using filter_type takes care of the
turning the filter off so we don't need an "infinity" value
here.
That does bring up the question though, if the filter is off,
should this attribute return an error in that case?
> + return IIO_VAL_INT;
> +
> + default:
> + return -EINVAL;
> + }
> +}
Powered by blists - more mailing lists