On Tue, Sep 08, 2026 at 11:08:26AM +0200, Thierry Reding wrote: > On Tue, Sep 08, 2026 at 09:57:57AM +0100, Vincent Donnefort wrote: > > On Tue, Sep 08, 2026 at 10:39:17AM +0200, Thierry Reding wrote: > > > 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: > > > > > 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/[email protected] > > > > > > > > ? 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 > > > > I should be able to add PMD_SIZE mapping support to the series. That was > > actually my original idea as we can easily force the CMA allocation granule > > to > > be PMD_SIZE too. > > > > I didn't implement it as I thought there were not much interest in the end > > (and > > also as contiguous.c is always using PAGE_SIZE granularity). > > > > But now as I have implemented a specific pool (and do not use contiguous.c > > as > > originally planned), if you believe it is important for the VPR driver, let > > me > > see if I can extend the support in a V2. > > I don't think it needs to be part of a v2 and can be a follow-up. It > should be transparent from an API point of view and merely be an > optimisation for that specific case. > > Eventually it'd be nice to have, though it might also be worth checking > what the actually gains are. > > Thierry
Ack. I'll keep it as is then and we will see later how to extend it, if it is necessary. -- Vincent
