ttm vs aarch64 mappings

Christian König christian.koenig at amd.com
Mon Jun 2 11:51:20 UTC 2025


On 6/1/25 22:50, Dave Airlie wrote:
> Hey,
> 
> I've been playing a bit with nouveau on aarch64, and I noticed ttm
> translates ttm_uncached into pgprot_noncached which uses
> MT_DEVICE_nGnRnE. This is of course a device mapping which isn't
> appropriate for memory.
> 
> For main memory we should be using pgprot_dmacoherent which translates
> to MT_NORMAL_NC,
> pgprot_writecombine also translates to MT_NORMAL_NC.
> 
> Now I'm not sure anything gets this wrong right now, (except maybe
> nouveau), but I'm wondering would adding a ttm_uncached_ram caching
> type and rename ttm_uncached to ttm_uncached_device, if that would be
> a good idea?

Let me ask the other way around: Why is nouveau still using ttm_uncached with system memory?

IIRC there are only two use cases for ttm_uncached: >15year old AGP systems which for some reason can't handle write combine and MMIO BARs.

E.g. for amdgpu the doorbells and HDP remapping are mapped with ttm_uncached these days but nothing else.

> Has anyone else come across this problem with TTM on aarch64? or
> understand if I'm missing something.

If I'm not completely mistaken both pgprot_dmacoherent and pgprot_writecombine map to MT_NORMAL_NC because there is no such thing as uncached system memory without write combining on aarch64.

I mean why would you want to do this except for getting the MMIO write ordering right? Avoiding write memory barriers?

Regards,
Christian. 

> 
> Dave.



More information about the dri-devel mailing list