All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: jic23@kernel.org, dlechner@baylibre.com, nuno.sa@analog.com,
	andy@kernel.org, robh@kernel.org, conor+dt@kernel.org,
	krzk+dt@kernel.org, linux-iio@vger.kernel.org, s32@nxp.com,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	chester62515@gmail.com, mbrugger@suse.com,
	ghennadi.procopciuc@oss.nxp.com
Subject: Re: [PATCH v5 2/2] iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms
Date: Fri, 31 Oct 2025 14:45:25 +0200	[thread overview]
Message-ID: <aQSvZT73NBWZFVfk@smile.fi.intel.com> (raw)
In-Reply-To: <c4c14051-2ba2-4d80-a22d-4deb3709f727@linaro.org>

On Fri, Oct 31, 2025 at 12:32:03PM +0100, Daniel Lezcano wrote:
> On 10/30/25 10:28, Andy Shevchenko wrote:
> > On Thu, Oct 30, 2025 at 09:27:21AM +0100, Daniel Lezcano wrote:
> > > On 10/18/25 22:12, Andy Shevchenko wrote:
> > > > On Fri, Oct 17, 2025 at 06:42:38PM +0200, Daniel Lezcano wrote:

[ ... ]

> > > > > +	dma_samples = (u32 *)dma_buf->buf;
> > > > 
> > > > Is it aligned properly for this type of casting?
> > > 
> > > TBH, I don't know the answer :/
> > > 
> > > How can I check that ?
> > 
> > Is buf defined as a pointer to u32 / int or bigger? or is it just byte buffer?
> > If the latter, how does the address of it being formed? Does it come from a heap
> > (memory allocator)? If yes, we are fine, as this is usually the case for all
> > (k)malloc'ed memory.
> 
> buf is a byte buffer allocated with dmam_alloc_coherent(..., GFP_KERNEL)

We are fine :-)

...

> > > > > +	dmaengine_tx_status(info->dma_chan, info->cookie, &state);
> > > > 
> > > > No return value check?
> > > 
> > > The return value is not necessary here because the caller of the callback
> > > will check with dma_submit_error() in case of error which covers the
> > > DMA_ERROR case and the other cases are not useful because the residue is
> > > taken into account right after.
> > 
> > In some cases it might return DMA_PAUSE (and actually this is the correct way
> > to get residue, one needs to pause the channel to read it, otherwise it will
> > give outdated / incorrect information).
> 
> But if the residue is checked in the callback routine without checking
> DMA_PAUSED, the result is the same no ?

DMA in some corner cases might have already be charged for the next transfer.
Do you have a synchronisation between DMA start and residue check?

I.o.w. this may work for your case, but in general it's not guaranteed. The proper
read of residue is to: pause DMA --> read residue --> resume DMA.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2025-10-31 12:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17 16:42 [PATCH v5 0/2] NXP SAR ADC IIO driver for s32g2/3 platforms Daniel Lezcano
2025-10-17 16:42 ` [PATCH v5 1/2] dt-bindings: iio: adc: Add the NXP SAR ADC " Daniel Lezcano
2025-10-17 16:42 ` [PATCH v5 2/2] iio: adc: Add the NXP SAR ADC support for the " Daniel Lezcano
2025-10-18 20:12   ` Andy Shevchenko
2025-10-30  8:27     ` Daniel Lezcano
2025-10-30  9:28       ` Andy Shevchenko
2025-10-31  8:03         ` Daniel Lezcano
2025-10-31 11:32         ` Daniel Lezcano
2025-10-31 12:45           ` Andy Shevchenko [this message]
2025-11-07 11:36             ` Daniel Lezcano
2025-11-18 14:20               ` Andy Shevchenko
2025-11-18 13:57             ` Daniel Lezcano
2025-11-18 14:22               ` Andy Shevchenko
2025-10-19  8:42   ` Jonathan Cameron
2025-11-07 11:15     ` Vinod Koul
2025-11-09 12: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=aQSvZT73NBWZFVfk@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=chester62515@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=ghennadi.procopciuc@oss.nxp.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbrugger@suse.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=s32@nxp.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.