buggy/weird behavior in ttm

[Maarten Lankhorst]

I was trying to clean ttm up a little so my changes would be less invasive, and simplify
the code for debuggability. During testing I noticed the following weirdnesses:
- ttm_mem_evict_first ignores no_wait_gpu if the buffer is on the ddestroy list.
  If you follow the code, it will effectively spin in ttm_mem_evict_first if a bo
  is on the list and no_wait_gpu is true.
This makes it very hard to change this function around to something more sane, what is the
desired effect? Could this perhaps be changed to something more sane?

I was working on a commit that removes fence_lock since I was killing off the
fence lock, but that requires some kind of defined behavior for this. Unless
we leave this in place as expected behavior..

- no_wait_reserve is ignored if no_wait_gpu is false
  ttm_bo_reserve_locked can only return true if no_wait_reserve is true, but
  subsequently it will do a wait_unreserved if no_wait_gpu is false.
I'm planning on removing this argument and act like it is always true, since
nothing on the lru list should fail to reserve currently.

- effectively unlimited callchain between some functions that all go through
  ttm_mem_evict_first:

                                    /------------------------\
ttm_mem_evict_first - ttm_bo_evict -                          -ttm_bo_mem_space  - ttm_bo_mem_force_space - ttm_mem_evict_first
                                    \ ttm_bo_handle_move_mem /
I'm not surprised that there was a deadlock before, it seems to me it would
be pretty suicidal to ever do a blocking reserve on any of those lists,
lockdep would be all over you for this.

Also it seems ttm_bo_move_ttm, ttm_bo_move_memcpy and ttm_bo_move_accel_cleanup
don't use some of their arguments, so could those be dropped?

~Maarten