On Tuesday, October 27, 2026 11:15 AM Karl Mehltretter wrote:
> On Mon, Oct 26, 2026 at 04:36:14PM +0100, Alistair Popple wrote:
>
> Testing the series on a Jetson Nano exposed this path. A 3 MiB system-heap
> buffer was imported into Tegra DRM and scanned out over HDMI. With
> CONFIG_DMABUF_DEBUG=y the PRIME import succeeded, but scanout immediately
> produced display SMMU faults starting at 0x300000.
>
> Tracing the fault led here:
>
> > @@ -475,7 +475,7 @@ static struct tegra_bo *tegra_bo_import(struct
> > drm_device *drm,
> > * domain, map it first to the DRM device to get an sgt.
> > */
> > if (tegra->domain) {
> > - attach = dma_buf_attach(buf, drm->dev);
> > + attach = dma_buf_sgt_attach(buf, drm->dev);
>
> tegra_bo_import() passes the attachment SGT to iommu_map_sgtable(), which
> uses sg_phys() and sg->length. The SGT mapping contract only guarantees the
> DMA address and length fields. The debug wrapper clears the page-side fields,
> so iommu_map_sgtable() maps zero bytes.
>
> Tegra only treats negative returns as errors and keeps the reserved
> IOVA, which scanout then faults on.
>
> This page-side use predates the series, so the fault is not itself a v2
> regression. Is dma_buf_sgt_attach() valid for this call site, or does Tegra
> need a page/physical mapping type first?
>
> Karl
>
Sounds like a bug in TegraDRM; we should be using the DMA addr/length
for the explicit IOMMU mapping as the sgt attachment is for the dummy
DRM device explicitly intended to give us physical addresses.
I'm currently in the process of removing the whole explicit IOMMU path
so if this only occurs with CONFIG_DMABUF_DEBUG enabled, I don't think
there's a pressing need to fix this before then.
Thanks for the bug report!
Mikko
