> 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
== 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
== 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
== 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
== 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
== 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
== 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
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:
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
---
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)
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
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:
*
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
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
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
---
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
---
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
> > ;
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
== 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
---
== 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
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.
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
---
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
>
== 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
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:
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
> > >>
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);
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 =
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
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:
> >>
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
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
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 =
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
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) >=
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));
>> >
>> >
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
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 --
== 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
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
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
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
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.
>
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
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.")
> >
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
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
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
== 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
== 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
== 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
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
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
> ---
>
+ 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,
>
>
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
== 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
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.
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.
== 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
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
> ---
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
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
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
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)
>
>
== 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
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
== 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,
== 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
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
---
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(-)
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
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
== 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
73 matches
Mail list logo