linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Sa, Nuno" <Nuno.Sa@analog.com>
To: Jonathan Cameron <jic23@kernel.org>,
	"Chindris, Mihail" <Mihail.Chindris@analog.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>,
	"Bogdan, Dragos" <Dragos.Bogdan@analog.com>
Subject: RE: [PATCH v4 1/6] iio: Add output buffer support
Date: Wed, 1 Sep 2021 08:54:52 +0000	[thread overview]
Message-ID: <MW4PR03MB636324E990C3ED6BF8D6D94399CD9@MW4PR03MB6363.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20210830170555.25887e82@jic23-huawei>



> -----Original Message-----
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Monday, August 30, 2021 6:06 PM
> To: Chindris, Mihail <Mihail.Chindris@analog.com>
> Cc: linux-kernel@vger.kernel.org; linux-iio@vger.kernel.org;
> lars@metafoo.de; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Sa, Nuno
> <Nuno.Sa@analog.com>; Bogdan, Dragos
> <Dragos.Bogdan@analog.com>; alexandru.ardelean@analog.com
> Subject: Re: [PATCH v4 1/6] iio: Add output buffer support
> 
> On Fri, 20 Aug 2021 16:59:22 +0000
> Mihail Chindris <mihail.chindris@analog.com> wrote:
> 
> > From: Lars-Peter Clausen <lars@metafoo.de>
> >
> > Currently IIO only supports buffer mode for capture devices like
> ADCs. Add
> > support for buffered mode for output devices like DACs.
> >
> > The output buffer implementation is analogous to the input buffer
> > implementation. Instead of using read() to get data from the buffer
> write()
> > is used to copy data into the buffer.
> >
> > poll() with POLLOUT will wakeup if there is space available for more
> or
> > equal to the configured watermark of samples.
> >
> > Drivers can remove data from a buffer using
> iio_buffer_remove_sample(), the
> > function can e.g. called from a trigger handler to write the data to
> > hardware.
> >
> > A buffer can only be either a output buffer or an input, but not both.
> So,
> > for a device that has an ADC and DAC path, this will mean 2 IIO
> buffers
> > (one for each direction).
> >
> > The direction of the buffer is decided by the new direction field of
> the
> > iio_buffer struct and should be set after allocating and before
> registering
> > it.
> >
> > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > Signed-off-by: Alexandru Ardelean
> <alexandru.ardelean@analog.com>
> > Signed-off-by: Mihail Chindris <mihail.chindris@analog.com>
> Hi Mihial,
> 
> Welcome to IIO (I don't think I've seen you before?)
> 
> Given the somewhat odd sign off trail I'd add some comments to the
> description
> (probably not saying that everyone who works on this ends up leaving
> Analog.
> It's not cursed! Really it's not ;)  Lars and I discussed this at least 7+
> years
> ago and he lasted ages at Analog after that *evil laugh*
> 
> I'm not really clear how the concept of a watermark applies here. It
> feels
> like it's getting used for two unrelated things:
> 1) Space in buffer for polling form userspace.  We let userspace know it
> can
>    write more data once the watermark worth of scans is empty.
> 2) Writing to the kfifo.  If a large write is attempted we do smaller
> writes to
>    transfer some of the data into the kfifo which can then drain to the
> hardware.
>    I can sort of see this might be beneficial as it provides batching.
> They are somewhat related but it's not totally clear to me they should
> be the
> same parameter.  Perhaps we need some more docs to explain how
> watermark is
> used for output buffers?
> 
> As it stands there are some corner cases around this that look ominous
> to me...
> See inline.
> 
> > ---
> >  drivers/iio/iio_core.h            |   4 +
> >  drivers/iio/industrialio-buffer.c | 133
> +++++++++++++++++++++++++++++-
> >  drivers/iio/industrialio-core.c   |   1 +
> >  include/linux/iio/buffer.h        |   7 ++
> >  include/linux/iio/buffer_impl.h   |  11 +++
> >  5 files changed, 154 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > index 8f4a9b264962..61e318431de9 100644
> > --- a/drivers/iio/iio_core.h
> > +++ b/drivers/iio/iio_core.h
> > @@ -68,12 +68,15 @@ __poll_t iio_buffer_poll_wrapper(struct file
> *filp,
> >  				 struct poll_table_struct *wait);
> >  ssize_t iio_buffer_read_wrapper(struct file *filp, char __user *buf,
> >  				size_t n, loff_t *f_ps);
> > +ssize_t iio_buffer_write_wrapper(struct file *filp, const char __user
> *buf,
> > +				 size_t n, loff_t *f_ps);
> >
> >  int iio_buffers_alloc_sysfs_and_mask(struct iio_dev *indio_dev);
> >  void iio_buffers_free_sysfs_and_mask(struct iio_dev *indio_dev);
> >
> >  #define iio_buffer_poll_addr (&iio_buffer_poll_wrapper)
> >  #define iio_buffer_read_outer_addr (&iio_buffer_read_wrapper)
> > +#define iio_buffer_write_outer_addr
> (&iio_buffer_write_wrapper)
> >
> >  void iio_disable_all_buffers(struct iio_dev *indio_dev);
> >  void iio_buffer_wakeup_poll(struct iio_dev *indio_dev);
> > @@ -83,6 +86,7 @@ void iio_device_detach_buffers(struct iio_dev
> *indio_dev);
> >
> >  #define iio_buffer_poll_addr NULL
> >  #define iio_buffer_read_outer_addr NULL
> > +#define iio_buffer_write_outer_addr NULL
> >
> >  static inline int iio_buffers_alloc_sysfs_and_mask(struct iio_dev
> *indio_dev)
> >  {
> > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> buffer.c
> > index a95cc2da56be..73d4451a0572 100644
> > --- a/drivers/iio/industrialio-buffer.c
> > +++ b/drivers/iio/industrialio-buffer.c
> > @@ -161,6 +161,69 @@ static ssize_t iio_buffer_read(struct file *filp,
> char __user *buf,
> >  	return ret;
> >  }
> >
> > +static size_t iio_buffer_space_available(struct iio_buffer *buf)
> > +{
> > +	if (buf->access->space_available)
> > +		return buf->access->space_available(buf);
> > +
> > +	return SIZE_MAX;
> > +}
> > +
> > +static ssize_t iio_buffer_write(struct file *filp, const char __user
> *buf,
> > +				size_t n, loff_t *f_ps)
> > +{
> > +	struct iio_dev_buffer_pair *ib = filp->private_data;
> > +	struct iio_buffer *rb = ib->buffer;
> > +	struct iio_dev *indio_dev = ib->indio_dev;
> > +	DEFINE_WAIT_FUNC(wait, woken_wake_function);
> > +	size_t datum_size;
> > +	size_t to_wait;
> > +	int ret;
> > +
> > +	if (!rb || !rb->access->write)
> > +		return -EINVAL;
> > +
> > +	datum_size = rb->bytes_per_datum;
> > +
> > +	/*
> > +	 * If datum_size is 0 there will never be anything to read from
> the
> > +	 * buffer, so signal end of file now.
> > +	 */
> > +	if (!datum_size)
> > +		return 0;
> > +
> > +	if (filp->f_flags & O_NONBLOCK)
> > +		to_wait = 0;
> > +	else
> > +		to_wait = min_t(size_t, n / datum_size, rb-
> >watermark);
> 
> Why is the watermark relevant here?  We need enough space for the
> data
> as written whatever the watermark is set to.
> Been a while since I looked at equivalent write path, but I think there
> we are interested in ensuring a hwfifo flushes out.  I'm don't think
> the same concept exists in this direction.
> 
> > +
> > +	add_wait_queue(&rb->pollq, &wait);
> > +	do {
> > +		if (!indio_dev->info) {
> > +			ret = -ENODEV;
> > +			break;
> > +		}
> > +
> > +		if (iio_buffer_space_available(rb) < to_wait) {
> > +			if (signal_pending(current)) {
> > +				ret = -ERESTARTSYS;
> > +				break;
> > +			}
> > +
> > +			wait_woken(&wait, TASK_INTERRUPTIBLE,
> > +				   MAX_SCHEDULE_TIMEOUT);
> > +			continue;
> > +		}
> > +
> > +		ret = rb->access->write(rb, n, buf);
> > +		if (ret == 0 && (filp->f_flags & O_NONBLOCK))
> > +			ret = -EAGAIN;
> 
> Do we need to advance the buf pointer here and reduce n?  We may
> have written
> some but not all the data.
> 
> > +	} while (ret == 0);
> > +	remove_wait_queue(&rb->pollq, &wait);
> > +
> > +	return ret;
> > +}
> > +
> >  /**
> >   * iio_buffer_poll() - poll the buffer to find out if it has data
> >   * @filp:	File structure pointer for device access
> > @@ -181,8 +244,18 @@ static __poll_t iio_buffer_poll(struct file
> *filp,
> >  		return 0;
> >
> >  	poll_wait(filp, &rb->pollq, wait);
> > -	if (iio_buffer_ready(indio_dev, rb, rb->watermark, 0))
> > -		return EPOLLIN | EPOLLRDNORM;
> > +
> > +	switch (rb->direction) {
> > +	case IIO_BUFFER_DIRECTION_IN:
> > +		if (iio_buffer_ready(indio_dev, rb, rb->watermark, 0))
> > +			return EPOLLIN | EPOLLRDNORM;
> > +		break;
> > +	case IIO_BUFFER_DIRECTION_OUT:
> > +		if (iio_buffer_space_available(rb) >= rb->watermark)
> 
> That's interesting.  We should probably make sure we update docs to
> make
> it clear that it has a different meaning for output buffers.  Guess that
> might be later in this set though.
> 
> > +			return EPOLLOUT | EPOLLWRNORM;
> > +		break;
> > +	}
> > +
> >  	return 0;
> >  }
> >
> > @@ -199,6 +272,19 @@ ssize_t iio_buffer_read_wrapper(struct file
> *filp, char __user *buf,
> >  	return iio_buffer_read(filp, buf, n, f_ps);
> >  }
> >
> > +ssize_t iio_buffer_write_wrapper(struct file *filp, const char __user
> *buf,
> > +				 size_t n, loff_t *f_ps)
> > +{
> > +	struct iio_dev_buffer_pair *ib = filp->private_data;
> > +	struct iio_buffer *rb = ib->buffer;
> > +
> > +	/* check if buffer was opened through new API */
> 
> This is new.  We don't need to support the old API.  If we can make
> sure
> it never appears in the old API at all that would be great.
> 
> > +	if (test_bit(IIO_BUSY_BIT_POS, &rb->flags))
> > +		return -EBUSY;
> > +
> > +	return iio_buffer_write(filp, buf, n, f_ps);
> > +}
> > +
> >  __poll_t iio_buffer_poll_wrapper(struct file *filp,
> >  				 struct poll_table_struct *wait)
> >  {
> > @@ -231,6 +317,15 @@ void iio_buffer_wakeup_poll(struct iio_dev
> *indio_dev)
> >  	}
> >  }
> >
> > +int iio_buffer_remove_sample(struct iio_buffer *buffer, u8 *data)
> 
> sample or scan?  Sample would be a single value for a single channel,
> scan would be updates for all channels that are enabled.

