Re: [PATCH v1 2/4] drm/panthor: Add support for atomic page table updates

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 7 Nov 2025 16:26:54 +0000
Steven Price <steven.price@arm.com> 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 <boris.brezillon@collabora.com>  
> 
> +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.