iris: Drop fallback GEM_MMAP_GTT if GEM_MMAP with I915_MMAP_WC fails

iris: Drop fallback GEM_MMAP_GTT if GEM_MMAP with I915_MMAP_WC fails

XXX: This is actually wrong.  The dmabuf imported case can be mapped via
GEM_MMAP_GTT if the iommu is working, according to Joonas, but GEM_MMAP
would fall over and fail.  So we would need this fallback.
ALTERNATIVELY...we would need to flag such imported dmabufs as
unmappable, and then make iris_transfer_map/unmap always do blits
instead of direct mappings.  That seems like the saner approach

We never want to use GEM_MMAP_GTT, as it does detiling maps, and iris
always wants direct maps.  There were originally two cases that this
fallback path was attempting to handle:

1. The BO was allocated from stolen memory that we can't GEM_MMAP.

   At one point, kernel patches were being proposed to use stolen
   memory for userspace buffers, but these never landed.  The kernel
   has never given us stolen memory, so we cannot hit this case.

2. Imported objects may be from memory we can't GEM_MMAP.

   For example, a DMABUF from a discrete AMD/NVIDIA GPU in a PRIME
   setup would be backed by memory that we can't GEM_MMAP.  We could
   try and mmap these directly with GEM_MMAP_GTT, but that relies on
   the IOMMU working.  We could mmap the DMABUF fd directly (but have
   never tried to do so), but there are complex rules there.  Instead,
   we now flag those imports, however, and rely on the iris_transfer_map
   code to perform staging blits on the GPU, so we never even try to
   map them directly.  So this case won't reach us here any longer.

With both of those out of the way, there is no need for a fallback.

Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10941>