From: Thierry Reding <thierry.reding@gmail.com>
To: Akhil R <akhilrajeev@nvidia.com>
Cc: Vinod Koul <vkoul@kernel.org>, Frank Li <Frank.Li@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Laxman Dewangan <ldewangan@nvidia.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
Frank Li <Frank.Li@nxp.com>
Subject: Re: [PATCH v6 06/10] dmaengine: tegra: Support address width > 39 bits
Date: Fri, 22 May 2026 12:32:20 +0200 [thread overview]
Message-ID: <ahAtps7D2ZgjlP6f@orome> (raw)
In-Reply-To: <20260331102303.33181-7-akhilrajeev@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]
On Tue, Mar 31, 2026 at 03:52:59PM +0530, Akhil R wrote:
> Tegra264 supports address width of 41 bits. Unlike older SoCs which use
> a common high_addr register for upper address bits, Tegra264 has separate
> src_high and dst_high registers to accommodate this wider address space.
>
> Add an addr_bits property to the device data structure to specify the
> number of address bits supported on each device and use that to program
> the appropriate registers.
>
> Update the sg_req struct to remove the high_addr field and use
> dma_addr_t for src and dst to store the complete addresses. Extract
> the high address bits only when programming the registers.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/dma/tegra186-gpc-dma.c | 83 +++++++++++++++++++++-------------
> 1 file changed, 52 insertions(+), 31 deletions(-)
Sorry for not noticing this earlier.
My understanding is that previously this IP (along with most others) did
support 40 bit addressing. That's a much more natural boundary, too. The
reason why 39 is often mentioned in this context is that bit 39 was
treated specially and interpreted by the memory controller as a way to
swizzle memory between the Tegra and discrete GPU formats.
I assume GPC DMA was in the same category. I'd be very surprised if
there really was a limit on exactly 39 bits. Looking at the register
documentation, I see that the high address register is 8 bits, which
together with the 32 bits from the regular ADR register gives 40 bits.
Given the above this patch looks wrong. Technically the previous
iterations did support the full 40 bits, and that should be reflected in
the DMA mask. The platform-specific 39-bit restriction due to the
swizzle bit is something that we've always represented via the
dma-ranges property, but it doesn't reflect the capabilities of the
hardware.
It's a bit odd that GPC DMA on Tegra264 supports 41 bits. I think the
regular address map is only 40 bits, but I guess if the registers define
it this way, might as well support it.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-05-22 10:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 10:22 [PATCH v6 00/10] Add GPCDMA support in Tegra264 Akhil R
2026-03-31 10:22 ` [PATCH v6 01/10] dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional Akhil R
2026-05-22 10:09 ` Thierry Reding
2026-03-31 10:22 ` [PATCH v6 02/10] arm64: tegra: Remove fallback compatible for GPCDMA Akhil R
2026-03-31 10:22 ` [PATCH v6 03/10] dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property Akhil R
2026-05-22 10:10 ` Thierry Reding
2026-03-31 10:22 ` [PATCH v6 04/10] dmaengine: tegra: Make reset control optional Akhil R
2026-05-22 10:11 ` Thierry Reding
2026-03-31 10:22 ` [PATCH v6 05/10] dmaengine: tegra: Use struct for register offsets Akhil R
2026-05-22 10:15 ` Thierry Reding
2026-03-31 10:22 ` [PATCH v6 06/10] dmaengine: tegra: Support address width > 39 bits Akhil R
2026-05-22 10:32 ` Thierry Reding [this message]
2026-03-31 10:23 ` [PATCH v6 07/10] dmaengine: tegra: Use managed DMA controller registration Akhil R
2026-05-22 10:33 ` Thierry Reding
2026-03-31 10:23 ` [PATCH v6 08/10] dmaengine: tegra: Use iommu-map for stream ID Akhil R
2026-03-31 14:12 ` Frank Li
2026-05-22 10:37 ` Thierry Reding
2026-03-31 10:23 ` [PATCH v6 09/10] dmaengine: tegra: Add Tegra264 support Akhil R
2026-05-22 10:38 ` Thierry Reding
2026-03-31 10:23 ` [PATCH v6 10/10] arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map Akhil R
2026-03-31 18:06 ` [PATCH v6 00/10] Add GPCDMA support in Tegra264 Jon Hunter
2026-04-10 8:09 ` Jon Hunter
2026-05-06 3:46 ` Akhil R
2026-05-21 10:07 ` Jon Hunter
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=ahAtps7D2ZgjlP6f@orome \
--to=thierry.reding@gmail.com \
--cc=Frank.Li@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=akhilrajeev@nvidia.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=krzk+dt@kernel.org \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@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