Re: [PATCH v4 7/8] iio: imu: adis16607: Add external clock sync support

[Nuno Sá]

On Fri, 23 Oct 2026 12:30:24 +0300, Radu Sabau <radu.sabau@xxxxxxxxxx> wrote:
> diff --git a/drivers/iio/imu/adis16607.c b/drivers/iio/imu/adis16607.c
> index b1f3667d8ce3..3c5b59820be1 100644
> --- a/drivers/iio/imu/adis16607.c
> +++ b/drivers/iio/imu/adis16607.c
> @@ -1063,17 +1091,96 @@ static const struct adis16607_chip_info adis16607_3_chip_info = {
> [ ... skip 24 lines ... ]
> +	clk = devm_clk_get_optional_enabled(dev, NULL);
> +	if (IS_ERR(clk))
> +		return PTR_ERR(clk);
> +
> +	if (clk) {
> +		ext_clk_hz = clk_get_rate(clk);

The notifier might just be a lot of complication for something that I
dunno we'll hit in practice. So, I would very much request exlusive rate
for the clock if we want to care about this and deal with something more
complex if we ever need.

FWIW, I guess you need to handle things on PRE_RATE_CHANGE. For
example, if buffering is enabled we should deny the request!

> [ ... skip 47 lines ... ]
> +		 * sync_scale is a rounded integer, so the hardware's actual
> +		 * effective rate is ext_clk_hz * sync_scale, not necessarily
> +		 * int_clk_hz - use the real value here so sample_period_ns (and
> +		 * therefore FIFO sample timestamps) don't drift from it.
> +		 */
> +		st->clk_freq_mhz = (unsigned long)ext_clk_hz * sync_scale * 1000;

On other devices, we actually control the scale when adjusting ODR. Here
it looks like we keep it constant. Any reason for that? It does not give
so much flexibility. See:

https://elixir.bootlin.com/linux/v7.3/source/drivers/iio/imu/adis16475.c#L336

-- 
Nuno Sá <nuno.sa@xxxxxxxxxx>