On Thu, Feb 12, 2026 at 03:50:09PM +0100, Thierry Reding wrote: > On Fri, Jan 23, 2026 at 02:30:14PM +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Jan 22, 2026 at 05:10:05PM +0100, Thierry Reding wrote: > > > From: Thierry Reding <[email protected]> > > > > > > NVIDIA Tegra SoCs commonly define a Video-Protection-Region, which is a > > > region of memory dedicated to content-protected video decode and > > > playback. This memory cannot be accessed by the CPU and only certain > > > hardware devices have access to it. > > > > > > Expose the VPR as a DMA heap so that applications and drivers can > > > allocate buffers from this region for use-cases that require this kind > > > of protected memory. > > > > > > VPR has a few very critical peculiarities. First, it must be a single > > > contiguous region of memory (there is a single pair of registers that > > > set the base address and size of the region), which is configured by > > > calling back into the secure monitor. The memory region also needs to > > > quite large for some use-cases because it needs to fit multiple video > > > frames (8K video should be supported), so VPR sizes of ~2 GiB are > > > expected. However, some devices cannot afford to reserve this amount > > > of memory for a particular use-case, and therefore the VPR must be > > > resizable. > > > > > > Unfortunately, resizing the VPR is slightly tricky because the GPU found > > > on Tegra SoCs must be in reset during the VPR resize operation. This is > > > currently implemented by freezing all userspace processes and calling > > > invoking the GPU's freeze() implementation, resizing and the thawing the > > > GPU and userspace processes. This is quite heavy-handed, so eventually > > > it might be better to implement thawing/freezing in the GPU driver in > > > such a way that they block accesses to the GPU so that the VPR resize > > > operation can happen without suspending all userspace. > > > > > > In order to balance the memory usage versus the amount of resizing that > > > needs to happen, the VPR is divided into multiple chunks. Each chunk is > > > implemented as a CMA area that is completely allocated on first use to > > > guarantee the contiguity of the VPR. Once all buffers from a chunk have > > > been freed, the CMA area is deallocated and the memory returned to the > > > system. > > > > > > Signed-off-by: Thierry Reding <[email protected]> > > > > Aside from the discussion on CMA, it doesn't look like the heap defines > > anywhere the attributes of the allocated buffers this heap provides. > > Attributes like what? Where would you expect the driver to define this? > I don't see anything in struct drm_heap_export_info that sounds like > what you expect, nor does the allocation ABI provide any means of > reporting attributes. > > There's also not a whole lot to this, other than that the memory > allocated by this can't be accessed by anything other than a select set > of devices. You can't have any CPU access to these buffers (the hardware > will refuse to let the CPU read from this memory) either, which is > hinted at by the fact that no mmap() operations are allowed. > > Can you elaborate what you're looking for?
Are the buffers you're getting when allocating cacheable? uncacheable? mappable? physically or virtually contiguous? etc. See https://docs.kernel.org/userspace-api/dma-buf-heaps.html#heaps Maxime
signature.asc
Description: PGP signature
