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
prev parent 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®