On Wed, Oct 7, 2026 at 6:16 AM Jianfeng Liu <[email protected]> wrote: > > Hi Rob, > > On Tue, Oct 6, 2026 at 6:09 AM Rob Clark wrote: > > With DMABUF_DEBUG=y, the page information is stripped from the sgt that > > we get for an externally allocated buffer that is dma-buf imported (as > > opposed to an exported GEM buffer that is re-imported). [...] > > Tested on the machine that originally reported the breakage - this > exercises exactly the externally-allocated-buffer case from your cover > letter: > > Tested-by: Jianfeng Liu <[email protected]> # x1e78100 (Acer > SFA14-11), v7.3-rc5 + this series, CONFIG_DMABUF_DEBUG=y > > Hardware video decode in chromium (V4L2 decoder capture buffers from > videobuf2-dma-contig imported into msm and rendered by the GPU) > displays correctly, with zero arm-smmu faults and zero io-pgtable > WARNs. For comparison, on plain v7.3-rc5 with DMABUF_DEBUG=y the > same workload logs UCHE translation faults and a __arm_lpae_unmap() > WARN storm (~470 traces per minute of playback). > > This is also much cleaner than the translation-based approach in the > follow-up series I withdrew - mapping from the DMA addresses is where > I should have ended up in the first place. > > One small suggestion for __do_map(): panthor treats "map_pages() > mapped nothing" as an error (panthor_mmu.c): > > /* If nothing was mapped, consider it an ENOMEM. */ > if (!ret && !mapped) > ret = -ENOMEM;
Yeah, that is probably a good idea. Thanks for testing BR, -R > > With the DMA fields now populated on both paths this should not > trigger in practice, but it would turn any future regression back > into a loud failure instead of a silent empty mapping - which is > the failure mode this whole series fixes. > > Happy to run more (heap-exported dmabuf import test, kmssink scanout > of V4L2 frames) on any revision. > > BR, > Jianfeng
