On Fri, 7 Nov 2025 16:26:54 +0000 Steven Price <[email protected]> wrote:
> On 31/10/2025 15:48, Boris Brezillon wrote: > > Move the lock/flush_mem operations around the gpuvm_sm_[un]map() calls > > so we can implement true atomic page updates, where any access in the > > locked range done by the GPU has to wait for the page table updates > > to land before proceeding. > > > > This is needed for vkQueueBindSparse(), so we can replace the dummy > > page mapped over the entire object by actual BO backed pages in an atomic > > way. But it's also useful to avoid "AS_ACTIVE bit stuck" failures in > > the sm_[un]map() path, leading to gpuvm state inconsistencies. > > > > Signed-off-by: Boris Brezillon <[email protected]> > > +CC: Karunika > > The concept here looks good, but... > > This is effectively undoing the changes that Karunika did in commit > dd11c7dec74b ("drm/panthor: Make MMU cache maintenance use FLUSH_CACHES > command"). The FLUSH_MEM/FLUSH_PT commands have been deprecated in > Mali-Gx20, so either this needs refactoring to use the newer > FLUSH_CACHES GPU_COMMAND. > > I believe the expected ideal approach on later GPUs is: > > 1. LOCK > 2. Make page table updates > 3. FLUSH_RANGE to GPU_COMMAND flushing the *physical* address ranges > 4. UNLOCK > > Note that on earlier GPUs we don't have FLUSH_RANGE so FLUSH_CACHES > replaces step 3 (and is what we have upstream). But I think this is the > reason why FLUSH_MEM/FLUSH_PT are deprecated because those work on a > virtual address range. Ah, right. I'll revisit the logic to have it working on newer gens.
