[Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved

[Thomas Hellström (VMware)]

On 8/21/19 4:10 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
> <thomas_os at shipmail.org> wrote:
>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
>>> With nouveau fixed all ttm-using drives have the correct nesting of
>>> mmap_sem vs dma_resv, and we can just lock the buffer.
>>>
>>> Assuming I didn't screw up anything with my audit of course.
>>>
>>> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
>>> Cc: Christian Koenig <christian.koenig at amd.com>
>>> Cc: Huang Rui <ray.huang at amd.com>
>>> Cc: Gerd Hoffmann <kraxel at redhat.com>
>>> Cc: "VMware Graphics" <linux-graphics-maintainer at vmware.com>
>>> Cc: Thomas Hellstrom <thellstrom at vmware.com>
>>> ---
>>>    drivers/gpu/drm/ttm/ttm_bo.c    | 34 ---------------------------------
>>>    drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>>>    include/drm/ttm/ttm_bo_api.h    |  1 -
>>>    3 files changed, 1 insertion(+), 60 deletions(-)
>>>
>>>
>>> +     dma_resv_lock(bo->base.resv, NULL);
>> interruptible, or at least killable. (IIRC think killable is the right
>> choice in fault code, even if TTM initially implemented interruptible to
>> get reasonable Xorg "silken mouse" latency).
> I think interruptible is fine. I chickend out of that for v1 because I
> always mix up the return code for _lock_interruptibl() :-)

:). IIRC I think the in-kernel users of fault() were unhappy with 
interruptible.  (GUP?), but I guess it's better to use a bulk change at 
some point if necessary.

/Thomas

> I'll add that for the next version too.
> -Daniel