diff mbox series

i915/gem: Force HW tracking to exit PSR

Message ID 20200807115633.16328-1-gaurav.k.singh@intel.com (mailing list archive)
State New, archived
Headers show
Series i915/gem: Force HW tracking to exit PSR | expand

Commit Message

Gaurav K Singh Aug. 7, 2020, 11:56 a.m. UTC
Instead of calling i915_gem_object_invalidate_frontbuffer(),
call i915_gem_object_flush_frontbuffer() which will eventually
call psr_force_hw_tracking_exit(). This will force HW tracking
to exit PSR instead of disabling and re-enabling.

On Gen9 Intel chromebooks, while playing around with Squid software,
after drawing line, line delay was observed.Also can see flash, garbage
and even shaking display sometimes.

With this fix, issues reported were resolved on Gen9 and Gen11 Intel
chromebooks.

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Chris Wilson Aug. 7, 2020, noon UTC | #1
Quoting Gaurav K Singh (2020-08-07 12:56:33)
> Instead of calling i915_gem_object_invalidate_frontbuffer(),
> call i915_gem_object_flush_frontbuffer() which will eventually
> call psr_force_hw_tracking_exit(). This will force HW tracking
> to exit PSR instead of disabling and re-enabling.

set-domain is before the frontbuffer is dirtied. This is meant to be
followed by either sw_finish (primarily for direct CPU access to the
frontbuffer) or the more modern approach of marking the framebuffer
as dirty (DRM_IOCTL_MODE_DIRTYFB).

If you following the API, then we have a problem. But it sounds like
it could be circumventing an important step.
-Chris
Gaurav K Singh Aug. 10, 2020, 10:23 a.m. UTC | #2
-----Original Message-----
From: Chris Wilson <chris@chris-wilson.co.uk> 
Sent: Friday, August 7, 2020 5:30 PM
To: Singh, Gaurav K <gaurav.k.singh@intel.com>; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] i915/gem: Force HW tracking to exit PSR

Quoting Gaurav K Singh (2020-08-07 12:56:33)
> Instead of calling i915_gem_object_invalidate_frontbuffer(),
> call i915_gem_object_flush_frontbuffer() which will eventually call 
> psr_force_hw_tracking_exit(). This will force HW tracking to exit PSR 
> instead of disabling and re-enabling.

set-domain is before the frontbuffer is dirtied. This is meant to be followed by either sw_finish (primarily for direct CPU access to the
frontbuffer) or the more modern approach of marking the framebuffer as dirty (DRM_IOCTL_MODE_DIRTYFB).

If you following the API, then we have a problem. But it sounds like it could be circumventing an important step.
-Chris

Hi Chris,

Thanks for your comments.  I was following the API and this issue is seen on various kind of PSR1 & PSR2 panels on older Gen and as well as on new Gen with older and latest drm-tip kernel. 
With this patch, the issue was resolved on all kinds of PSR panels across platforms.  
Can you please suggest a way to do it in kernel, not sure whether I have access to Application code.

With regards,
Gaurav
diff mbox series

Patch

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 7f76fc68f498..fb1daddde286 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -553,7 +553,7 @@  i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 	i915_gem_object_unlock(obj);
 
 	if (write_domain)
-		i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
+		i915_gem_object_flush_frontbuffer(obj, ORIGIN_DIRTYFB);
 
 out_unpin:
 	i915_gem_object_unpin_pages(obj);