Re: [Intel-gfx] [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-03 Thread Zack Rusin
> On Dec 3, 2020, at 10:12, Daniel Vetter wrote: > > On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote: >> >> >>> On Dec 2, 2020, at 11:03, Daniel Vetter wrote: >>> >>> On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > On Dec 2, 2020, at 09:27, Thomas

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check URL : https://patchwork.freedesktop.org/series/84555/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9439_full -> Patchwork_19055_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Track all timelines created using the HWSP

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915/gt: Track all timelines created using the HWSP URL : https://patchwork.freedesktop.org/series/84546/ State : success == Summary == CI Bug Log - changes from CI_DRM_9438_full -> Patchwork_19052_full

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check URL : https://patchwork.freedesktop.org/series/84555/ State : success == Summary == CI Bug Log - changes from CI_DRM_9439 -> Patchwork_19055

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check URL : https://patchwork.freedesktop.org/series/84555/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [v3,1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check URL : https://patchwork.freedesktop.org/series/84555/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0f525febc7f4 drm/i915/display/vrr: Create VRR file

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Stop sampling rc6 from inside pmu_enable (rev2)

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915: Stop sampling rc6 from inside pmu_enable (rev2) URL : https://patchwork.freedesktop.org/series/84549/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9439 -> Patchwork_19054 Summary

[Intel-gfx] [PATCH v3 7/9] drm/i915/display/vrr: Disable VRR in modeset disable path

2020-12-03 Thread Manasi Navare
This patch disables the VRR enable and VRR PUSH bits in the HW during commit modeset disable sequence. Thsi disable will happen when the port is disabled or when the userspace sets VRR prop to false and requests to disable VRR. v2: * Use intel_de_rmw (Jani N) Cc: Ville Syrjälä Signed-off-by:

[Intel-gfx] [PATCH v3 5/9] drm/i915/display/vrr: Configure and enable VRR in modeset enable

2020-12-03 Thread Manasi Navare
This patch computes the VRR parameters from VRR crtc states and configures them in VRR registers during CRTC enable in the modeset enable sequence. v2: * Remove initialization to 0 (Jani N) * Use correct pipe %c (Jani N) Cc: Ville Syrjälä Signed-off-by: Manasi Navare ---

[Intel-gfx] [PATCH v3 3/9] drm/i915/display/dp: Compute VRR state in atomic_check

2020-12-03 Thread Manasi Navare
This forces a complete modeset if vrr drm crtc state goes from enabled to disabled and vice versa. This patch also computes vrr state variables from the mode timings and based on the vrr property set by userspace as well as hardware's vrr capability. v2: *Rebase v3: * Vmin = max (vtotal, vmin)

[Intel-gfx] [PATCH v3 6/9] drm/i915/display/vrr: Send VRR push to flip the frame

2020-12-03 Thread Manasi Navare
VRR achieves vblank stretching using the HW PUSH functionality. So once the VRR is enabled during modeset then for each flip request from userspace, in the atomic tail pipe_update_end() we need to set the VRR push bit in HW for it to terminate the vblank at configured flipline or anytime after

[Intel-gfx] [PATCH v3 2/9] drm/i915/display/dp: Attach and set drm connector VRR property

2020-12-03 Thread Manasi Navare
From: Aditya Swarup This function sets the VRR property for connector based on the platform support, EDID monitor range and DP sink DPCD capability of outputing video without msa timing information. v8: * Use HAS_VRR, remove drm_conn declaration (Jani N) * Fix typos in Comment (Jani N) v7: *

[Intel-gfx] [PATCH v3 9/9] drm/i915/display: Add HW state readout for VRR

2020-12-03 Thread Manasi Navare
This functions gets the VRR config from the VRR registers to match the crtc state variables for VRR. v2: * Rebase (Manasi) * Use HAS_VRR (Jani N) Cc: Jani Nikula Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ drivers/gpu/drm/i915/display/intel_vrr.c

[Intel-gfx] [PATCH v3 1/9] drm/i915/display/vrr: Create VRR file and add VRR capability check

2020-12-03 Thread Manasi Navare
We create a new file for all VRR related helpers. Also add a function to check vrr capability based on platform support, DPCD bits and EDID monitor range. v2: * Remove author (Jani N) * Define HAS_VRR (Jani N) * Ensure intel_dp can be obtained from conn (Jani N) Cc: Ville Syrjälä Cc: Jani

[Intel-gfx] [PATCH v3 4/9] drm/i915/display/dp: Do not enable PSR if VRR is enabled

2020-12-03 Thread Manasi Navare
Even though our HW supports PSR + VRR, the available panels do not work reliably with PSR and VRR together. So if user requested VRR and is supported by HW enable that and do not enable PSR in that case. Cc: Ville Syrjälä Cc: Gwan-gyeong Mun Cc: Imre Deak Signed-off-by: Manasi Navare ---

[Intel-gfx] [PATCH v3 8/9] drm/i915/display/vrr: Set IGNORE_MSA_PAR state in DP Sink

2020-12-03 Thread Manasi Navare
If VRR is enabled, the sink should ignore MSA parameters and regenerate incoming video stream without depending on these parameters. Hence set the MSA_TIMING_PAR_IGNORE_EN bit if VRR is enabled. Reset this bit on VRR disable. Cc: Ville Syrjälä Cc: Jani Nikula Signed-off-by: Manasi Navare ---

Re: [Intel-gfx] [PATCH v1] vfio/pci: Add support for opregion v2.0+

2020-12-03 Thread Alex Williamson
On Thu, 3 Dec 2020 09:21:03 + "Gao, Fred" wrote: > Thanks Alex for the timely review. > > > -Original Message- > > From: Alex Williamson > > Sent: Thursday, December 3, 2020 2:57 AM > > To: Gao, Fred > > Cc: k...@vger.kernel.org; intel-gfx@lists.freedesktop.org; Zhenyu Wang > > ;

[Intel-gfx] [PATCH] drm/i915: Stop sampling rc6 from inside pmu_enable

2020-12-03 Thread Chris Wilson
Since rc6 is sampling the device registers, we try to acquire the device wakeref. However, since i915_pmu_enable may be called from hardirq, we cannot actually wake the device up and so much find another way to calibrate the rc6 bias. Having thought of no ideal solution, let's just always record

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop sampling rc6 from inside pmu_enable

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915: Stop sampling rc6 from inside pmu_enable URL : https://patchwork.freedesktop.org/series/84549/ State : success == Summary == CI Bug Log - changes from CI_DRM_9438 -> Patchwork_19053 Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Track all timelines created using the HWSP

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915/gt: Track all timelines created using the HWSP URL : https://patchwork.freedesktop.org/series/84546/ State : success == Summary == CI Bug Log - changes from CI_DRM_9438 -> Patchwork_19052 Summary

Re: [Intel-gfx] [PATCH] drm/i915: Stop sampling rc6 from inside pmu_enable

2020-12-03 Thread Chris Wilson
Quoting Chris Wilson (2020-12-03 22:38:49) > Since rc6 is sampling the device registers, we try to acquire the device > wakeref. However, since i915_pmu_enable may be called from hardirq, we > cannot actually wake the device up. So let's not, and hope our gt wake > tracking is accurate.

[Intel-gfx] [PATCH] drm/i915: Stop sampling rc6 from inside pmu_enable

2020-12-03 Thread Chris Wilson
Since rc6 is sampling the device registers, we try to acquire the device wakeref. However, since i915_pmu_enable may be called from hardirq, we cannot actually wake the device up. So let's not, and hope our gt wake tracking is accurate. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin ---

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Deprecate I915_PMU_LAST and optimize state tracking

2020-12-03 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-11-26 16:47:03) > From: Tvrtko Ursulin > > Adding any kinds of "last" abi markers is usually a mistake which I > repeated when implementing the PMU because it felt convenient at the time. > > This patch marks I915_PMU_LAST as deprecated and stops the internal >

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Try to fix encoder possible_clones/crtc (rev4)

