On Wed, May 13, 2020 at 06:13:17AM +, Ashwin H wrote:
> This patch fixes CVE-2018-20669 in 4.19 tree.
Ok, but what does that mean for us?
You need to say why you are sending a patch, otherwise we will guess
wrong.
greg k-h
___
Intel-gfx mailing lis
== Series Details ==
Series: series starting with [v5,1/3] drm/dp: DRM DP helper for reading Ignore
MSA from DPCD
URL : https://patchwork.freedesktop.org/series/77204/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8471 -> Patchwork_17638
==
On Wed, May 13, 2020 at 07:19:21AM +0530, ashwin-h wrote:
> From: Linus Torvalds
>
> commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 upstream.
>
> Originally, the rule used to be that you'd have to do access_ok()
> separately, and then user_access_begin() before actually doing the
> direct (opti
On Tue, May 12, 2020 at 10:10 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-05-12 12:12 p.m., Daniel Vetter wrote:
> > On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote:
> >>
> >> On Tue, May 12, 2020 at 9:45 AM Daniel Vetter
> >> wrote:
> >>>
> >>> On Tue, May 12, 2020 at 3:29 PM Alex Deucher
== Series Details ==
Series: series starting with [v5,1/3] drm/dp: DRM DP helper for reading Ignore
MSA from DPCD
URL : https://patchwork.freedesktop.org/series/77204/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f6ad5ff374c2 drm/dp: DRM DP helper for reading Ignore MSA from
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate t
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "i915_vrr_info".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/i915_vrr_info
v5:
* Rename to vrr_range to ma
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.
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect
On Tue, May 12, 2020 at 10:30:31AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 5/1/20 9:57 PM, Matt Roper wrote:
> > Reads of multicast registers give the value associated with
> > slice/subslice 0 by default unless we manually steer the reads to a
> > different slice/subslice. If slice/subsli
On Tue, 2020-05-12 at 20:54 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/ehl: Restrict w/a 1607087056 for EHL/JSL
> URL : https://patchwork.freedesktop.org/series/77199/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8470_full -> Patchwork_17636
On 5/1/20 9:57 PM, Matt Roper wrote:
The multicast register ranges are slightly different for gen11 and gen12
than the table we have for gen8. This information never got updated in
the bspec, so this patch is based on a spreadsheet provided by the
hardware team while they work on getting the
On Tue, 2020-05-12 at 11:00 -0700, Swathi Dhanavanthri wrote:
> This w/a is fixed in B0 stepping and needs to be restricted for
> A0 stepping only.
> Bspec: 33451
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Swathi Dhanavanthri
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 11
== Series Details ==
Series: drm/i915/ehl: Restrict w/a 1607087056 for EHL/JSL
URL : https://patchwork.freedesktop.org/series/77199/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470_full -> Patchwork_17636_full
Summary
--
On Tue, May 12, 2020 at 06:32:38PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 04:26:53PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 04:14:33PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 1
== Series Details ==
Series: drm/i915: DP vswing/preemph fixes
URL : https://patchwork.freedesktop.org/series/77198/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470_full -> Patchwork_17635_full
Summary
---
**SUCCE
On 2020-05-12 12:12 p.m., Daniel Vetter wrote:
On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
On Tue, May 12, 2020 at 3:12
== Series Details ==
Series: drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker (rev3)
URL : https://patchwork.freedesktop.org/series/77191/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8470 -> Patchwork_17637
Sum
== Series Details ==
Series: drm/i915/ehl: Restrict w/a 1607087056 for EHL/JSL
URL : https://patchwork.freedesktop.org/series/77199/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470 -> Patchwork_17636
Summary
---
*
== Series Details ==
Series: drm/i915/ehl: Restrict w/a 1607087056 for EHL/JSL
URL : https://patchwork.freedesktop.org/series/77199/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d26f548aa0bd drm/i915/ehl: Restrict w/a 1607087056 for EHL/JSL
-:44: CHECK:MACRO_ARG_REUSE: Macro a
== Series Details ==
Series: drm/i915: DP vswing/preemph fixes
URL : https://patchwork.freedesktop.org/series/77198/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470 -> Patchwork_17635
Summary
---
**SUCCESS**
No
On Tue, May 12, 2020 at 7:31 PM Christian König
wrote:
>
> Ah!
>
> So we can't allocate memory while scheduling anything because it could
> be that memory reclaim is waiting for the scheduler to finish pushing
> things to the hardware, right?
Yup, that's my understanding. But like with all things
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the
This w/a is fixed in B0 stepping and needs to be restricted for
A0 stepping only.
Bspec: 33451
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 11 +++
drivers/gpu/drm/i915/i915_drv.h | 5 +
2 files changed, 12 insertions(+), 4 deletio
From: Ville Syrjälä
Different platforms have different max vswing/preemph settings.
Turn that into a pair vfuncs so we can decouple intel_dp.c and
intel_ddi.c further.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 21 ++
drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
IBX supports vswing level 3 and pre-emphasis level 3. Don't
limit it to level 2 for those.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.
From: Ville Syrjälä
The DP spec says:
"When the combination of the requested pre-emphasis level and
voltage swing exceeds the capability of a DPTX, the DPTX shall
set the pre-emphasis level according to the request and use the
highest voltage swing it can output with the given pre-emphasis lev
From: Ville Syrjälä
cpt/ppt support pre-emphasis level 3. Let's actually declare
support for it, instead of clamping things to level 2.
Also tweak the if-ladder in intel_dp_voltage_max() to match
intel_dp_pre_emphasis_max() to make it easier to compare them.
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
These vswing/preemph fixes were previously posted as part of
the link training crtc_state plumbing series, but since
that potentially had some odd behaviour in ci I'm sending
these separately. Hopefully nothing odd pops up with just these...
Ville Syrjälä (7):
drm/i915: Fix
From: Ville Syrjälä
The DP spec says:
"The transmitter shall support at least three levels of voltage
swing (Levels 0, 1, and 2).
If only three levels of voltage swing are supported (VOLTAGE
SWING SET field (bits 1:0) are programmed to 10 (Level 2)),
this bit shall be set to 1, and cleared i
From: Ville Syrjälä
According to the DP spec supporting vswing 1 + preemph 2 is
mandatory. We don't have the hw settings for that though. In
order to pretend to follow the DP spec let's just select
vswing 0 + preemph 2 in this case (the DP spec says to use
the requested preemph in preference to t
From: Ville Syrjälä
Use max() instead of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm
== Series Details ==
Series: drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker (rev2)
URL : https://patchwork.freedesktop.org/series/77191/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8470 -> Patchwork_17634
Sum
Ah!
So we can't allocate memory while scheduling anything because it could
be that memory reclaim is waiting for the scheduler to finish pushing
things to the hardware, right?
Indeed a nice problem, haven't noticed that one.
Christian.
Am 12.05.20 um 18:27 schrieb Daniel Vetter:
On Tue, Ma
On 5/1/20 9:57 PM, Matt Roper wrote:
Reads of multicast registers give the value associated with
slice/subslice 0 by default unless we manually steer the reads to a
different slice/subslice. If slice/subslice 0 are fused off in hardware,
performing unsteered reads of multicast registers will
== Series Details ==
Series: drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker
URL : https://patchwork.freedesktop.org/series/77191/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470_full -> Patchwork_17633_full
Our 'headless' subtest requires fairly precise measurements to determine
the impact of the dmc upon request latency. The test cannot be effective
if we cannot execute requests quickly, so add a very short pre-pass to
check the test requirements. For this we want to specify the baseline
measurement
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the
On Tue, May 12, 2020 at 6:20 PM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 5:56 PM Christian König
> wrote:
> >
> > Hui what? Of hand that doesn't looks correct to me.
>
> It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we
> have to avoid direct reclaim. And direct reclai
After triggering the reset, we would ping the engines with a no-op. But
we already validate the reset, so this would seem superfluous.
Signed-off-by: Chris Wilson
---
tests/i915/gem_eio.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
i
On Tue, May 12, 2020 at 5:56 PM Christian König
wrote:
>
> Hui what? Of hand that doesn't looks correct to me.
It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we
have to avoid direct reclaim. And direct reclaim might need to call
into your mmu notifier, which might need to wait
An obscure and very dated subtest, it's even covered by the other
subtests -- if the kernel still worked in any fashion assumed by the
test.
Signed-off-by: Chris Wilson
---
tests/i915/i915_pm_rpm.c | 12
1 file changed, 12 deletions(-)
diff --git a/tests/i915/i915_pm_rpm.c b/tests/
Quoting Tvrtko Ursulin (2020-05-12 17:07:23)
>
> On 12/05/2020 16:52, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-12 16:17:30)
> >>
> >> On 12/05/2020 14:22, Chris Wilson wrote:
> >>> - spin_lock(&old->breadcrumbs.irq_lock);
> >>> - if (!list_empty(&ve->context.signal_link)) {
Last user removed, remove the definition of gem_test_engine().
Signed-off-by: Chris Wilson
---
lib/i915/gem_submission.c | 49 ---
lib/i915/gem_submission.h | 2 --
2 files changed, 51 deletions(-)
diff --git a/lib/i915/gem_submission.c b/lib/i915/gem_submis
On Tue, 2020-05-12 at 06:17 +, Lee, Shawn C wrote:
> On Thu, May 11, 2020, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 06:46:17PM -0400, Lyude Paul wrote:
> > > On Thu, 2020-04-30 at 02:37 +, Lee, Shawn C wrote:
> > > > On Sat, 2020-04-25, Lyude Paul wrote:
> > > > > Hi! Sorry this too
On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter
> > > wrote:
> > > >
> > > > On Tue, May 12, 2020 at 3:12 PM Alex D
Quoting Janusz Krzysztofik (2020-05-12 15:07:36)
> Some tests may need to take care of closing all device file descriptors
> even on subtest failure. For example, if a test would like to
> effectively unload the driver module after a subtest failure, that
> wouldn't be possible if any device file
On 12/05/2020 16:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-12 16:17:30)
On 12/05/2020 14:22, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcru
On Thu, May 07, 2020 at 05:45:02PM +0300, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
>
> Currently we are just comparing against all of
> those and take minimum(worst case)
Hui what? Of hand that doesn't looks correct to me.
Why the heck should this be an atomic context? If that's correct
allocating memory is the least of the problems we have.
Regards,
Christian.
Am 12.05.20 um 10:59 schrieb Daniel Vetter:
My dma-fence lockdep annotations caught an inversion be
Quoting Tvrtko Ursulin (2020-05-12 16:17:30)
>
> On 12/05/2020 14:22, Chris Wilson wrote:
> > The second try at staging the transfer of the breadcrumb. In part one,
> > we realised we could not simply move to the second engine as we were
> > only holding the breadcrumb lock on the first. So in com
On Tue, May 12, 2020 at 04:26:53PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:14:33PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > > > On Thu, May 0
On 12/05/2020 14:22, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the
On Tue, May 12, 2020 at 06:04:45PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 05:32:21PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 04:59:19PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 05:32:21PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 04:59:19PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 04:59:19PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
> >
> > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter
> > wrote:
> > >
> > > On Tue, May 12, 2020 at 3:12 PM Alex Deucher
> > > wrote:
> > > >
> > > > On Tue, May 12, 2020 at 8:58 AM D
Daniele Ceraolo Spurio writes:
> On 5/7/20 7:20 AM, Mika Kuoppala wrote:
>> All engines, exception being blitter as it does not
>> care about the form, can access compressed surfaces.
>>
>> So we need to add forced aux table invalidates
>> for those engines.
>>
>> v2: virtual instance masking (
== Series Details ==
Series: drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker
URL : https://patchwork.freedesktop.org/series/77191/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470 -> Patchwork_17633
Summary
--
Some tests may need to take care of closing all device file descriptors
even on subtest failure. For example, if a test would like to
effectively unload the driver module after a subtest failure, that
wouldn't be possible if any device file descriptors were kept open.
That may happen if the subtes
On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, May 12, 2020 at 08:54:45AM -0400, Ale
On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> > > > On Thu, May 0
On Tue, May 12, 2020 at 04:14:33PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > > > Seems that onl
On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
> >
> > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> > >
> > > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > > > On Tue, May 12, 2020 at 5:00 AM Daniel Vette
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the
On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> > > > Starting from
On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter
> > > wrote:
> > > >
> > > > ...
> > > >
> > > > I think it's ti
On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > > Seems that only skl needs to have SAGV turned off
> > > for multipipe scenarios, so l
On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter
> > wrote:
> > >
> > > ...
> > >
> > > I think it's time to stop this little exercise.
> > >
> > > The lockdep splat, for the r
On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> > > Starting from TGL we need to have a separate wm0
> > > values for SAGV and non-SAGV w
On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > > Seems that only skl needs to have SAGV turned off
> > > for multipipe scenarios, so l
On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote:
> >
> > ...
> >
> > I think it's time to stop this little exercise.
> >
> > The lockdep splat, for the record:
> >
> > [ 132.583381] ===
On Tue, May 12, 2020 at 09:09:52AM -0300, Jason Gunthorpe wrote:
> On Tue, May 12, 2020 at 10:59:29AM +0200, Daniel Vetter wrote:
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 6802125349fb..d5c0fd2efc70 100644
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -110,
On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> > Starting from TGL we need to have a separate wm0
> > values for SAGV and non-SAGV which affects
> > how calculations are done.
> >
> > v2: Remove long lines
> >
On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote:
>
> ...
>
> I think it's time to stop this little exercise.
>
> The lockdep splat, for the record:
>
> [ 132.583381] ==
> [ 132.584091] WARNING: possible circular locking dependency detected
On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > Seems that only skl needs to have SAGV turned off
> > for multipipe scenarios, so lets do it this way.
>
> It doesn't afaics. It's just someone added the check
On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> Starting from TGL we need to have a separate wm0
> values for SAGV and non-SAGV which affects
> how calculations are done.
>
> v2: Remove long lines
> v3: Removed COLOR_PLANE enum references
> v4, v5, v6: Fixed rebase conflict
On Thu, May 07, 2020 at 05:44:59PM +0300, Stanislav Lisovskiy wrote:
> Introduce platform dependent SAGV checking in
> combination with bandwidth state pipe SAGV mask.
>
> This is preparation to adding TGL support, which
> requires different way of SAGV checking.
>
> v2, v3, v4, v5, v6: Fix rebas
On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> Seems that only skl needs to have SAGV turned off
> for multipipe scenarios, so lets do it this way.
It doesn't afaics. It's just someone added the check for some random
reason. So this should be reworded a bit. Also this isn't
On Thu, May 07, 2020 at 05:44:58PM +0300, Stanislav Lisovskiy wrote:
> For future Gen12 SAGV implementation we need to
> seemlessly alter wm levels calculated, depending
> on whether we are allowed to enable SAGV or not.
>
> So this accessor will give additional flexibility
> to do that.
>
> Curr
Checked on skl+ before sending, older platforms now failing because of ddb_size
== 0 warn..
Need to fix for older platforms as well..
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From:
Quoting Mika Kuoppala (2020-05-12 11:39:31)
> Chris Wilson writes:
>
> > i915_gem_evict_something() is charged with finding a slot within the GTT
> > that we may reuse. Since our goal is not to stall, we first look for a
> > slot that only overlaps idle vma. To this end, on the first pass we move
Chris Wilson writes:
> i915_gem_evict_something() is charged with finding a slot within the GTT
> that we may reuse. Since our goal is not to stall, we first look for a
> slot that only overlaps idle vma. To this end, on the first pass we move
> any active vma to the end of the search list. Howev
Quoting Tvrtko Ursulin (2020-05-12 11:12:23)
>
> On 12/05/2020 09:49, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-12 09:41:01)
> >> On 11/05/2020 08:57, Chris Wilson wrote:
> >>> The second try at staging the transfer of the breadcrumb. In part one,
> >>> we realised we could not simpl
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev11)
URL : https://patchwork.freedesktop.org/series/74739/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8467 -> Patchwork_17632
Summary
---
On 12/05/2020 09:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-12 09:41:01)
On 11/05/2020 08:57, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrum
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev11)
URL : https://patchwork.freedesktop.org/series/74739/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d3cd77d67aae drm/i915: Decouple cdclk calculation from modeset checks
65be6d7302db drm/i915: E
Hi,
This includes support for ppgtt update by LRI command which gvt
replaces by shadow ppgtt, another small optimization for shadow
ctx and one workload destroy cleanup.
Thanks
--
The following changes since commit fb55c735522352704c35d899d0b253453cf0e799:
drm/i915/gvt: skip populate shadow
== Series Details ==
Series: dma-fence lockdep annotations
URL : https://patchwork.freedesktop.org/series/77178/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8467 -> Patchwork_17631
Summary
---
**FAILURE**
Seriou
== Series Details ==
Series: dma-fence lockdep annotations
URL : https://patchwork.freedesktop.org/series/77178/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: dma-fence: add might_sleep annotation to _wait()
Okay!
Commit: dma-fence: basic lockdep ann
== Series Details ==
Series: dma-fence lockdep annotations
URL : https://patchwork.freedesktop.org/series/77178/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
761b03bd55bc dma-fence: add might_sleep annotation to _wait()
-:39: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by:
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
Quoting Daniel Vetter (2020-05-12 10:08:47)
> On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-05-12 09:59:29)
> > > Design is similar to the lockdep annotations for workers, but with
> > > some twists:
> > >
> > > - We use a read-lock for the execution
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-12 09:59:29)
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> > this explicit ann
Am 12.05.20 um 10:59 schrieb Daniel Vetter:
But only for non-zero timeout, to avoid false positives.
One question here is whether the might_sleep should be unconditional,
or only for real timeouts. I'm not sure, so went with the more
defensive option. But in the interest of locking down the cros
Quoting Daniel Vetter (2020-05-12 09:59:29)
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lockde
Quoting Daniel Vetter (2020-05-12 09:59:28)
> But only for non-zero timeout, to avoid false positives.
>
> One question here is whether the might_sleep should be unconditional,
> or only for real timeouts. I'm not sure, so went with the more
> defensive option. But in the interest of locking down
1 - 100 of 121 matches
Mail list logo
