kernel/linux.git/drivers/gpu/drm/i915/intel_frontbuffer.c, branch linux-4.20.y

drm/i915/psr: Nuke PSR support for VLV and CHV

2018-05-24T13:05:19+00:00

PSR hardware and hence the driver code for VLV and CHV deviates a lot from their DDI counterparts. While the feature has been disabled for a long time now, retaining support for these platforms is a maintenance burden. There have been multiple refactoring commits to just keep the existing code for these platforms in line with the rest. There are known issues that need to be fixed to enable PSR on these platforms, and there is no PSR capable platform in CI to ensure the code does not break again if we get around to fixing the existing issues. On account of all these reasons, let's nuke this code for now and bring it back if a need arises in the future. Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Ville Syrjälä Acked-by: Jani Nikula Acked-by: Rodrigo Vivi Reviewed-by: José Roberto de Souza Signed-off-by: Dhinakaran Pandiyan Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20180511230059.19387-1-dhinakaran.pandiyan@intel.com

drm/i915/psr: Use more PSR HW tracking.

2018-03-13T20:50:22+00:00

So far we are using frontbuffer tracking for everything and ignoring that PSR has a HW capable HW tracking for many modern usages of GPU on Core platforms and newer Atom ones. One reason for that is that we were trying to keep same infrastructure in place for VLV/CHV than the rest of platforms. But also because when this infrastructure was created the front-buffer-tracking origin wasn't that good and stable how it is today after Paulo reworked it to attend FBC cases. However this PSR implementation without HW tracking died on gen8LP. And newer platforms are starting to demand more HW tracking specially with PSR2 cases in mind. By disabling and re-enabling PSR totally every time we believe someone is going to change the front buffer content we don't allow PSR HW tracking to do this job and specially compromising the whole idea of PSR2 case where the HW tracking detect only the damaged area and do a partial screen update. So, from now on, on the platforms that has hw_tracking let's rely more on HW tracking. This also is the case in used by other drivers and more validated by SV teams. So I hope that this will lead us to less misterious bugs. v2: Only do this for platform that actually has hw tracking. v3 from DK Do this only for flips, small gradual changes are better. Cc: Dhinakaran Pandiyan Cc: Jim Bride Cc: Vathsala Nagaraju Signed-off-by: Rodrigo Vivi Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Jose Roberto de Souza Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20180307033420.3086-3-dhinakaran.pandiyan@intel.com

drm/i915/frontbuffer: Mark frontbuffer flush and invalidate with might_sleep()

2018-02-27T20:06:07+00:00

Frontbuffer flush and invalidate call psr, fbc and drrs functions that use mutexes but they can be called in atomic contexts in the fbdev path. The point where the spinlocks are acquired is up in the call stack that is not entirely easy to spot, so annotate with might_sleep(). Cc: Rodrigo Vivi Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20180223221520.18464-2-dhinakaran.pandiyan@intel.com

drm/i915: Remove 'retire' parameter from intel_fb_obj_flush

2017-02-22T12:12:17+00:00

Setting retire=true is identical to using origin=ORIGIN_CS, so make the same simplification to intel_fb_obj_flush() as already employed for intel_fb_obj_invalidate(). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/20170222114049.28456-6-chris@chris-wilson.co.uk

drm/i915: Use dev_priv consistently through the intel_frontbuffer interface

2016-08-04T19:20:03+00:00

Rather than a mismash of struct drm_device *dev and struct drm_i915_private *dev_priv being used freely within a function, be consistent and only pass along dev_priv. Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Reviewed-by: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/1470324762-2545-22-git-send-email-chris@chris-wilson.co.uk

drm/i915: Use atomics to manipulate obj->frontbuffer_bits

2016-08-04T19:20:03+00:00

The individual bits inside obj->frontbuffer_bits are protected by each plane->mutex, but the whole bitfield may be accessed by multiple KMS operations simultaneously and so the RMW need to be under atomics. However, for updating the single field we do not need to mandate that it be under the struct_mutex, one more step towards its removal as the de facto BKL. Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/1470324762-2545-21-git-send-email-chris@chris-wilson.co.uk

drm/i915: Make fb_tracking.lock a spinlock

2016-08-04T19:20:02+00:00

We only need a very lightweight mechanism here as the locking is only used for co-ordinating a bitfield. v2: Move the cheap unlikely tests into the caller v3: Move the kerneldoc into the header (now separated out into intel_fronbuffer.h for better kerneldoc and readability) Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtien Cc: Daniel Vetter Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470324762-2545-20-git-send-email-chris@chris-wilson.co.uk

drm/i915: Separate intel_frontbuffer into its own header

2016-08-04T19:20:01+00:00

In view of adding inline functions into the intel_frontbuffer section, we first split the header into its own file so that we can integrate it more easily with kerneldoc. Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470324762-2545-19-git-send-email-chris@chris-wilson.co.uk

drm/i915: fix FBC frontbuffer tracking flushing code

2015-08-05T07:59:44+00:00

Due to the way busy_bits was handled, we were not doing any flushes if we didn't previously get an invalidate. Since it's possible to get flushes without an invalidate first, remove the busy_bits early return. So now that we don't have the busy_bits guard anymore we'll need the origin check for the GTT tracking (we were not doing anything on GTT flushes due to the GTT check at invalidate()). As a last detail, since we can get multiple consecutive flushes, disable FBC before updating it, otherwise intel_fbc_update() will just keep FBC enabled instead of restarting it. Notice that this does not fix any of the current IGT tests due to the fact that we still have a few intel_fbc() calls at points where we also have the frontbuffer tracking calls: we didn't fully convert to frontbuffer tracking yet. Once we remove those calls and start relying only on the frontbuffer tracking infrastructure we'll need this patch. Signed-off-by: Paulo Zanoni Reviewed-by: Rodrigo Vivi Signed-off-by: Daniel Vetter

drm/i915: fix intel_frontbuffer_flip documentation

2015-07-09T17:17:53+00:00

Reported by the kbuild test robot. Regression introduced by: commit fdbff9282c0f5f61ffc87d57461b04d943250910 Author: Daniel Vetter Date: Thu Jun 18 11:23:24 2015 +0200 drm/i915: Clear fb_tracking.busy_bits also for synchronous flips (I reviewed this commit, so it's also my fault) Signed-off-by: Paulo Zanoni Signed-off-by: Daniel Vetter