LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: "Sa, Nuno" <Nuno.Sa@analog.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 03/16] iio: adc: max1027: Push only the requested samples
Date: Sat, 4 Sep 2021 15:06:45 +0100	[thread overview]
Message-ID: <20210904150645.640d2810@jic23-huawei> (raw)
In-Reply-To: <20210901101209.31703187@xps13>

On Wed, 1 Sep 2021 10:12:09 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Hello,
> 
> "Sa, Nuno" <Nuno.Sa@analog.com> wrote on Mon, 30 Aug 2021 15:02:26
> +0000:
> 
> > > -----Original Message-----
> > > From: Jonathan Cameron <jic23@kernel.org>
> > > Sent: Monday, August 30, 2021 4:30 PM
> > > To: Sa, Nuno <Nuno.Sa@analog.com>
> > > Cc: Miquel Raynal <miquel.raynal@bootlin.com>; Lars-Peter Clausen
> > > <lars@metafoo.de>; Thomas Petazzoni
> > > <thomas.petazzoni@bootlin.com>; linux-iio@vger.kernel.org; linux-
> > > kernel@vger.kernel.org
> > > Subject: Re: [PATCH 03/16] iio: adc: max1027: Push only the requested
> > > samples
> > > 
> > > [External]
> > > 
> > > On Mon, 30 Aug 2021 10:49:50 +0000
> > > "Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> > >     
> > > > > -----Original Message-----
> > > > > From: Jonathan Cameron <jic23@kernel.org>
> > > > > Sent: Monday, August 30, 2021 12:08 PM
> > > > > To: Sa, Nuno <Nuno.Sa@analog.com>
> > > > > Cc: Miquel Raynal <miquel.raynal@bootlin.com>; Lars-Peter    
> > > Clausen    
> > > > > <lars@metafoo.de>; Thomas Petazzoni
> > > > > <thomas.petazzoni@bootlin.com>; linux-iio@vger.kernel.org;    
> > > linux-    
> > > > > kernel@vger.kernel.org
> > > > > Subject: Re: [PATCH 03/16] iio: adc: max1027: Push only the    
> > > requested    
> > > > > samples
> > > > >
> > > > > [External]
> > > > >
> > > > > On Fri, 20 Aug 2021 07:10:48 +0000
> > > > > "Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> > > > >    
> > > > > > > -----Original Message-----
> > > > > > > From: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > Sent: Wednesday, August 18, 2021 1:11 PM
> > > > > > > To: Jonathan Cameron <jic23@kernel.org>; Lars-Peter Clausen
> > > > > > > <lars@metafoo.de>
> > > > > > > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>; linux-
> > > > > > > iio@vger.kernel.org; linux-kernel@vger.kernel.org; Miquel    
> > > Raynal    
> > > > > > > <miquel.raynal@bootlin.com>
> > > > > > > Subject: [PATCH 03/16] iio: adc: max1027: Push only the    
> > > requested    
> > > > > > > samples
> > > > > > >
> > > > > > > [External]
> > > > > > >
> > > > > > > When a triggered scan occurs, the identity of the desired    
> > > channels    
> > > > > is    
> > > > > > > known in indio_dev->active_scan_mask. Instead of reading and
> > > > > > > pushing to
> > > > > > > the IIO buffers all channels each time, scan the minimum    
> > > amount    
> > > > > of    
> > > > > > > channels (0 to maximum requested chan, to be exact) and only
> > > > > > > provide the
> > > > > > > samples requested by the user.
> > > > > > >
> > > > > > > For example, if the user wants channels 1, 4 and 5, all channels    
> > > > > from    
> > > > > > > 0 to 5 will be scanned but only the desired channels will be    
> > > pushed    
> > > > > to    
> > > > > > > the IIO buffers.
> > > > > > >
> > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > ---
> > > > > > >  drivers/iio/adc/max1027.c | 25 +++++++++++++++++++++----
> > > > > > >  1 file changed, 21 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/iio/adc/max1027.c    
> > > b/drivers/iio/adc/max1027.c    
> > > > > > > index b753658bb41e..8ab660f596b5 100644
> > > > > > > --- a/drivers/iio/adc/max1027.c
> > > > > > > +++ b/drivers/iio/adc/max1027.c
> > > > > > > @@ -360,6 +360,9 @@ static int    
> > > max1027_set_trigger_state(struct    
> > > > > > > iio_trigger *trig, bool state)
> > > > > > >  	struct max1027_state *st = iio_priv(indio_dev);
> > > > > > >  	int ret;
> > > > > > >
> > > > > > > +	if (bitmap_empty(indio_dev->active_scan_mask,    
> > > indio_dev-    
> > > > > > > >masklength))    
> > > > > > > +		return -EINVAL;
> > > > > > > +    
> > > > > >
> > > > > > I'm not sure this can actually happen. If you try to enable the    
> > > buffer    
> > > > > > with no scan element, it should give you an error before you    
> > > reach    
> > > > > > this point...
> > > > > >    
> > > > > > >  	if (state) {
> > > > > > >  		/* Start acquisition on cnvst */
> > > > > > >  		st->reg = MAX1027_SETUP_REG |
> > > > > > > MAX1027_CKS_MODE0 |
> > > > > > > @@ -368,9 +371,12 @@ static int    
> > > max1027_set_trigger_state(struct    
> > > > > > > iio_trigger *trig, bool state)
> > > > > > >  		if (ret < 0)
> > > > > > >  			return ret;
> > > > > > >
> > > > > > > -		/* Scan from 0 to max */
> > > > > > > -		st->reg = MAX1027_CONV_REG |    
> > > MAX1027_CHAN(0) |    
> > > > > > > -			  MAX1027_SCAN_N_M |    
> > > MAX1027_TEMP;    
> > > > > > > +		/*
> > > > > > > +		 * Scan from 0 to the highest requested    
> > > channel. The    
> > > > > > > temperature
> > > > > > > +		 * could be avoided but it simplifies a bit the    
> > > logic.    
> > > > > > > +		 */
> > > > > > > +		st->reg = MAX1027_CONV_REG |
> > > > > > > MAX1027_SCAN_0_N | MAX1027_TEMP;
> > > > > > > +		st->reg |= MAX1027_CHAN(fls(*indio_dev-    
> > > > > > > >active_scan_mask) - 2);    
> > > > > > >  		ret = spi_write(st->spi, &st->reg, 1);
> > > > > > >  		if (ret < 0)
> > > > > > >  			return ret;
> > > > > > > @@ -391,11 +397,22 @@ static irqreturn_t
> > > > > > > max1027_trigger_handler(int irq, void *private)
> > > > > > >  	struct iio_poll_func *pf = private;
> > > > > > >  	struct iio_dev *indio_dev = pf->indio_dev;
> > > > > > >  	struct max1027_state *st = iio_priv(indio_dev);
> > > > > > > +	unsigned int scanned_chans = fls(*indio_dev-    
> > > > > > > >active_scan_mask);    
> > > > > > > +	u16 *buf = st->buffer;    
> > > > > >
> > > > > > I think sparse will complain here. buffer is a __be16 restricted
> > > > > > type so you should not mix those...    
> > > > > > > +	unsigned int bit;
> > > > > > >
> > > > > > >  	pr_debug("%s(irq=%d, private=0x%p)\n", __func__,    
> > > irq,    
> > > > > > >    
> > > > >    
> > > private);in/20210818_miquel_raynal_bring_software_triggers_support    
> > > > > _to_max1027_like_adcs.mbx    
> > > > > > >
> > > > > > >  	/* fill buffer with all channel */
> > > > > > > -	spi_read(st->spi, st->buffer, indio_dev->masklength *    
> > > 2);    
> > > > > > > +	spi_read(st->spi, st->buffer, scanned_chans * 2);
> > > > > > > +
> > > > > > > +	/* Only keep the channels selected by the user */
> > > > > > > +	for_each_set_bit(bit, indio_dev->active_scan_mask,
> > > > > > > +			 indio_dev->masklength) {
> > > > > > > +		if (buf[0] != st->buffer[bit])
> > > > > > > +			buf[0] = st->buffer[bit];    
> > > > > >
> > > > > > Since we are here, when looking into the driver, I realized
> > > > > > that st->buffer is not DMA safe. In IIO, we kind of want to    
> > > enforce    
> > > > > > that all buffers that are passed to spi/i2c buses are safe... Maybe
> > > > > > this is something you can include in your series.    
> > > > >
> > > > > Why is it not?  st->buffer is result of a devm_kmalloc_array() call    
> > > and    
> > > > > that should provide a DMA safe buffer as I understand it.
> > > > >    
> > > >
> > > > That's a good question. I'm not sure how I came to that conclusion    
> > > which    
> > > > is clearly wrong. Though I think the buffer might share the line with    
> > > the    
> > > > mutex...    
> > > Pointer shares a line.  The buffer it points to doesn't as allocated
> > > by separate heap allocation.
> > >     
> > 
> > Ups, sure :facepalm:  
> 
> My understanding [1] was that devm_ allocations were generally not
> suitable for DMA and should not be used for this particular purpose
> because of the extra 16 bytes allocated for storing the devm magic
> somewhere, which shifts the entire buffer and prevents it to always be
> aligned on a cache line. I will propose a patch to switch to
> kmalloc_array() instead.
> 
> [1] https://linux-arm-kernel.infradead.narkive.com/vyJqy0RQ/question-devm-kmalloc-for-dma

That shouldn't actually matter because here we don't care about
it being aligned on a cacheline - but we do care about it being
aligned so that nothing else we might touch is in the same cacheline.
Note the thread you link talks about this.

If we were possibly doing additional devm_ managed allocations
whilst DMA was active then it might be a problem, but
I'm fairly sure we aren't doing that here.

Not there might be a bus controller that has stricter alignment
requirements - whether we need to be careful of those isn't
particularly clear to me.  There are lots of places in IIO
where we cachealign a set of buffers, but for example the
rx is after the tx buffers and isn't aligned as would be
required. As such I'm fairly sure it's not a problem.

Jonathan


> 
> Thanks,
> Miquèl


  reply	other threads:[~2021-09-04 14:03 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 11:11 [PATCH 00/16] Bring software triggers support to MAX1027-like ADCs Miquel Raynal
2021-08-18 11:11 ` [PATCH 01/16] iio: adc: max1027: Fix wrong shift with 12-bit devices Miquel Raynal
2021-08-20  7:02   ` Sa, Nuno
2021-08-30  9:57     ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 02/16] iio: adc: max1027: Fix the number of max1X31 channels Miquel Raynal
2021-08-20  7:03   ` Sa, Nuno
2021-08-30 10:00     ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 03/16] iio: adc: max1027: Push only the requested samples Miquel Raynal
2021-08-20  7:10   ` Sa, Nuno
2021-08-30 10:07     ` Jonathan Cameron
2021-08-30 10:49       ` Sa, Nuno
2021-08-30 14:29         ` Jonathan Cameron
2021-08-30 15:02           ` Sa, Nuno
2021-09-01  8:12             ` Miquel Raynal
2021-09-04 14:06               ` Jonathan Cameron [this message]
2021-09-06  8:59               ` Sa, Nuno
2021-09-06 16:56                 ` Jonathan Cameron
2021-09-06 17:34                   ` Miquel Raynal
2021-08-30 10:06   ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 04/16] iio: adc: max1027: Lower conversion time Miquel Raynal
2021-08-20  7:12   ` Sa, Nuno
2021-08-30 10:10   ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 05/16] iio: adc: max1027: Drop extra warning message Miquel Raynal
2021-08-20  7:12   ` Sa, Nuno
2021-08-30 10:12   ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 06/16] iio: adc: max1027: Rename a helper Miquel Raynal
2021-08-20  7:13   ` Sa, Nuno
2021-08-18 11:11 ` [PATCH 07/16] iio: adc: max1027: Create a helper to configure the trigger Miquel Raynal
2021-08-20  7:16   ` Sa, Nuno
2021-08-30 10:16   ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 08/16] iio: adc: max1027: Explain better how the trigger state gets changed Miquel Raynal
2021-08-20  7:17   ` Sa, Nuno
2021-08-18 11:11 ` [PATCH 09/16] iio: adc: max1027: Create a helper to configure the channels to scan Miquel Raynal
2021-08-20  7:18   ` Sa, Nuno
2021-08-18 11:11 ` [PATCH 10/16] iio: adc: max1027: Prevent single channel accesses during buffer reads Miquel Raynal
2021-08-20  7:20   ` Sa, Nuno
2021-08-20  7:30     ` Sa, Nuno
2021-08-30 10:20       ` Jonathan Cameron
2021-09-02  8:56         ` Miquel Raynal
2021-08-18 11:11 ` [PATCH 11/16] iio: adc: max1027: Separate the IRQ handler from the read logic Miquel Raynal
2021-08-20  7:23   ` Sa, Nuno
2021-09-02  8:55     ` Miquel Raynal
2021-09-04 14:08       ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 12/16] iio: adc: max1027: Introduce an end of conversion helper Miquel Raynal
2021-08-20  7:28   ` Sa, Nuno
2021-09-02  9:26     ` Miquel Raynal
2021-08-30 10:34   ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 13/16] iio: adc: max1027: Prepare re-using the EOC interrupt Miquel Raynal
2021-08-20  7:31   ` Sa, Nuno
2021-08-30 10:30   ` Jonathan Cameron
2021-08-30 10:47   ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 14/16] iio: adc: max1027: Consolidate the end of conversion helper Miquel Raynal
2021-08-20  7:45   ` Sa, Nuno
2021-08-30 10:37   ` Jonathan Cameron
2021-08-30 12:44     ` Sa, Nuno
2021-08-30 14:32       ` Jonathan Cameron
2021-09-02 15:12       ` Miquel Raynal
2021-09-03 14:28         ` Sa, Nuno
2021-09-03 14:46           ` Miquel Raynal
2021-09-05  9:41             ` Jonathan Cameron
2021-09-06  9:12               ` Sa, Nuno
2021-09-06  9:30                 ` Sa, Nuno
2021-08-18 11:11 ` [PATCH 15/16] iio: adc: max1027: Support software triggers Miquel Raynal
2021-08-20  7:58   ` Sa, Nuno
2021-09-02 12:25     ` Miquel Raynal
2021-09-03 14:20       ` Sa, Nuno
2021-08-30 10:50   ` Jonathan Cameron
2021-09-02 15:21     ` Miquel Raynal
2021-09-05  9:43       ` Jonathan Cameron
2021-08-18 11:11 ` [PATCH 16/16] iio: adc: max1027: Enable software triggers to be used without IRQ Miquel Raynal
2021-08-30 10:54   ` 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=20210904150645.640d2810@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Nuno.Sa@analog.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    --subject='Re: [PATCH 03/16] iio: adc: max1027: Push only the requested samples' \
    /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

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).