mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@nxp.com>
To: Kartik Rajput <kkartik@nvidia.com>
Cc: ldewangan@nvidia.com, jonathanh@nvidia.com,
	akhilrajeev@nvidia.com, vkoul@kernel.org, Frank.Li@kernel.org,
	thierry.reding@kernel.org, digetx@gmail.com,
	pkunapuli@nvidia.com, dmaengine@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] dmaengine: tegra: Fix burst size calculation
Date: Wed, 25 Feb 2026 15:06:40 -0500	[thread overview]
Message-ID: <aZ9WUPglQp9NTGax@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <a2efd470-6c66-4686-8cc2-ce767aac930a@nvidia.com>

On Wed, Feb 25, 2026 at 11:36:18AM +0530, Kartik Rajput wrote:
> On 25/02/26 03:48, Frank Li wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Feb 24, 2026 at 02:04:54PM +0530, Kartik Rajput wrote:
> > > Currently, the Tegra GPC DMA hardware requires the transfer length to
> > > be a multiple of the max burst size configured for the channel. When a
> > > client requests a transfer where the length is not evenly divisible by
> > > the configured max burst size, the DMA hangs with partial burst at
> > > the end.
> > >
> > > Fix this by reducing the burst size to the largest power-of-2 value
> > > that evenly divides the transfer length. For example, a 40-byte
> > > transfer with a 16-byte max burst will now use an 8-byte burst
> > > (40 / 8 = 5 complete bursts) instead of causing a hang.
> > >
> > > This issue was observed with the PL011 UART driver where TX DMA
> > > transfers of arbitrary lengths were stuck.
> >
> > Suppose set burst size by UART driver through dma_config_slave. it depend
> > on uart's watermark settings.
> >
> > Optimaized method as your example is set first transfer burst length 32,
> > the second transfer is 8.
> >
> > Frank
> > >
> > > Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> > > ---
> > >   drivers/dma/tegra186-gpc-dma.c | 7 +++++++
> > >   1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
> > > index 4d6fe0efa76e..7df0a745e7b8 100644
> > > --- a/drivers/dma/tegra186-gpc-dma.c
> > > +++ b/drivers/dma/tegra186-gpc-dma.c
> > > @@ -825,6 +825,13 @@ static unsigned int get_burst_size(struct tegra_dma_channel *tdc,
> > >         * len to calculate the optimum burst size
> > >         */
> > >        burst_byte = burst_size ? burst_size * slave_bw : len;
> > > +
> > > +     /*
> > > +      * Find the largest burst size that evenly divides the transfer length.
> > > +      * The hardware requires the transfer length to be a multiple of the
> > > +      * burst size - partial bursts are not supported.
> > > +      */
> > > +     burst_byte = min(burst_byte, 1U << __ffs(len));
> > >        burst_mmio_width = burst_byte / 4;
> > >
> > >        if (burst_mmio_width < TEGRA_GPCDMA_MMIOSEQ_BURST_MIN)
> > > --
> > > 2.43.0
> > >
>
> Hi Frank,
>
> Thanks for reviewing the patch.
>
> The primary goal of this change is correctness. GPCDMA requires the programmed
> burst size to evenly divide the transfer length; otherwise, the transfer can hang
> due to an incomplete final burst.
>
> While dmaengine_slave_config() allows clients to specify a maxburst based on
> their FIFO configuration, DMAengine does not guarantee that every submitted
> transfer length will be divisible by that value. Since clients may submit
> arbitrary lengths, the driver must ensure the programmed burst size is valid
> for each descriptor.
>
> This change simply makes sure the burst we program does not exceed the
> configured maxburst and divides the transfer length, so we don’t end up
> programming something the hardware cannot handle.

Okay, it is fine.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
>
> Thanks,
> Kartik

      reply	other threads:[~2026-02-25 20:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24  8:34 Kartik Rajput
2026-02-24 22:18 ` Frank Li
2026-02-25  6:06   ` Kartik Rajput
2026-02-25 20:06     ` Frank Li [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=aZ9WUPglQp9NTGax@lizhi-Precision-Tower-5810 \
    --to=frank.li@nxp.com \
    --cc=Frank.Li@kernel.org \
    --cc=akhilrajeev@nvidia.com \
    --cc=digetx@gmail.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=kkartik@nvidia.com \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pkunapuli@nvidia.com \
    --cc=stable@vger.kernel.org \
    --cc=thierry.reding@kernel.org \
    --cc=vkoul@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

all inboxes | Powered by JetHome®