Maybe iio_pop_from_buffer()? To be consistent with iio_push_to_buffer()...

- Nuno Sá

  reply	other threads:[~2021-09-01  8:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20 16:59 [PATCH v4 0/6] iio: Add output buffer support and DAC example Mihail Chindris
2021-08-20 16:59 ` [PATCH v4 1/6] iio: Add output buffer support Mihail Chindris
2021-08-21  0:24   ` kernel test robot
2021-08-23  2:23   ` kernel test robot
2021-08-23 13:50   ` Nuno Sá
2021-08-30 15:42     ` Jonathan Cameron
2021-09-01  8:50       ` Sa, Nuno
2021-09-05  9:54         ` Jonathan Cameron
2021-08-25  8:35   ` Alexandru Ardelean
2021-08-30 16:05   ` Jonathan Cameron
2021-09-01  8:54     ` Sa, Nuno [this message]
2021-09-05  9:55       ` Jonathan Cameron
2021-09-16 10:57     ` Chindris, Mihail
2021-08-20 16:59 ` [PATCH v4 2/6] iio: kfifo-buffer: " Mihail Chindris
2021-08-21 14:15   ` kernel test robot
2021-08-23 13:51   ` Nuno Sá
2021-08-20 16:59 ` [PATCH v4 3/6] iio: triggered-buffer: extend support to configure output buffers Mihail Chindris
2021-08-21  3:28   ` kernel test robot
2021-08-20 16:59 ` [PATCH v4 4/6] Documentation:ABI:testing:add doc for AD3552R ABI Mihail Chindris
2021-08-30 15:22   ` Jonathan Cameron
2021-08-20 16:59 ` [PATCH v4 5/6] dt-bindings: iio: dac: Add adi,ad3552r.yaml Mihail Chindris
2021-08-30 15:37   ` Jonathan Cameron
2021-08-20 16:59 ` [PATCH v4 6/6] drivers:iio:dac: Add AD3552R driver support Mihail Chindris
2021-08-20 19:55   ` kernel test robot
2021-08-20 22:15   ` kernel test robot
2021-08-23 14:01   ` Nuno Sá
2021-08-30 16:54   ` Jonathan Cameron
2021-08-25  7:35 ` [PATCH v4 0/6] iio: Add output buffer support and DAC example Alexandru Ardelean
2021-08-30 15:17   ` Jonathan Cameron
     [not found] <202108222341.6RtluiRt-lkp@intel.com>
2021-08-25 15:31 ` [PATCH v4 1/6] iio: Add output buffer support kernel test robot

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=MW4PR03MB636324E990C3ED6BF8D6D94399CD9@MW4PR03MB6363.namprd03.prod.outlook.com \
    --to=nuno.sa@analog.com \
    --cc=Dragos.Bogdan@analog.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=Mihail.Chindris@analog.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).