Am 17.09.20 um 16:44 schrieb Michel Dänzer:
On 2020-09-17 2:20 p.m., Christian König wrote:
Hi guys,
Michel once submitted a patch to fix triggering this BUG_ON in
ttm_tt_swapout():
BUG_ON(ttm->caching_state != tt_cached);
Now my question is does anybody know why we have that in the first
place?
The only problematic thing I can see is calling copy_highpage() and
that one is just doing a kmap_atomic()/kunmap_atomic() on the source
and destination.
I can't see why it should be problematic for this temporary mapping
to be cached instead of uncached or WC?
Does anybody has any idea?
One thing is that AFAIK some (ARM?) CPUs can get very upset when
there's both a cached and uncacheable mapping for the same physical page.
Good point, but I already considered this.
If there is another mapping for that page left we are completely busted
anyway since we are currently changing the underlying storage.
In other words nobody else should have a mapping because we are about to
copy and then free up the memory.
Any other idea? It is the only place where we actually have to change
the caching attributes.
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
