Re: [PATCH v5 1/3] drm/shmem: add support for per object caching flags.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux