From: "Nuno Sá" <noname.nuno@gmail.com>
To: "Angelo Dureghello" <adureghello@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"Olivier Moysan" <olivier.moysan@foss.st.com>,
"Michael Hennerich" <Michael.Hennerich@analog.com>
Cc: linux-iio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/5] iio: dac: ad3552r-hs: add support for internal ramp
Date: Mon, 07 Apr 2025 17:21:43 +0100 [thread overview]
Message-ID: <b0f136eb616876018f2a952ee60d7376258e66fd.camel@gmail.com> (raw)
In-Reply-To: <20250407-wip-bl-ad3552r-fixes-v3-5-61874065b60f@baylibre.com>
On Mon, 2025-04-07 at 10:52 +0200, Angelo Dureghello wrote:
> From: Angelo Dureghello <adureghello@baylibre.com>
>
> The ad3552r can be feeded from the HDL controller by an internally
> generated 16bit ramp, useful for debug pourposes. Add debugfs a file
> to enable or disable it.
>
> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> ---
> drivers/iio/dac/ad3552r-hs.c | 124 ++++++++++++++++++++++++++++++++++++++++--
> -
> 1 file changed, 118 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/dac/ad3552r-hs.c b/drivers/iio/dac/ad3552r-hs.c
> index
> 37397e188f225a8099745ec03f7c604da76960b1..3dcbda23c732f5f5e655bde31c5dab496055
> 4bfc 100644
> --- a/drivers/iio/dac/ad3552r-hs.c
> +++ b/drivers/iio/dac/ad3552r-hs.c
> @@ -7,6 +7,7 @@
> */
>
> #include <linux/bitfield.h>
> +#include <linux/debugfs.h>
> #include <linux/delay.h>
> #include <linux/gpio/consumer.h>
> #include <linux/iio/backend.h>
> @@ -54,8 +55,13 @@ struct ad3552r_hs_state {
> struct ad3552r_hs_platform_data *data;
> /* INTERFACE_CONFIG_D register cache, in DDR we cannot read values.
> */
> u32 config_d;
> + /* Protects backend I/O operations from concurrent accesses. */
> + struct mutex lock;
> };
>
> +static const char dbgfs_src_iio_buffer[] = "iio-buffer";
> +static const char dbgfs_src_backend_ramp_gen[] = "backend-ramp-generator";
> +
Why not having both strings in one array? See below...
> static int ad3552r_hs_reg_read(struct ad3552r_hs_state *st, u32 reg, u32
> *val,
> size_t xfer_size)
> {
> @@ -65,6 +71,18 @@ static int ad3552r_hs_reg_read(struct ad3552r_hs_state *st,
> u32 reg, u32 *val,
> return st->data->bus_reg_read(st->back, reg, val, xfer_size);
> }
>
> +static int ad3552r_hs_set_data_source(struct ad3552r_hs_state *st,
> + enum iio_backend_data_source type)
> +{
> + int ret;
> +
> + ret = iio_backend_data_source_set(st->back, 0, type);
> + if (ret)
> + return ret;
> +
> + return iio_backend_data_source_set(st->back, 1, type);
Do we have some number of channels variable in some chip info? If so, I would
loop over that. If not, disregard the comment...
> +}
> +
> static int ad3552r_hs_update_reg_bits(struct ad3552r_hs_state *st, u32 reg,
> u32 mask, u32 val, size_t xfer_size)
> {
> @@ -483,6 +501,76 @@ static int ad3552r_hs_reg_access(struct iio_dev
> *indio_dev, unsigned int reg,
> return st->data->bus_reg_write(st->back, reg, writeval, 1);
> }
>
> +static ssize_t ad3552r_hs_show_data_source(struct file *f, char __user
> *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct ad3552r_hs_state *st = file_inode(f)->i_private;
> + enum iio_backend_data_source type;
> + int ret;
> +
> + guard(mutex)(&st->lock);
> +
> + ret = iio_backend_data_source_get(st->back, 0, &type);
> + if (ret)
> + return ret;
> +
> + switch (type) {
> + case IIO_BACKEND_INTERNAL_RAMP_16BIT:
> + return simple_read_from_buffer(userbuf, count, ppos,
> + dbgfs_src_backend_ramp_gen,
> + strlen(dbgfs_src_backend_ramp_gen));
> + case IIO_BACKEND_EXTERNAL:
> + return simple_read_from_buffer(userbuf, count, ppos,
> + dbgfs_src_iio_buffer, strlen(dbgfs_src_iio_buffer));
Even with only one array, you could easily handle things here...
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static ssize_t ad3552r_hs_write_data_source(struct file *f,
> + const char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct ad3552r_hs_state *st = file_inode(f)->i_private;
> + char buf[64];
> + int ret, len;
> +
> + guard(mutex)(&st->lock);
> +
> + ret = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, userbuf,
> + count);
> + if (ret < 0)
> + return ret;
> +
> + len = strlen(dbgfs_src_iio_buffer);
> + if (count == len && !strncmp(buf, dbgfs_src_iio_buffer, len)) {
> + ret = ad3552r_hs_set_data_source(st, IIO_BACKEND_EXTERNAL);
> + if (ret)
> + return ret;
> + goto exit_ok;
> + }
> +
> + len = strlen(dbgfs_src_backend_ramp_gen);
> + if (count == len && !strncmp(buf, dbgfs_src_backend_ramp_gen, len)) {
> + ret = ad3552r_hs_set_data_source(st,
> + IIO_BACKEND_INTERNAL_RAMP_16BIT);
> + if (ret)
> + return ret;
> + goto exit_ok;
> + }
But here is where it makes more sense... I would use match_string() and then get
the match index and translate that into the backend signal type.
Plus, I still think you could provide a 'data_source_available' attribute to
make the user interface more friendly.
- Nuno Sá
> +
> + return -EINVAL;
> +
> +exit_ok:
> + return count;
> +}
> +
> +static const struct file_operations ad3552r_hs_data_source_fops = {
> + .owner = THIS_MODULE,
> + .write = ad3552r_hs_write_data_source,
> + .read = ad3552r_hs_show_data_source,
> +};
> +
> static int ad3552r_hs_setup(struct ad3552r_hs_state *st)
> {
> u16 id;
> @@ -550,11 +638,7 @@ static int ad3552r_hs_setup(struct ad3552r_hs_state *st)
> if (ret)
> return ret;
>
> - ret = iio_backend_data_source_set(st->back, 0, IIO_BACKEND_EXTERNAL);
> - if (ret)
> - return ret;
> -
> - ret = iio_backend_data_source_set(st->back, 1, IIO_BACKEND_EXTERNAL);
> + ret = ad3552r_hs_set_data_source(st, IIO_BACKEND_EXTERNAL);
> if (ret)
> return ret;
>
> @@ -661,6 +745,24 @@ static const struct iio_info ad3552r_hs_info = {
> .debugfs_reg_access = &ad3552r_hs_reg_access,
> };
>
> +static void ad3552r_hs_debugfs_init(struct iio_dev *indio_dev)
> +{
> + struct ad3552r_hs_state *st = iio_priv(indio_dev);
> + struct dentry *d = iio_get_debugfs_dentry(indio_dev);
> +
> + if (!IS_ENABLED(CONFIG_DEBUG_FS))
> + return;
> +
> + d = iio_get_debugfs_dentry(indio_dev);
> + if (!d) {
> + dev_warn(st->dev, "can't set debugfs in driver dir\n");
> + return;
> + }
> +
> + debugfs_create_file("data_source", 0600, d, st,
> + &ad3552r_hs_data_source_fops);
> +}
> +
> static int ad3552r_hs_probe(struct platform_device *pdev)
> {
> struct ad3552r_hs_state *st;
> @@ -705,7 +807,17 @@ static int ad3552r_hs_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - return devm_iio_device_register(&pdev->dev, indio_dev);
> + ret = devm_iio_device_register(&pdev->dev, indio_dev);
> + if (ret)
> + return ret;
> +
> + ret = devm_mutex_init(&pdev->dev, &st->lock);
> + if (ret)
> + return ret;
> +
> + ad3552r_hs_debugfs_init(indio_dev);
> +
> + return ret;
> }
>
> static const struct of_device_id ad3552r_hs_of_id[] = {
prev parent reply other threads:[~2025-04-07 16:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 8:52 [PATCH v3 0/5] iio: ad3552r-hs: add support for internal ramp generator Angelo Dureghello
2025-04-07 8:52 ` [PATCH v3 1/5] iio: dac: adi-axi-dac: add cntrl chan check Angelo Dureghello
2025-04-07 16:11 ` Nuno Sá
2025-04-07 8:52 ` [PATCH v3 2/5] docs: iio: add documentation for ad3552r driver Angelo Dureghello
2025-04-07 8:52 ` [PATCH v3 3/5] iio: backend: add support for data source get Angelo Dureghello
2025-04-07 16:12 ` Nuno Sá
2025-04-07 8:52 ` [PATCH v3 4/5] iio: dac: adi-axi-dac: add " Angelo Dureghello
2025-04-07 16:13 ` Nuno Sá
2025-04-07 8:52 ` [PATCH v3 5/5] iio: dac: ad3552r-hs: add support for internal ramp Angelo Dureghello
2025-04-07 16:21 ` Nuno Sá [this message]
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=b0f136eb616876018f2a952ee60d7376258e66fd.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=adureghello@baylibre.com \
--cc=corbet@lwn.net \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=olivier.moysan@foss.st.com \
/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.