Re: [PATCH v12 12/15] drm/panfrost: Skip cache flush/invalidate when enabling perfcnt

[Steven Price <steven.price@arm.com>]

On 06/10/2026 18:35, Adrián Larumbe wrote:
> On 2026-10-05 17:05:14+01:00, Steven Price wrote:
>> On 05/10/2026 16:37, Boris Brezillon wrote:
>>
>>> On Mon, 5 Oct 2026 16:06:02 +0100
>>> Steven Price <steven.price@arm.com> wrote:
>>>
>>>
>>> Hm, I'd say it's actually impossible because every unmap operation is
>>> followed by a flush+inval of the GPU L2 and LSC, so for this stale
>>> clean line to exist on the GPU side when a physical page is GPU-mapped
>>> again, it would take a bug in the unmap logic or in the MMU HW, I
>>> think. Am I missing something?
>>
>> Ah, yes that's true :) Although there's no need for us to do an
>> invalidate on the unmap path...
> 
> Does that mean the panfrost_mmu_flush_range() we do at the end of panfrost_mmu_unmap()
> is unnecessary? Is it because, as you said in a previous message, cache lines for
> BOs referenced in a CS are always invalidates before anything else is executed?

Sorry, I wasn't very clear on the wording here - we don't need an
*invalidate* but we do need a *clean*. Midgard/Bifrost hardware doesn't
really give us much control over cache operations - we tend to just
clean everything and blow away the cache (because the GPU's caches are
"small" it's not worth the complexity).

> If we keep the invalidate at the end of the mmu path, then there would be no need
> to mention that all counters being enabled is the ultimate reason why no initial
> flush/invalidate is needed in the perfcnt enable path.

Yes I think relying on all counters being enabled is a bad design. We
can justify the change based on the existing flushes/invalidates we're
doing.

>>>>
>>>
>>> I suppose speculation pre-populating the caches with stale data would be
>>> covered by the flush+inval we do after a map operation (this is
>>> currently done in the unlock path regardless of the VM op, so both map
>>> and unmap get it). I don't know, maybe the goal is to relax the flushing
>>> policy around VM modifications in the future, but if things stay as
>>> they are now, we can assume that a fresh BO being GPU-mapped guarantees
>>> that no cacheline points to it until the first GPU access. But maybe
>>> I'm missing something else...
>>
>> I have to admit I'm coming from experience on CPUs - there speculation
>> means a CPU can load a cache line at basically any point. So the
>> argument that a line cannot be in a cache almost never holds. GPUs (at
>> least Mali GPUs) haven't quite got to the stage of CPUs.
>>
>> Thanks,
>> Steve
> 
>