On 2/27/20 11:56 AM, Gerd Hoffmann wrote:
Hi,I think it might be safe for some integrated graphics where the driver maintainers can guarantee that it's safe on all particular processors used with that driver, but then IMO it should be moved out to those drivers. Other drivers needing write-combine shouldn't really use shmem. So again, to fix the regression, could we revert 0be895893607f ("drm/shmem: switch shmem helper to &drm_gem_object_funcs.mmap") or does that have other implications?This patch isn't a regression. The old code path has the pgprot_writecombine() call in drm_gem_mmap_obj(), so the behavior is the same before and afterwards.
OK. I wasn't checking where this all came from from the start...
But with the patch in place we can easily have shmem helpers do their own thing instead of depending on whatever drm_gem_mmap_obj() is doing. Just using cached mappings unconditionally would be perfectly fine for virtio-gpu. Not sure about the other users though. I'd like to fix the virtio-gpu regression (coming from ttm -> shmem switch) asap, and I don't feel like changing the behavior for other drivers in 5.6-rc is a good idea. So I'd like to push patches 1+2 to -fixes and sort everything else later in -next. OK?
OK with me. Do we have any idea what drivers are actually using write-combine and decrypted?
/Thomas
cheers, Gerd
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