2020-12-03 Thread Patchwork
== Series Details == Series: drm: Try to fix encoder possible_clones/crtc (rev4) URL : https://patchwork.freedesktop.org/series/63399/ State : failure == Summary == Applying: drm: Include the encoder itself in possible_clones Using index info to reconstruct a base tree... M

[Intel-gfx] [PATCH] drm/i915/gt: Track all timelines created using the HWSP

2020-12-03 Thread Chris Wilson
We assume that the contents of the HWSP are lost across suspend, and so upon resume we must restore critical values such as the timeline seqno. Keep track of every timeline allocated that uses the HWSP as its storage and so we can then reset all seqno values by walking that list. Signed-off-by:

Re: [Intel-gfx] [PATCH v3 6/7] drm: Validate encoder->possible_crtcs

2020-12-03 Thread Alex Deucher
On Tue, Sep 29, 2020 at 4:04 PM Alex Deucher wrote: > > On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka wrote: > > > > On 10.09.20 20:18, Deucher, Alexander wrote: > > > [AMD Public Use] > > > > > > > > > > > >> -Original Message- > > >> From: amd-gfx On Behalf Of > > >> Daniel Vetter > > >>

Re: [Intel-gfx] [PATCH 08/11] drm/i915/display/vrr: Send VRR push to flip the frame

