public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Kartik Rajput <kkartik@nvidia.com>
To: Frank Li <Frank.li@nxp.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 11:36:18 +0530	[thread overview]
Message-ID: <a2efd470-6c66-4686-8cc2-ce767aac930a@nvidia.com> (raw)
In-Reply-To: <aZ4jwJ330VUXBNuE@lizhi-Precision-Tower-5810>

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.


Thanks,
Kartik

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

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24  8:34 [PATCH] dmaengine: tegra: Fix burst size calculation Kartik Rajput
2026-02-24 22:18 ` Frank Li
2026-02-25  6:06   ` Kartik Rajput [this message]
2026-02-25 20:06     ` Frank Li

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=a2efd470-6c66-4686-8cc2-ce767aac930a@nvidia.com \
    --to=kkartik@nvidia.com \
    --cc=Frank.Li@kernel.org \
    --cc=Frank.li@nxp.com \
    --cc=akhilrajeev@nvidia.com \
    --cc=digetx@gmail.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=jonathanh@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