Re: [PATCH v2 06/10] dma-buf: heaps: Add support for Tegra VPR

Re: [PATCH v2 06/10] dma-buf: heaps: Add support for Tegra VPR

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4014 bytes --]

On Wed, Feb 18, 2026 at 10:42:22AM +0100, Maxime Ripard wrote:
> 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 <treding@nvidia.com>
> > > > 
> > > > 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 <treding@nvidia.com>
> > > 
> > > 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

The CPU doesn't have access to the contents of these buffers, so
cacheable or uncacheable aren't really meaningful, but I guess they are
unmappable in that sense. The buffers are physically contiguous, but I
think "protected" is the right name for the heap since it most
accurately describes what the purpose (and access pattern) is.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 06/10] dma-buf: heaps: Add support for Tegra VPR

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]

Hi Thierry,

On Wed, Apr 29, 2026 at 08:49:58PM +0200, Thierry Reding wrote:
> On Wed, Feb 18, 2026 at 10:42:22AM +0100, Maxime Ripard wrote:
> > 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 <treding@nvidia.com>
> > > > > 
> > > > > 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 <treding@nvidia.com>
> > > > 
> > > > 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
> 
> The CPU doesn't have access to the contents of these buffers, so
> cacheable or uncacheable aren't really meaningful, but I guess they are
> unmappable in that sense. The buffers are physically contiguous, but I
> think "protected" is the right name for the heap since it most
> accurately describes what the purpose (and access pattern) is.

Yeah, that's what panthor has been using too:
https://lore.kernel.org/r/20260505140516.1372388-1-ketil.johnsen@arm.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]