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.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel