All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Lechner <dlechner@baylibre.com>
To: "Angelo Dureghello" <adureghello@baylibre.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Olivier Moysan" <olivier.moysan@foss.st.com>
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 8/9] iio: dac: ad3552r: add axi platform driver
Date: Thu, 5 Sep 2024 15:40:11 -0500	[thread overview]
Message-ID: <b289a789-0440-4c1f-9f75-6d7e8e04189d@baylibre.com> (raw)
In-Reply-To: <20240905-wip-bl-ad3552r-axi-v0-iio-testing-v2-8-87d669674c00@baylibre.com>

On 9/5/24 10:17 AM, Angelo Dureghello wrote:

...

> +
> +static int ad3552r_axi_read_raw(struct iio_dev *indio_dev,
> +				struct iio_chan_spec const *chan,
> +				int *val, int *val2, long mask)
> +{
> +	struct ad3552r_axi_state *st = iio_priv(indio_dev);
> +	int err, ch = chan->channel;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_SAMP_FREQ: {
> +		int clk_rate;
> +
> +		err = iio_backend_read_raw(st->back, chan, &clk_rate, 0,
> +					   IIO_CHAN_INFO_FREQUENCY);

This seems odd to me. How does the backend know what frequency we want?
It would make more sense to me if this somehow indicated that we were
getting the SPI SCLK rate.

> +		if (err != IIO_VAL_INT)

Would be better to call the variable ret instead of err if it can hold
something besides an error code.

> +			return err;
> +
> +		/*
> +		 * Data stream SDR/DDR (clk_in/8 or clk_in/4 update rate).
> +		 * Samplerate has sense in DDR only.

We should also mention that this assumes QSPI in addtion to DDR enabled.

> +		 */
> +		if (st->single_channel)
> +			clk_rate = DIV_ROUND_CLOSEST(clk_rate, 4);
> +		else
> +			clk_rate = DIV_ROUND_CLOSEST(clk_rate, 8);
> +

Having the sample rate depend on how many channels are enabled in
the buffer seems a bit odd. Sampling frequency is not strictly
defined in IIO, so I think it would be fine to always return the
same value no matter how many channels are enabled.

We will just need to document that the sampling frequency is the
rate per sample, not per channel. So if two channels are enabled,
the effective sampling rate per channel is 1/2 of the sampling
rate reported by the sysfs attribute. 

> +		*val = clk_rate;
> +
> +		return IIO_VAL_INT;
> +	}
> +	case IIO_CHAN_INFO_RAW:

Do we need iio_device_claim_direct_scoped() here to prevent attempting
to do register access while a buffered write is in progress?

> +		err = iio_backend_bus_reg_read(st->back,
> +					       AD3552R_REG_ADDR_CH_DAC_16B(ch),
> +					       val, 2);
> +		if (err)
> +			return err;
> +
> +		return IIO_VAL_INT;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int ad3552r_axi_write_raw(struct iio_dev *indio_dev,
> +				 struct iio_chan_spec const *chan,
> +				 int val, int val2, long mask)
> +{
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		iio_device_claim_direct_scoped(return -EBUSY, indio_dev) {
> +			struct ad3552r_axi_state *st = iio_priv(indio_dev);
> +			int ch = chan->channel;
> +
> +			return iio_backend_bus_reg_write(st->back,
> +				    AD3552R_REG_ADDR_CH_DAC_16B(ch), val, 2);
> +		}
> +		unreachable();
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int ad3552r_axi_buffer_postenable(struct iio_dev *indio_dev)
> +{
> +	struct ad3552r_axi_state *st = iio_priv(indio_dev);
> +	struct iio_backend_data_fmt fmt = {
> +		.type = IIO_BACKEND_DATA_UNSIGNED
> +	};
> +	int loop_len, val, err;
> +
> +	/* Inform DAC chip to switch into DDR mode */
> +	err = axi3552r_qspi_update_reg_bits(st->back,
> +					    AD3552R_REG_ADDR_INTERFACE_CONFIG_D,
> +					    AD3552R_MASK_SPI_CONFIG_DDR,
> +					    AD3552R_MASK_SPI_CONFIG_DDR, 1);
> +	if (err)
> +		return err;
> +
> +	/* Inform DAC IP to go for DDR mode from now on */
> +	err = iio_backend_ddr_enable(st->back);
> +	if (err)
> +		goto exit_err;

Might want a comment or dev_warn() here. If we put the DAC in DDR
mode but can't put the backend in DDR mode, then things are probably
going to be a bit broken if we can't get the DAC back out of DDR
mode. Not likely to ever get an error here, but it will be helpful
to let readers of the code know why the unwinding isn't exactly
balanced.

> +> +	switch (*indio_dev->active_scan_mask) {
> +	case AD3552R_CH0_ACTIVE:
> +		st->single_channel = true;
> +		loop_len = AD3552R_STREAM_2BYTE_LOOP;
> +		val = AD3552R_REG_ADDR_CH_DAC_16B(0);
> +		break;
> +	case AD3552R_CH1_ACTIVE:
> +		st->single_channel = true;
> +		loop_len = AD3552R_STREAM_2BYTE_LOOP;
> +		val = AD3552R_REG_ADDR_CH_DAC_16B(1);
> +		break;
> +	case AD3552R_CH0_CH1_ACTIVE:
> +		st->single_channel = false;
> +		loop_len = AD3552R_STREAM_4BYTE_LOOP;
> +		val = AD3552R_REG_ADDR_CH_DAC_16B(1);
> +		break;
> +	default:
> +		return -EINVAL;

Move the switch statement before changing to DDR mode or
goto exit_err here.

> +	}
> +
> +	err = iio_backend_bus_reg_write(st->back, AD3552R_REG_ADDR_STREAM_MODE,
> +					loop_len, 1);
> +	if (err)
> +		goto exit_err;
> +
> +	err = iio_backend_data_transfer_addr(st->back, val);
> +	if (err)
> +		goto exit_err;
> +
> +	/*
> +	 * The EXT_SYNC is mandatory in the CN0585 project where 2 instances
> +	 * of the IP are in the design and they need to generate the signals
> +	 * synchronized.
> +	 *
> +	 * Note: in first IP implementations CONFIG EXT_SYNC (RO) can be 0,
> +	 * but EXT_SYMC (ext synch ability) is enabled anyway.

EXT_SYNC

> +	 */
> +	if (st->synced_transfer == AD3552R_EXT_SYNC_ARM)
> +		err = iio_backend_ext_sync_enable(st->back);
> +	else
> +		err = iio_backend_ext_sync_disable(st->back);
> +	if (err)
> +		goto exit_err_sync;

		goto exit_err;

If enabling failed, no need to disable.

> +
> +	err = iio_backend_data_format_set(st->back, 0, &fmt);
> +	if (err)
> +		goto exit_err_sync;
> +
> +	err = iio_backend_buffer_enable(st->back);
> +	if (err)
> +		goto exit_err_sync;
> +
> +	return 0;
> +
> +exit_err_sync:
> +	iio_backend_ext_sync_disable(st->back);
> +
> +exit_err:
> +	axi3552r_qspi_update_reg_bits(st->back,
> +				      AD3552R_REG_ADDR_INTERFACE_CONFIG_D,
> +				      AD3552R_MASK_SPI_CONFIG_DDR,
> +				      0, 1);
> +
> +	iio_backend_ddr_disable(st->back);
> +
> +	return err;
> +}
> +
> +static int ad3552r_axi_buffer_predisable(struct iio_dev *indio_dev)
> +{
> +	struct ad3552r_axi_state *st = iio_priv(indio_dev);
> +	int err;
> +
> +	err = iio_backend_buffer_disable(st->back);
> +	if (err)
> +		return err;

Looks like iio_backend_ext_sync_disable(st->back); should be called here.

> +
> +	/* Inform DAC to set in SDR mode */
> +	err = axi3552r_qspi_update_reg_bits(st->back,
> +					    AD3552R_REG_ADDR_INTERFACE_CONFIG_D,
> +					    AD3552R_MASK_SPI_CONFIG_DDR,
> +					    0, 1);
> +	if (err)
> +		return err;
> +
> +	return iio_backend_ddr_disable(st->back);
> +}
> +

  reply	other threads:[~2024-09-05 20:40 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-05 15:17 [PATCH v2 0/9] iio: add support for the ad3552r AXI DAC IP Angelo Dureghello
2024-09-05 15:17 ` [PATCH v2 1/9] dt-bindings: iio: dac: ad3552r: add io-backend property Angelo Dureghello
2024-09-05 16:28   ` Rob Herring (Arm)
2024-09-05 19:51     ` David Lechner
2024-09-08 12:29   ` Jonathan Cameron
2024-09-09 11:39     ` Angelo Dureghello
2024-09-09 19:16       ` Jonathan Cameron
2024-09-09 12:46     ` Conor Dooley
2024-09-09 14:03       ` Nuno Sá
2024-09-09 16:06         ` Conor Dooley
2024-09-10  8:12           ` Nuno Sá
2024-09-09 17:19         ` David Lechner
2024-09-09 17:38           ` David Lechner
2024-09-10  8:16           ` Nuno Sá
2024-09-11  8:45             ` Angelo Dureghello
2024-09-11 19:28             ` Conor Dooley
2024-09-05 15:17 ` [PATCH v2 2/9] iio: backend: extend features Angelo Dureghello
2024-09-08 12:38   ` Jonathan Cameron
2024-09-09 11:58     ` Angelo Dureghello
2024-09-05 15:17 ` [PATCH v2 3/9] iio: backend adi-axi-dac: " Angelo Dureghello
2024-09-08 15:11   ` Jonathan Cameron
2024-09-08 15:40   ` Christophe JAILLET
2024-09-05 15:17 ` [PATCH v2 4/9] iio: backend adi-axi-dac: add registering of child fdt node Angelo Dureghello
2024-09-05 19:19   ` David Lechner
2024-09-06  5:42     ` Nuno Sá
2024-09-06 13:52       ` David Lechner
2024-09-06  7:08     ` Nuno Sá
2024-09-08 12:36       ` Jonathan Cameron
2024-09-09  7:53         ` Nuno Sá
2024-09-05 15:17 ` [PATCH v2 5/9] dt-bindings: iio: dac: add ad3552r axi-dac compatible Angelo Dureghello
2024-09-05 16:28   ` Rob Herring (Arm)
2024-09-05 21:08   ` David Lechner
2024-09-06  7:22   ` Krzysztof Kozlowski
2024-09-06  9:11     ` Angelo Dureghello
2024-09-06  9:37       ` Krzysztof Kozlowski
2024-09-06 11:53         ` Nuno Sá
2024-09-06 12:13           ` Krzysztof Kozlowski
2024-09-06 13:52             ` Nuno Sá
2024-09-06 14:04               ` David Lechner
2024-09-06 16:36                 ` Krzysztof Kozlowski
2024-09-06 16:42                   ` David Lechner
2024-09-06 16:44                     ` Krzysztof Kozlowski
2024-09-06 16:43               ` Krzysztof Kozlowski
2024-09-05 15:17 ` [PATCH v2 6/9] iio: dac: ad3552r: changes to use FIELD_PREP Angelo Dureghello
2024-09-05 20:59   ` David Lechner
2024-09-08 15:14   ` Jonathan Cameron
2024-09-08 15:15     ` Jonathan Cameron
2024-09-05 15:17 ` [PATCH v2 7/9] iio: dac: ad3552r: extract common code (no changes in behavior intended) Angelo Dureghello
2024-09-08 15:42   ` Jonathan Cameron
2024-09-08 15:53   ` Christophe JAILLET
2024-09-05 15:17 ` [PATCH v2 8/9] iio: dac: ad3552r: add axi platform driver Angelo Dureghello
2024-09-05 20:40   ` David Lechner [this message]
2024-09-08 15:49     ` Jonathan Cameron
2024-09-09  9:00     ` Nuno Sá
2024-09-08 16:07   ` Jonathan Cameron
2024-09-08 16:28   ` Christophe JAILLET
2024-09-09 13:35     ` Nuno Sá
2024-09-05 15:17 ` [PATCH v2 9/9] iio: ABI: add DAC sysfs synchronous_mode parameter Angelo Dureghello
2024-09-05 19:14   ` David Lechner
2024-09-08 12:26     ` Jonathan Cameron
2024-09-05 19:46 ` [PATCH v2 0/9] iio: add support for the ad3552r AXI DAC IP David Lechner
2024-09-06  9:07 ` Conor Dooley
2024-09-06  9:44   ` Angelo Dureghello

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=b289a789-0440-4c1f-9f75-6d7e8e04189d@baylibre.com \
    --to=dlechner@baylibre.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=adureghello@baylibre.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=olivier.moysan@foss.st.com \
    --cc=robh@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.