On Tue, Oct 27, 2026 at 03:15:34AM +0100, 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.
Why is this being reported here? Shouldn't CONFIG_DMABUF_DEBUG=y have
always caused tegra to fail?
> > @@ -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
This is illegal use of dmabuf, this was discussed in some other driver
recently.
All DRM drivers trying to use custom iommu domains are busted this
way. AFAIK there is no solution besides "don't do that".
> 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?
Tegra is broken.
Jason
