drm/i915: fbdev_set_par reliably invalidating frontbuffer

fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind and broken in

commit 031b698a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jun 26 19:35:16 2015 +0200

    drm/i915: Unconditionally do fb tracking invalidate in set_domain

Note that even before this commit it wasn't perfect since the
invalidate was omitted if the fbcon was already in the GTT domain,
which it usually was.

Since we are also invalidating in other fbdev cases this one
was masked here. At least until now that I found this corner
case: On boot with plymouth doing a splash screen
when returning to the console frontbuffer wans't being invalidated
causing missed screen updates with PSR enabled.

So this patch fixes this issue.

v2: Make invalidate directly and unconditionally and
    fix commit message indicating the set_domain fix
    as pointed out by Daniel.
v3: Remove unecessary if(obj) added by mistake

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Try to clarify commit message a bit and make it clear the
referenced commit made this worse.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drivers/gpu/drm/i915/intel_fbdev.c

@@ -63,8 +63,7 @@ static int intel_fbdev_set_par(struct fb_info *info)
 		 * now until we solve this for real.
 		 */
 		mutex_lock(&fb_helper->dev->struct_mutex);
-		ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj,
-							true);
+		intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
 		mutex_unlock(&fb_helper->dev->struct_mutex);
 	}