On Fri, Sep 04, 2026 at 12:41:05PM +0100, Will Deacon wrote:
Hi Thierry,
On Fri, Sep 04, 2026 at 12:44:51PM +0200, Thierry Reding wrote:
quoted
This series adds support for the video protection region (VPR) used on
Tegra SoC devices. It's a special region of memory that is protected
from accesses by the CPU and used to store DRM protected content (both
decrypted stream data as well as decoded video frames).
Patches 1 through 3 add DT binding documentation for the VPR and add the
VPR to the list of memory-region items for display, host1x and NVDEC.
The set_direct_map_*_noflush() functions that will be used later in this
series are exported in patch 4 so that the drivers that use them can be
built as a module.
Patch 5 adds bitmap_allocate(), which is like bitmap_allocate_region()
but works on sizes that are not a power of two.
The of_node_to_nid() function is exported in patch 6 because it is used
in a later patch adding a driver that can be built as a module.
Patch 7 introduces new APIs needed by the Tegra VPR implementation that
allow memory to be allocated at a fixed offset within a CMA area. Tegra
VPR needs this in order to implement its own allocator on top of CMA to
meet the strict hardware requirements. This replaces the dynamic CMA
area creation patch from earlier versions.
Did you get a chance to see how this could work with Vincent's series:
https://lore.kernel.org/r/20260902104712.2399797-1-vdonnefort@google.com (local)
? I think that should remove your reliance on can_set_direct_map() and
mean that you can retain block mappings for most of the linear mapping.
I'm not sure if it would help all that much. Yes, if we mark the VPR
region as LLMAP (or PTE_MAP, whichever it ends up being), it should make
the checks for can_set_direct_map() redundant. However, from what I can
tell, Vincent's series still forces page-granularity on these regions,
so it won't retain block mappings at all for them.
The block mappings can be retained for the non-VPR memory, so that's
nice. It also reduces the amount of external prerequisites, but I had
kind of hoped that we could go one step further and keep block mappings
even for the VPR memory if the region happened to be a multiple of the
block size.
The recent addition of page count to the set_direct_map_*() functions
helps reduce the amount of checks that need to be run, so maybe there's
not too much to be gained from removing whole block mappings at once
from the linear map.
Thierry