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