All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org>
Cc: nuno.sa@analog.com, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org,
	Dragos Bogdan <dragos.bogdan@analog.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Olivier Moysan <olivier.moysan@foss.st.com>
Subject: Re: [PATCH 08/10] iio: backend: add new functionality
Date: Thu, 28 Mar 2024 15:16:32 +0000	[thread overview]
Message-ID: <20240328151632.298bd95f@jic23-huawei> (raw)
In-Reply-To: <20240328-iio-backend-axi-dac-v1-8-afc808b3fde3@analog.com>

On Thu, 28 Mar 2024 14:22:32 +0100
Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org> wrote:

> From: Nuno Sa <nuno.sa@analog.com>
> 
> This adds the needed backend ops for supporting a backend inerfacing
> with an high speed dac. The new ops are:
> 
> * data_source_set();
> * set_sampling_freq();
> * extend_chan_spec();
> * ext_info_set();
> * ext_info_get().
> 
> Also to note the new helpers that are meant to be used by the backends
> when extending an IIO channel (adding extended info):
> 
> * iio_backend_ext_info_set();
> * iio_backend_ext_info_get().
> 
> Signed-off-by: Nuno Sa <nuno.sa@analog.com>
I'm pretty flexible on this so far as I think we are still learning how front
ends and backends should interact. Maybe we'll figure that out in the medium
term and rework this stuff. For now it looks fine. A few minor things inline.
>  
> +/**
> + * iio_backend_ext_info_get - IIO ext_info read callback
> + * @indio_dev:	IIO device
> + * @private:	Data private to the driver
> + * @chan:	IIO channel
> + * @buf:	Buffer where to place the attribute data
> + *
> + * This helper is intended to be used by backends that extend an IIO channel
> + * (trough iio_backend_extend_chan_spec()) with extended info. In that case,
> + * backends are not supposed to give their own callbacks (as they would not
> + * a way to get te backend from indio_dev). This is the getter.

te->the?


> +/**
> + * iio_backend_extend_chan_spec - Extend an IIO channel
> + * @indio_dev:	IIO device
> + * @back:	Backend device
> + * @chan:	IIO channel
> + *
> + * Some backends may have their own functionalities and hence capable of
> + * extending a frontend's channel.
> + *
> + * RETURNS:
> + * 0 on success, negative error number on failure.
> + */
> +int iio_backend_extend_chan_spec(struct iio_dev *indio_dev,
> +				 struct iio_backend *back,
> +				 struct iio_chan_spec *chan)
> +{
> +	const struct iio_chan_spec_ext_info *ext_info = chan->ext_info;
This is getting confusing.  So this one is the front end value of ext_info?
Name it as such frontend_ext_info

> +	int ret;
> +
> +	ret = iio_backend_op_call(back, extend_chan_spec, chan);
> +	if (ret)
> +		return ret;
> +	/*
> +	 * Let's keep things simple for now. Don't allow to overwrite the
> +	 * frontend's extended info. If ever needed, we can support appending
> +	 * it.
> +	 */
> +	if (ext_info && chan->ext_info != ext_info)
> +		return -EOPNOTSUPP;
> +	if (!chan->ext_info)

This is checking if the backend added anything? Perhaps a comment on that
as we don't need a backend_ext_info local variable...

> +		return 0;
> +	/*
> +	 * !\NOTE: this will break as soon as we have multiple backends on one
> +	 * frontend and all of them extend channels. In that case, the core
> +	 * backend code has no way to get the correct backend given the
> +	 * iio device.
> +	 *
> +	 * One solution for this could be introducing a new backend
> +	 * dedicated callback in struct iio_info so we can callback into the
> +	 * frontend so it can give us the right backend given a chan_spec.
> +	 */

Hmm. This is indeed messy.  Could we associate it with the buffer as presuably
a front end with multiple backends is using multiple IIO buffers?

As you say a dance via the front end would work fine.


> +	iio_device_set_drvdata(indio_dev, back);
> +
> +	/* Don't allow backends to get creative and force their own handlers */
> +	for (ext_info = chan->ext_info; ext_info->name; ext_info++) {
> +		if (ext_info->read != iio_backend_ext_info_get)
> +			return -EINVAL;
> +		if (ext_info->write != iio_backend_ext_info_set)
> +			return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_NS_GPL(iio_backend_extend_chan_spec, IIO_BACKEND);

> diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
> index a6d79381866e..09ff2f8f9fd8 100644
> --- a/include/linux/iio/backend.h
> +++ b/include/linux/iio/backend.h
> @@ -4,6 +4,7 @@
>  
>  #include <linux/types.h>
>  
> +struct iio_chan_spec;
>  struct fwnode_handle;
>  struct iio_backend;
>  struct device;
> @@ -15,6 +16,26 @@ enum iio_backend_data_type {
>  	IIO_BACKEND_DATA_TYPE_MAX
>  };
>  
> +enum iio_backend_data_source {
> +	IIO_BACKEND_INTERNAL_CW,

CW?  Either expand out what ever that is in definition of add a comment
at least.

> +	IIO_BACKEND_EXTERNAL,
What does external mean in this case?
> +	IIO_BACKEND_DATA_SOURCE_MAX
> +};
> +
> +/**
> + * IIO_BACKEND_EX_INFO - Helper for an IIO extended channel attribute
> + * @_name:	Attribute name
> + * @_shared:	Whether the attribute is shared between all channels
> + * @_what:	Data private to the driver
> + */
> +#define IIO_BACKEND_EX_INFO(_name, _shared, _what) {	\
> +	.name = (_name),				\
> +	.shared = (_shared),				\
> +	.read =  iio_backend_ext_info_get,		\
> +	.write = iio_backend_ext_info_set,		\
> +	.private = (_what),				\
> +}
> +
>  /**
>   * struct iio_backend_data_fmt - Backend data format
>   * @type:		Data type.
> @@ -35,8 +56,13 @@ struct iio_backend_data_fmt {
>   * @chan_enable:	Enable one channel.
>   * @chan_disable:	Disable one channel.
>   * @data_format_set:	Configure the data format for a specific channel.
> + * @data_source_set:	Configure the data source for a specific channel.
> + * @set_sample_rate:	Configure the sampling rate for a specific channel.
>   * @request_buffer:	Request an IIO buffer.
>   * @free_buffer:	Free an IIO buffer.
> + * @extend_chan_spec:	Extend an IIO channel.
> + * @ext_info_set:	Extended info setter.
> + * @ext_info_get:	Extended info getter.
>   **/
>  struct iio_backend_ops {
>  	int (*enable)(struct iio_backend *back);
> @@ -45,10 +71,21 @@ struct iio_backend_ops {
>  	int (*chan_disable)(struct iio_backend *back, unsigned int chan);
>  	int (*data_format_set)(struct iio_backend *back, unsigned int chan,
>  			       const struct iio_backend_data_fmt *data);
> +	int (*data_source_set)(struct iio_backend *back, unsigned int chan,
> +			       enum iio_backend_data_source data);
> +	int (*set_sample_rate)(struct iio_backend *back, unsigned int chan,
> +			       u64 sample_rate);

Name the parameter that so we know the units.  _hz?  


  reply	other threads:[~2024-03-28 15:16 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 13:22 [PATCH 00/10] iio: dac: support IIO backends on the output direction Nuno Sa
2024-03-28 13:22 ` Nuno Sa via B4 Relay
2024-03-28 13:22 ` [PATCH 01/10] iio: buffer: add helper for setting direction Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 14:36   ` Jonathan Cameron
2024-03-28 15:18     ` Nuno Sá
2024-03-28 15:54       ` Jonathan Cameron
2024-03-28 13:22 ` [PATCH 02/10] iio: buffer-dma: Rename iio_dma_buffer_data_available() Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 13:22 ` [PATCH 03/10] iio: buffer-dma: Enable buffer write support Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 13:22 ` [PATCH 04/10] iio: buffer-dmaengine: Support specifying buffer direction Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 13:22 ` [PATCH 05/10] iio: buffer-dmaengine: Enable write support Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 13:22 ` [PATCH 06/10] dt-bindings: iio: dac: add bindings doc for AXI DAC driver Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-29 18:46   ` David Lechner
2024-04-02  7:51     ` Nuno Sá
2024-04-01 13:59   ` Rob Herring
2024-04-04 10:03     ` Nuno Sá
2024-03-28 13:22 ` [PATCH 07/10] dt-bindings: iio: dac: add bindings doc for AD9739A Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-29 19:06   ` David Lechner
2024-03-30 18:27     ` Krzysztof Kozlowski
2024-04-02  7:49       ` Nuno Sá
2024-04-02  7:50     ` Nuno Sá
2024-04-01 14:02   ` Rob Herring
2024-03-28 13:22 ` [PATCH 08/10] iio: backend: add new functionality Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 15:16   ` Jonathan Cameron [this message]
2024-03-28 15:42     ` Nuno Sá
2024-03-28 15:59       ` Jonathan Cameron
2024-03-28 16:54         ` Nuno Sá
2024-03-28 13:22 ` [PATCH 09/10] iio: dac: add support for AXI DAC IP core Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 15:35   ` Jonathan Cameron
2024-03-28 16:43     ` Nuno Sá
2024-03-28 13:22 ` [PATCH 10/10] iio: dac: support the ad9739a RF DAC Nuno Sa
2024-03-28 13:22   ` Nuno Sa via B4 Relay
2024-03-28 15:51   ` Jonathan Cameron
2024-03-28 16:37     ` Nuno Sá
2024-03-28 16:52       ` Jonathan Cameron

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=20240328151632.298bd95f@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=devnull+nuno.sa.analog.com@kernel.org \
    --cc=dragos.bogdan@analog.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@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.