2020-12-03 Thread Navare, Manasi
Actually one of the opens I had here was regarding the min and max calculation in intel_pipe_update_start aroudn teh vblank evasion code. Currently we have: min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, VBLANK_EVASION_TIME_US);

Re: [Intel-gfx] [PATCH 02/11] drm/i915/display/vrr: Create VRR file and add VRR capability check

2020-12-03 Thread Navare, Manasi
On Thu, Dec 03, 2020 at 06:35:29PM +0200, Jani Nikula wrote: > On Wed, 02 Dec 2020, "Navare, Manasi" wrote: > > On Tue, Dec 01, 2020 at 02:21:56PM -0800, Navare, Manasi wrote: > >> On Tue, Nov 10, 2020 at 12:39:08PM +0200, Jani Nikula wrote: > >> > > +{ > >> > > + struct intel_dp *intel_dp =

Re: [Intel-gfx] [PATCH 03/11] drm/i915/display/dp: Attach and set drm connector VRR property

2020-12-03 Thread Navare, Manasi
On Thu, Dec 03, 2020 at 06:37:46PM +0200, Jani Nikula wrote: > On Tue, 01 Dec 2020, "Navare, Manasi" wrote: > > On Tue, Nov 10, 2020 at 12:41:07PM +0200, Jani Nikula wrote: > >> On Thu, 22 Oct 2020, Manasi Navare wrote: > >> > + > >> > +if (INTEL_GEN(dev_priv) >= 12) > >> > >> I wonder

Re: [Intel-gfx] [PATCH 05/11] drm/i915/display/dp: Compute VRR state in atomic_check

2020-12-03 Thread Navare, Manasi
On Thu, Dec 03, 2020 at 06:39:43PM +0200, Jani Nikula wrote: > On Wed, 02 Dec 2020, "Navare, Manasi" wrote: > > On Tue, Dec 01, 2020 at 02:52:59PM -0800, Navare, Manasi wrote: > >> On Tue, Nov 10, 2020 at 12:47:46PM +0200, Jani Nikula wrote: > >> > On Thu, 22 Oct 2020, Manasi Navare wrote: > >>

Re: [Intel-gfx] [PATCH 10/11] drm/i915/display/vrr: Set IGNORE_MSA_PAR state in DP Sink

2020-12-03 Thread Navare, Manasi
On Thu, Dec 03, 2020 at 06:49:27PM +0200, Jani Nikula wrote: > On Tue, 01 Dec 2020, "Navare, Manasi" wrote: > > @Jani could you review this as well? > > Okay, I'm going to cop out here and say that, while I don't see anything > wrong here, I also didn't go through all the specs and verify this

Re: [Intel-gfx] [PATCH 10/11] drm/i915/display/vrr: Set IGNORE_MSA_PAR state in DP Sink

2020-12-03 Thread Jani Nikula
On Tue, 01 Dec 2020, "Navare, Manasi" wrote: > @Jani could you review this as well? Okay, I'm going to cop out here and say that, while I don't see anything wrong here, I also didn't go through all the specs and verify this is the right place to do this stuff. Let's see the updated version

Re: [Intel-gfx] [PATCH 07/11] drm/i915/display/vrr: Configure and enable VRR in modeset enable

2020-12-03 Thread Jani Nikula
On Tue, 01 Dec 2020, "Navare, Manasi" wrote: > On Tue, Nov 10, 2020 at 12:56:40PM +0200, Jani Nikula wrote: >> On Thu, 22 Oct 2020, Manasi Navare wrote: >> > + /* Programming adjustments for 0 based regs */ >> > + trans_vrr_vmax = crtc_state->vrr.vtotalmax - 1; >> > + trans_vrr_vmin =

Re: [Intel-gfx] [PATCH 05/11] drm/i915/display/dp: Compute VRR state in atomic_check

2020-12-03 Thread Jani Nikula
On Wed, 02 Dec 2020, "Navare, Manasi" wrote: > On Tue, Dec 01, 2020 at 02:52:59PM -0800, Navare, Manasi wrote: >> On Tue, Nov 10, 2020 at 12:47:46PM +0200, Jani Nikula wrote: >> > On Thu, 22 Oct 2020, Manasi Navare wrote: >> > > @@ -15202,7 +15206,8 @@ static int intel_atomic_check(struct

Re: [Intel-gfx] [PATCH 03/11] drm/i915/display/dp: Attach and set drm connector VRR property

2020-12-03 Thread Jani Nikula
On Tue, 01 Dec 2020, "Navare, Manasi" wrote: > On Tue, Nov 10, 2020 at 12:41:07PM +0200, Jani Nikula wrote: >> On Thu, 22 Oct 2020, Manasi Navare wrote: >> > + >> > + if (INTEL_GEN(dev_priv) >= 12) >> >> I wonder if we should just add a wrapper >> >> #define HAS_VRR(i915) (INTEL_GEN(i915) >=

Re: [Intel-gfx] [PATCH 02/11] drm/i915/display/vrr: Create VRR file and add VRR capability check

2020-12-03 Thread Jani Nikula
On Wed, 02 Dec 2020, "Navare, Manasi" wrote: > On Tue, Dec 01, 2020 at 02:21:56PM -0800, Navare, Manasi wrote: >> On Tue, Nov 10, 2020 at 12:39:08PM +0200, Jani Nikula wrote: >> > > +{ >> > > +struct intel_dp *intel_dp = >> > > intel_attached_dp(to_intel_connector(connector)); >> > >> >

Re: [Intel-gfx] [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-03 Thread Daniel Vetter
On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: > >>> > >>> Hi > >>> > >>> Am 02.12.20 um

Re: [Intel-gfx] [PATCH] drm/i915/dp: No need to poll FEC Enable Live bit

2020-12-03 Thread Nautiyal, Ankit K
On 11/25/2020 12:56 PM, Manasi Navare wrote: The Bspec does not mention polling the FEC Enable Live status bit. That is only there for debug purposes. So remove the polling from driver. Cc: Ankit Nautiyal Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/display/intel_ddi.c | 6 --

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Check the correct variable

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915: Check the correct variable URL : https://patchwork.freedesktop.org/series/84534/ State : failure == Summary == Applying: drm/i915: Check the correct variable Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/selftests/i915_gem.c

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset

2020-12-03 Thread Chris Wilson
Quoting Chris Wilson (2020-12-03 08:16:13) > Before reseting the engine, we suspend the execution of the guilty > request, so that we can continue execution with a new context while we > slowly compress the captured error state for the guilty context. However, > if the reset fails, we will

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset

2020-12-03 Thread Chris Wilson
Quoting Chris Wilson (2020-12-03 08:16:13) > Before reseting the engine, we suspend the execution of the guilty > request, so that we can continue execution with a new context while we > slowly compress the captured error state for the guilty context. However, > if the reset fails, we will

[Intel-gfx] [PULL] drm-intel-fixes v2

2020-12-03 Thread Rodrigo Vivi
Hi Dave and Daniel, Please ignore the pull request I had sent yesterday and use only this one. I had missed one patch: 14d1eaf08845 ("drm/i915/gt: Protect context lifetime with RCU"). Also, please notice that the commit 6db58901c2aa ("drm/i915/display: return earlier from

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add the missing wakeref tracking for display power references (rev3)

2020-12-03 Thread Imre Deak
On Thu, Dec 03, 2020 at 10:44:12AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add the missing wakeref tracking for display power > references (rev3) > URL : https://patchwork.freedesktop.org/series/84418/ > State : success Pushed to -dinq, thanks for the review. >

[Intel-gfx] [PATCH] drm/i915: Check the correct variable

2020-12-03 Thread Dan Carpenter
There is a copy and paste bug in this code. It's supposed to check "obj2" instead of checking "obj" a second time. Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.") Signed-off-by: Dan Carpenter --- drivers/gpu/drm/i915/selftests/i915_gem.c | 4 ++-- 1

Re: [Intel-gfx] [PATCH] drm/i915: Check the correct variable

2020-12-03 Thread Chris Wilson
Quoting Andi Shyti (2020-12-03 11:12:24) > Hi Dan, > > > There is a copy and paste bug in this code. It's supposed to check > > "obj2" instead of checking "obj" a second time. > > > > Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx > > locking, v2.") > >

[Intel-gfx] [PULL] drm-misc-fixes

2020-12-03 Thread Maxime Ripard
Hi Daniel, Dave, Here's this week round of fixes for drm-misc Thanks! Maxime drm-misc-fixes-2020-12-03: One bridge fix for OMAP, one for a race condition in a panel, two for uninitialized variables in rockchip and nouveau, and two fixes for mxsfb to fix a regression with modifiers and a fix for

Re: [Intel-gfx] [PATCH v3] drm/i915/display: Record the plane update times for debugging

2020-12-03 Thread Chris Wilson
Quoting Ville Syrjälä (2020-12-03 12:45:43) > On Wed, Dec 02, 2020 at 09:28:09PM +, Chris Wilson wrote: > > Since we try and estimate how long we require to update the registers to > > perform a plane update, it is of vital importance that we measure the > > distribution of plane updates to

Re: [Intel-gfx] [PATCH v3] drm/i915/display: Record the plane update times for debugging

2020-12-03 Thread Ville Syrjälä
On Wed, Dec 02, 2020 at 09:28:09PM +, Chris Wilson wrote: > Since we try and estimate how long we require to update the registers to > perform a plane update, it is of vital importance that we measure the > distribution of plane updates to better guide our estimate. If we > underestimate how

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Propagate error from cancelled submit due to context closure

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915/gem: Propagate error from cancelled submit due to context closure URL : https://patchwork.freedesktop.org/series/84531/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9432 -> Patchwork_19049

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Propagate error from cancelled submit due to context closure

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915/gem: Propagate error from cancelled submit due to context closure URL : https://patchwork.freedesktop.org/series/84531/ State : warning == Summary == $ dim checkpatch origin/drm-tip a6642ebaca9a drm/i915/gem: Propagate error from cancelled submit due to

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset URL : https://patchwork.freedesktop.org/series/84526/ State : success == Summary == CI Bug Log - changes from CI_DRM_9430_full -> Patchwork_19048_full

Re: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe protection

2020-12-03 Thread Chris Wilson
Quoting Surendrakumar Upadhyay, TejaskumarX (2020-12-03 04:13:57) > Hi Jaswant, > > Can you please re-run resume run on CI as well as local setup and share > results here? If it passes in full resume run in either of setup we are good > go with. Acknowledge the bug as a critical failure [it

Re: [Intel-gfx] [PATCH] drm/i915: Check the correct variable

2020-12-03 Thread Andi Shyti
Hi Dan, > There is a copy and paste bug in this code. It's supposed to check > "obj2" instead of checking "obj" a second time. > > Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx > locking, v2.") > Signed-off-by: Dan Carpenter > --- >

Re: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe protection

2020-12-03 Thread Surendrakumar Upadhyay, TejaskumarX
+ Jaswant > -Original Message- > From: Surendrakumar Upadhyay, TejaskumarX > Sent: 03 December 2020 09:44 > To: Chris Wilson ; Pandey, Hariom > ; intel-gfx@lists.freedesktop.org > Subject: RE: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe > protection > > Hi Jaswant, > >

Re: [Intel-gfx] [PATCH i-g-t] i915/api_intel_bb: Only assert objects are unmoved for full-ppgtt

2020-12-03 Thread Chris Wilson
Quoting Zbigniew Kempczyński (2020-12-03 10:34:23) > On Thu, Dec 03, 2020 at 08:39:31AM +, Chris Wilson wrote: > > If we let an object idle in a shared GTT, it may be evicted by the > > kernel in favour of another client. Thus, we have to be very careful > > when asserting that two different

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add the missing wakeref tracking for display power references (rev3)

2020-12-03 Thread Patchwork
== Series Details == Series: drm/i915: Add the missing wakeref tracking for display power references (rev3) URL : https://patchwork.freedesktop.org/series/84418/ State : success == Summary == CI Bug Log - changes from CI_DRM_9415_full -> Patchwork_19027_full

[Intel-gfx] [PATCH] drm/i915/gem: Propagate error from cancelled submit due to context closure

2020-12-03 Thread Chris Wilson
In the course of discovering and closing many races with context closure and execbuf submission, since commit 61231f6bd056 ("drm/i915/gem: Check that the context wasn't closed during setup") we started checking that the context was not closed by another userspace thread during the execbuf ioctl.

Re: [Intel-gfx] [PATCH i-g-t] i915/api_intel_bb: Only assert objects are unmoved for full-ppgtt

2020-12-03 Thread Zbigniew Kempczyński
On Thu, Dec 03, 2020 at 08:39:31AM +, Chris Wilson wrote: > If we let an object idle in a shared GTT, it may be evicted by the > kernel in favour of another client. Thus, we have to be very careful > when asserting that two different executions of the same object will > be at the same address.

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [v2,1/2] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping URL : https://patchwork.freedesktop.org/series/84518/ State : success == Summary == CI Bug Log - changes from CI_DRM_9430_full -> Patchwork_19047_full

Re: [Intel-gfx] [PATCH] drm/i915: Check the correct variable

2020-12-03 Thread Chris Wilson
Quoting Dan Carpenter (2020-12-03 08:45:17) > There is a copy and paste bug in this code. It's supposed to check > "obj2" instead of checking "obj" a second time. > > Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx > locking, v2.") > Signed-off-by: Dan Carpenter > ---

[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it

2020-12-03 Thread Chris Wilson
Race the execution and interrupt handlers along a context, while closing it at a random time. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- tests/i915/gem_ctx_exec.c | 60 +++ 1 file changed, 60 insertions(+) diff --git a/tests/i915/gem_ctx_exec.c

[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it

2020-12-03 Thread Chris Wilson
Race the execution and interrupt handlers along a context, while closing it at a random time. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- tests/i915/gem_ctx_exec.c | 59 +++ 1 file changed, 59 insertions(+) diff --git a/tests/i915/gem_ctx_exec.c

Re: [Intel-gfx] [PATCH v1] vfio/pci: Add support for opregion v2.0+

2020-12-03 Thread Gao, Fred
Thanks Alex for the timely review. > -Original Message- > From: Alex Williamson > Sent: Thursday, December 3, 2020 2:57 AM > To: Gao, Fred > Cc: k...@vger.kernel.org; intel-gfx@lists.freedesktop.org; Zhenyu Wang > ; Fonn, Swee Yee > Subject: Re: [PATCH v1] vfio/pci: Add support for

Re: [Intel-gfx] [PATCH] drm/i915: refactor panel backlight control functions. (v2)

2020-12-03 Thread Jani Nikula
On Tue, 01 Dec 2020, Dave Airlie wrote: > From: Dave Airlie > > This moves the functions into static const instead of having > funcs and data in the same struct. > > It leaves the power callback alone, as it is used in a different > manner. > > v2: leave power callback alone (Jani) > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset URL : https://patchwork.freedesktop.org/series/84526/ State : success == Summary == CI Bug Log - changes from CI_DRM_9430 -> Patchwork_19048

[Intel-gfx] [PATCH i-g-t] i915/api_intel_bb: Only assert objects are unmoved for full-ppgtt

2020-12-03 Thread Chris Wilson
If we let an object idle in a shared GTT, it may be evicted by the kernel in favour of another client. Thus, we have to be very careful when asserting that two different executions of the same object will be at the same address. If there's an idle point between the two asserts, it will only be

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset URL : https://patchwork.freedesktop.org/series/84526/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used,

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset URL : https://patchwork.freedesktop.org/series/84526/ State : warning == Summary == $ dim checkpatch origin/drm-tip dacd9017014a drm/i915/gt: Ignore repeated

[Intel-gfx] [PATCH 4/4] drm/i915/gt: Clear the execlists timers upon reset

2020-12-03 Thread Chris Wilson
Across a reset, we stop the engine but not the timers. This leaves a window where the timers have inconsistent state with the engine, but should only result in a spurious timeout. As we cancel the outstanding events, also cancel their timers. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 3/4] drm/i915/gt: Include reset failures in the trace

2020-12-03 Thread Chris Wilson
The GT and engine reset failures are completely invisible when looking at a trace for a bug, but are vital to understanding the incomplete flow. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_reset.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-)

[Intel-gfx] [PATCH 2/4] drm/i915/gt: Cancel the preemption timeout on responding to it

2020-12-03 Thread Chris Wilson
We currently presume that the engine reset is successful, cancelling the expired preemption timer in the process. However, engine resets can fail, leaving the timeout still pending and we will then respond to the timeout again next time the tasklet fires. What we want is for the failed engine

[Intel-gfx] [PATCH 1/4] drm/i915/gt: Ignore repeated attempts to suspend request flow across reset

2020-12-03 Thread Chris Wilson
Before reseting the engine, we suspend the execution of the guilty request, so that we can continue execution with a new context while we slowly compress the captured error state for the guilty context. However, if the reset fails, we will promptly attempt to reset the same request again, and

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping

2020-12-03 Thread Patchwork
== Series Details == Series: series starting with [v2,1/2] drm/i915/tgl: Fix REVID macros for TGL to fetch correct stepping URL : https://patchwork.freedesktop.org/series/84518/ State : success == Summary == CI Bug Log - changes from CI_DRM_9430 -> Patchwork_19047