Quoting Patchwork (2020-01-29 02:56:00)
> * igt@i915_selftest@live_execlists:
> - fi-skl-lmem:[PASS][1] -> [DMESG-FAIL][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7833/fi-skl-lmem/igt@i915_selftest@live_execlists.html
>[2]:
> https://intel-gfx-ci.01.org/tree/
On Mon, Jan 27, 2020 at 01:14:37PM +0100, Thomas Hellström (VMware) wrote:
> On 1/27/20 11:02 AM, Daniel Vetter wrote:
> > vmwgfx stopped using them.
> >
> > With the drm device model that we've slowly evolved over the past few
> > years master status essentially controls access to display resourc
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, January 28, 2020 9:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Kulkarni, Vandita
> ; Ville Syrjala
> Subject: [PATCH 1/3] drm/i915: move pipe, pch and vblank enable to encoders
> on DDI platforms
>
> To allow
Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz
and 593.4/594Mhz. Add the missing rates and add logic to ignore
them if running on older hardware.
Bspec: 49333
Signed-off-by: Kai Vehmanen
---
drivers/gpu/drm/i915/display/intel_audio.c | 14 +++---
drivers/gpu/drm/i915/i91
We want to only take the BKL on crap drivers, but to know whether
we have a crap driver we first need to look it up. Split this shuffle
out from the main BKL-disabling patch, for more clarity.
Since the minors are refcounted drm_minor_acquire is purely internal
and this does not have a driver visi
Instead check for master status, in case we've raced.
This is the last exception to the general rule that we restore fbcon
only when there's no master active. Compositors are supposed to drop
their master status before they switch to a different console back to
text mode (or just switch to text mo
Kinda time to get this sorted. The locking around this really is not
nice.
Thomas mentioned in his review that the only drivers left unconverted
are radeon and amdgpu.
Cc: Harry Wentland
Cc: Alex Deucher
Reviewed-by: Chris Wilson
Reviewed-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
--
Hi all
New version without the deadlock in pan_display that Noralf spotted
(hopefully that appeases CI a bit, v1 was bad), plus now being co-tested
with the right igt series (hopefully).
Review (especially but not only on the igt side) very much appreciated.
Test-With: 20200128112549.172135-1-da
This catches the majority of drivers (unfortunately not if we take
users into account, because all the big drivers have at least a
lastclose hook).
With the prep patches out of the way all drm state is fully protected
and either prevents or can deal with the races from dropping the BKL
around open
Plus extend the kerneldoc a bit to explain how this should be used.
With the previous patch to drop the force restore the main user of
this function is not emphasis on the "I hold the internal master lock
already" aspect, so rename the function to match.
Suggested by Noralf.
Cc: Noralf Trønnes
S
On Fri, 24 Jan 2020 at 00:00, Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> nouveau over.
>
> v4:
> * add argument names in function declaration
>
> Signed-off-by
On Fri, 24 Jan 2020 at 00:00, Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert nouvean over.
>
> v4:
> * add argument names in function declaration
>
> Signed-off-by: Thomas Zimmermann
Revie
On Tue, 28 Jan 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2020-01-28 13:48:10)
>> On Tue, 28 Jan 2020, Tvrtko Ursulin wrote:
>> >> -DRM_DEBUG(
>> >> +drm_dbg(&T->drm,
>> >
>> > This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe
>> > becomes much more spammy.
>>
>> This
On Tue, 2020-01-28 at 19:35 +0200, Ville Syrjälä wrote:
> On Fri, Jan 24, 2020 at 10:44:52AM +0200, Stanislav Lisovskiy wrote:
> > Now start using parameterized DBUF_CTL instead
> > of hardcoded, this would allow shorter access
> > functions when reading or storing entire state.
> >
> > Tried to i
On Tue, 2020-01-28 at 15:15 -0800, Matt Roper wrote:
> On Fri, Jan 24, 2020 at 10:44:54AM +0200, Stanislav Lisovskiy wrote:
> > Added proper DBuf slice mapping to correspondent
> > pipes, depending on pipe configuration as stated
> > in BSpec.
> >
> > v2:
> > - Remove unneeded braces
> > -
On Tue, 2020-01-28 at 15:33 -0800, Matt Roper wrote:
> On Fri, Jan 24, 2020 at 10:44:55AM +0200, Stanislav Lisovskiy wrote:
> > Now using power_domain mutex to protect from race condition, which
> > can occur because intel_dbuf_slices_update might be running in
> > parallel to gen9_dc_off_power_wel
On Tue, 28 Jan 2020, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/display: mass conversion to intel_de_*() register accessors
> (rev2)
> URL : https://patchwork.freedesktop.org/series/72533/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7827_full -> Pa
Chris Wilson writes:
> We write to execlists->pending[0] in process_csb() to acknowledge the
> completion of the ESLP update, outside of the main spinlock. When we
> check the current status of the previous submission in
> __execlists_submission_tasklet() we should therefore use READ_ONCE() to
>
Measure the memcpy bw between our CPU accessible regions, trying all
supported mapping combinations(WC, WB) across various sizes.
v2:
use smaller sizes
throw in memcpy32/memcpy64/memcpy_from_wc
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.
Quoting Mika Kuoppala (2020-01-29 09:29:43)
> Chris Wilson writes:
>
> > We write to execlists->pending[0] in process_csb() to acknowledge the
> > completion of the ESLP update, outside of the main spinlock. When we
> > check the current status of the previous submission in
> > __execlists_submis
Quoting Matthew Auld (2020-01-29 09:33:43)
> Measure the memcpy bw between our CPU accessible regions, trying all
> supported mapping combinations(WC, WB) across various sizes.
>
> v2:
> use smaller sizes
> throw in memcpy32/memcpy64/memcpy_from_wc
>
> Signed-off-by: Matthew Auld
> Cc: C
On Tue, Jan 28, 2020 at 12:28:35PM -0800, Manasi Navare wrote:
> On Tue, Jan 28, 2020 at 07:30:59PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 28, 2020 at 07:05:38PM +0200, Ville Syrjälä wrote:
> > > On Fri, Jan 17, 2020 at 04:16:28AM -0500, Matt Atwood wrote:
> > > > On Tiger Lake we do not suppo
On Tue, Jan 28, 2020 at 03:52:41PM -0800, José Roberto de Souza wrote:
> From: Radhakrishna Sripada
>
> dgfx platforms do not support CPU fence and FBC host tracking so
> lets avoid write to removed registers.
>
> Cc: Rodrigo Vivi
> Cc: Matt Roper
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Ra
On Tue, Jan 28, 2020 at 03:52:40PM -0800, José Roberto de Souza wrote:
> dGFX have local memory so it do not have aperture and do not support
> CPU fences but even for iGFX it have a small number of fences.
>
> As replacement for fences to track frontbuffer modifications by CPU
> we have a softwar
On Wed, Jan 29, 2020 at 08:41:34AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2020-01-28 at 19:35 +0200, Ville Syrjälä wrote:
> > On Fri, Jan 24, 2020 at 10:44:52AM +0200, Stanislav Lisovskiy wrote:
> > > Now start using parameterized DBUF_CTL instead
> > > of hardcoded, this would allow shorter
On Fri, Jan 17, 2020 at 05:05:51PM +0200, Jani Nikula wrote:
> We've long had the more generic /dev/drm_dp_auxN devices for the same
> purpose. Drop the redundant and limited DPCD debugfs file.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_debugfs
On Wed, Jan 29, 2020 at 01:44:49PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 28, 2020 at 03:52:40PM -0800, José Roberto de Souza wrote:
> > dGFX have local memory so it do not have aperture and do not support
> > CPU fences but even for iGFX it have a small number of fences.
> >
> > As replacement
On Wed, 29 Jan 2020, Ville Syrjälä wrote:
> On Fri, Jan 17, 2020 at 05:05:51PM +0200, Jani Nikula wrote:
>> We've long had the more generic /dev/drm_dp_auxN devices for the same
>> purpose. Drop the redundant and limited DPCD debugfs file.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville
Update the local var e after iterating to the next engine when searching
for the next non-virtual engine. Otherwise, it is prone to loop forever.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Petri Latvala
---
lib/i915/gem_engine_topology.c | 6 ++
1 file changed, 2 in
Hi Chris,
On Wed, Jan 29, 2020 at 12:16:02PM +, Chris Wilson wrote:
> Update the local var e after iterating to the next engine when searching
> for the next non-virtual engine. Otherwise, it is prone to loop forever.
Do I remember correctly that you sent this once already?
In any case,
Rev
Quoting Andi Shyti (2020-01-29 12:35:38)
> Hi Chris,
>
> On Wed, Jan 29, 2020 at 12:16:02PM +, Chris Wilson wrote:
> > Update the local var e after iterating to the next engine when searching
> > for the next non-virtual engine. Otherwise, it is prone to loop forever.
>
> Do I remember correc
== Series Details ==
Series: drm/i915: Add missing HDMI audio pixel clocks for gen12 (rev2)
URL : https://patchwork.freedesktop.org/series/72617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7835 -> Patchwork_16310
Summary
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-01-29 09:29:43)
>> Chris Wilson writes:
>>
>> > We write to execlists->pending[0] in process_csb() to acknowledge the
>> > completion of the ESLP update, outside of the main spinlock. When we
>> > check the current status of the previous submis
Chris Wilson writes:
> We write to execlists->pending[0] in process_csb() to acknowledge the
> completion of the ESLP update, outside of the main spinlock. When we
> check the current status of the previous submission in
> __execlists_submission_tasklet() we should therefore use READ_ONCE() to
>
Den 29.01.2020 09.24, skrev Daniel Vetter:
> Plus extend the kerneldoc a bit to explain how this should be used.
> With the previous patch to drop the force restore the main user of
> this function is not emphasis on the "I hold the internal master lock
The _not_ confuses me, the emphasis is now
To avoid context corruption on some gens, we need to hold forcewake
for long periods of time. This leads to increased energy expenditure
for mostly idle workloads.
To combat the increased power consumption, park GPU more hastily.
As the HW isn't so quick to end up in rc6, this software mechanism
As Gen12 onwards there are HDCP instances for each transcoder
instead of port, remove the (port < PORT_E) hdcp support
limitation for platform >= Gen12.
v2:
- Nuke the comment and cosmetic changes. [Jani]
Cc: Jani Nikula
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915
Quoting Mika Kuoppala (2020-01-29 13:39:12)
> To avoid context corruption on some gens, we need to hold forcewake
> for long periods of time. This leads to increased energy expenditure
> for mostly idle workloads.
>
> To combat the increased power consumption, park GPU more hastily.
>
> As the HW
On 2020-01-28 at 18:38:03 +0200, Jani Nikula wrote:
> The DDI encoder code shouln't have to know about the guts of
> HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in
> intel_hdcp.c. No functional changes.
>
> Cc: Anshuman Gupta
> Signed-off-by: Jani Nikula
> ---
> driver
On Wed, 29 Jan 2020, Jani Nikula wrote:
> On Tue, 28 Jan 2020, Chris Wilson wrote:
>> Quoting Jani Nikula (2020-01-28 13:48:10)
>>> On Tue, 28 Jan 2020, Tvrtko Ursulin wrote:
>>> >> -DRM_DEBUG(
>>> >> +drm_dbg(&T->drm,
>>> >
>>> > This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debu
On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The linetime watermarks really have very little in common with the
> plane watermarks. It looks to be cleaner to simply track them in
> the crtc_state and program them from the normal modeset/fastset
> paths.
>
> T
On Wed, Jan 29, 2020 at 2:16 PM Noralf Trønnes wrote:
> Den 29.01.2020 09.24, skrev Daniel Vetter:
> > Plus extend the kerneldoc a bit to explain how this should be used.
> > With the previous patch to drop the force restore the main user of
> > this function is not emphasis on the "I hold the int
Chris Wilson writes:
> They haven't been effective for a long time; so drop them.
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
> benchmarks/gem_exec_reloc.c | 19 +-
> lib/igt_debugfs.c| 59
> lib/igt_debugfs.h| 7 -
>
On Wed, 29 Jan 2020, Anshuman Gupta wrote:
> On 2020-01-28 at 18:38:03 +0200, Jani Nikula wrote:
>> The DDI encoder code shouln't have to know about the guts of
>> HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in
>> intel_hdcp.c. No functional changes.
>>
>> Cc: Anshuman G
Chris Wilson writes:
> Now that we have offline error capture and can reset an engine from
> inside an atomic context while also preserving the GPU state for
> post-mortem analysis, it is time to handle error interrupts thrown by
> the command parser.
You might want to add an advertisement here
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
Hi Daniel.
On Wed, Jan 29, 2020 at 09:24:09AM +0100, Daniel Vetter wrote:
> We want to only take the BKL on crap drivers, but to know whether
The BKL was killed long time ago..
In other words I was confused until I realized that
- BKL
- drm_global_mutex BKL
- drm_global_mutex
Was all the same. At
Hi Daniel.
In the nit-pick department today - sorry.
Subject: [PATCH 5/5] drm: Nerv drm_global_mutex BKL for good drivers
I did not understand this subject... - what is "Nerv"?
Sam
On Wed, Jan 29, 2020 at 09:24:10AM +0100, Daniel Vetter wrote:
> This catches the majority of drivers (unf
Pre-allocate buffer object in atomic_check using intel_dsb_init
function which will allocate a gem object and used later to pin and
map the buffer in atomic_commit.
No chnage is dsb write/commit functions.
Now dsb get/put function is refactored and currently used only for
reference counting. Belo
When we reset the engine, we first remove the guilty request from the
active list. If it so happens that there is a pending preemption event
to process before we handle the reset, when we inspect that event we
find ourselves a little confused as we have bent the rules slightly to
perform the reset.
On Wed, Jan 29, 2020 at 05:45:45PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Wed, Jan 29, 2020 at 09:24:09AM +0100, Daniel Vetter wrote:
> > We want to only take the BKL on crap drivers, but to know whether
> The BKL was killed long time ago..
> In other words I was confused until I realized
On Wed, Jan 29, 2020 at 05:47:33PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> In the nit-pick department today - sorry.
>
> Subject: [PATCH 5/5] drm: Nerv drm_global_mutex BKL for good drivers
> I did not understand this subject... - what is "Nerv"?
It's a typo, supposed to be nerf:
https://ww
== Series Details ==
Series: disable drm_global_mutex for most drivers
URL : https://patchwork.freedesktop.org/series/72711/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4c86ec07f811 drm: Complain if drivers still use the ->load callback
-:48: WARNING:NO_AUTHOR_SIGN_OFF: Missi
== Series Details ==
Series: drm/i915/selftests/perf: measure memcpy bw between regions (rev3)
URL : https://patchwork.freedesktop.org/series/72621/
State : failure
== Summary ==
Applying: drm/i915/selftests/perf: measure memcpy bw between regions
Using index info to reconstruct a base tree...
== Series Details ==
Series: drm/i915: Park faster to alleviate kept forcewake
URL : https://patchwork.freedesktop.org/series/72721/
State : failure
== Summary ==
Applying: drm/i915: Park faster to alleviate kept forcewake
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i91
== Series Details ==
Series: disable drm_global_mutex for most drivers
URL : https://patchwork.freedesktop.org/series/72711/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7838 -> Patchwork_16311
Summary
---
**FAILURE
Quoting Daniel Vetter (2020-01-29 08:24:10)
> @@ -378,9 +409,10 @@ int drm_open(struct inode *inode, struct file *filp)
> if (IS_ERR(minor))
> return PTR_ERR(minor);
>
> - mutex_unlock(&drm_global_mutex);
> -
> dev = minor->dev;
> + if (drm_dev_needs_gl
Could be helpful for debugging purposes.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c| 8
drivers/gpu/drm/i915/i915_reg.h | 2 +
From: Ville Syrjälä
No point in having these wrappers for a simple DSB_CTRL write.
Inline them into intel_dsb_commit().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 64 +---
1 file changed, 13 insertions(+), 51 deletions(-)
diff --git a/drive
From: Ville Syrjälä
Clean up properly if we can't map the DSB buffer.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 8b35
From: Ville Syrjälä
We may want to not use the DSB even if the platform has one.
So replace the HAS_DSB check in the _put() with a cmd_buf check
that will work in either case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 3 +--
1 file changed, 1 insertion(+), 2 d
From: Ville Syrjälä
In case DSB was busy before we started it we try to disable it.
Let's try to wait for it to become idle.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
From: Ville Syrjälä
Our DSB support is borked. The DSB seems to get stuck and we just
get:
[drm:intel_dsb_commit [i915]] DSB execution started - head 0xa8c000, tail 0x10c0
[drm:intel_dsb_commit [i915]] *ERROR* Timed out waiting for DSB workload
completion.
[drm:icl_load_luts [i915]] DSB engine i
From: Ville Syrjälä
Move the DSB tail cacheline alignment to a helper. No need to pollute
the caller with mundane details like this.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git
From: Ville Syrjälä
The DSB should never be busy here or we messed up somewhere else.
Make this a DRM_ERROR().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
From: Ville Syrjälä
No point in having these drm_device variables around. Get rid of them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu
From: Ville Syrjälä
We don't want to keep random bits set in DSB_CTRL. Stop the
harmful RMW.
Also flip the reverse & around to appease my ocd.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsb.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
Quoting Ville Syrjala (2020-01-29 18:20:31)
> + intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id),
> + DSB_ENABLE);
> + intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
> + i915_ggtt_offset(dsb->vma));
> intel_de_write(dev_priv, DSB_TAIL
On Wed, Jan 29, 2020 at 06:32:04PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-01-29 18:20:31)
> > + intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id),
> > + DSB_ENABLE);
> > + intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
> > +
On Mon, Dec 09, 2019 at 03:13:13PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-12-09 15:01:37)
> > From: Ville Syrjälä
> >
> > The modparam checks performed by sna_mode_wants_tear_free() don't
> > generally work when the server is running as a regular user. Hence
> > we can't rely on
On Braswell and Broxton (also known as Valleyview and Apollolake), we
need to serialise updates of the GGTT using the big stop_machine()
hammer. This has the side effect of appearing to lockdep as a possible
reclaim (since it uses the cpuhp mutex and that is tainted by per-cpu
allocations). However
== Series Details ==
Series: drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
URL : https://patchwork.freedesktop.org/series/72724/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7838 -> Patchwork_16315
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer.
URL : https://patchwork.freedesktop.org/series/72729/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ef4f44f8827c drm/i915/dsb: Pre allocate and late cleanup of cmd buffer.
-:10: WARNING:TYPO
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer.
URL : https://patchwork.freedesktop.org/series/72729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7838 -> Patchwork_16316
Summary
---
Currently, the value assigned to the bool variable ddi_clk_needed
is a pointer -- which appears to have happened inadvertently. Therefore,
add a "!!" before the expression on the right to ensure that it results
in a bool.
Cc: Jani Nikula
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/d
Do a pass over gem_exec_reloc where we inject lots of SIGINTs.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
tests/i915/gem_exec_reloc.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index bc9
On 29/01/20 14:24, Chris Wilson wrote:
Do a pass over gem_exec_reloc where we inject lots of SIGINTs.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_exec_reloc.c | 13 +
1 file changed, 9 insertions(+), 4 dele
On some platforms such as Elkhart Lake, although we may use DDI D
to drive a connector, we have to use PHY A (Combo Phy PORT A) to
detect the hotplug interrupts as per the spec because there is no
one-to-one mapping between DDIs and PHYs. Therefore, use the
function intel_port_to_phy() which contai
Disable Inter and intra Read Suppression (bit 15) and
Early Read and Src Swap (bit 14) by setting the chicken
register.
BSpec: 46045,52890
v2: Follow the Bspec implementation for the WA.
v3: Have 2 separate defines for bit 14 and 15.
- Rename register definitions with TGL_ prefix
Cc: Matt Roper
On Braswell and Broxton (also known as Valleyview and Apollolake), we
need to serialise updates of the GGTT using the big stop_machine()
hammer. This has the side effect of appearing to lockdep as a possible
reclaim (since it uses the cpuhp mutex and that is tainted by per-cpu
allocations). However
Only the first and the last nodes were being added to
ref->preallocated_barriers.
I'm not familiar with this part of the code but if that is the
expected behavior it is leaking the nodes in between.
Renaming variables to make it more easy to read.
Fixes: 841350223816 ("drm/i915/gt: Drop mutex se
According to DP specification, DP_SINK_EVENT_NOTIFY is also a
broadcast message but as this function only handles
DP_CONNECTION_STATUS_NOTIFY I will only make the static
analyzer that caught this issue happy by not calling
drm_dp_get_mst_branch_device_by_guid() with a NULL guid, causing
drm_dp_mst_
Quoting José Roberto de Souza (2020-01-29 23:23:45)
> Only the first and the last nodes were being added to
> ref->preallocated_barriers.
>
> I'm not familiar with this part of the code but if that is the
> expected behavior it is leaking the nodes in between.
>
> Renaming variables to make it mo
Quoting José Roberto de Souza (2020-01-29 23:23:45)
> Only the first and the last nodes were being added to
> ref->preallocated_barriers.
>
> I'm not familiar with this part of the code but if that is the
> expected behavior it is leaking the nodes in between.
Fortunately only used with a maximum
On Wed, 2020-01-29 at 23:33 +, Chris Wilson wrote:
> Quoting José Roberto de Souza (2020-01-29 23:23:45)
> > Only the first and the last nodes were being added to
> > ref->preallocated_barriers.
> >
> > I'm not familiar with this part of the code but if that is the
> > expected behavior it is
== Series Details ==
Series: drm/i915/execlists: Ignore discrepancies in pending[] across resets
URL : https://patchwork.freedesktop.org/series/72730/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e031d39b424a drm/i915/execlists: Ignore discrepancies in pending[] across resets
Quoting Souza, Jose (2020-01-29 23:53:21)
> On Wed, 2020-01-29 at 23:33 +, Chris Wilson wrote:
> > Quoting José Roberto de Souza (2020-01-29 23:23:45)
> > > Only the first and the last nodes were being added to
> > > ref->preallocated_barriers.
> > >
> > > I'm not familiar with this part of th
The workarounds are a common "feature" across gens and submission
mechanisms and we already call the other WA related functions from
common engine ones (_common), so it makes sense to
do the same with WA application. Medium-term, This will help us
reduce the duplication once the GuC resume function
Now that intel_engine_apply_workarounds is called on all gens, we can
use the engine workaround lists for pre-gen8 workarounds as well to be
consistent in the way we handle and dump the WAs.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/intel
Quoting Daniele Ceraolo Spurio (2020-01-29 23:58:59)
> The workarounds are a common "feature" across gens and submission
> mechanisms and we already call the other WA related functions from
> common engine ones (_common), so it makes sense to
> do the same with WA application. Medium-term, This wil
Quoting Daniele Ceraolo Spurio (2020-01-29 23:59:00)
> Now that intel_engine_apply_workarounds is called on all gens, we can
> use the engine workaround lists for pre-gen8 workarounds as well to be
> consistent in the way we handle and dump the WAs.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc:
== Series Details ==
Series: drm/i915/execlists: Ignore discrepancies in pending[] across resets
URL : https://patchwork.freedesktop.org/series/72730/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7838 -> Patchwork_16317
Su
== Series Details ==
Series: drm/i915: add extra slice common debug registers
URL : https://patchwork.freedesktop.org/series/72735/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7838 -> Patchwork_16318
Summary
---
**
== Series Details ==
Series: series starting with [1/9] drm/i915/dsb: Replace HAS_DSB check with
dsb->cmd_buf check
URL : https://patchwork.freedesktop.org/series/72737/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9d0a47bda474 drm/i915/dsb: Replace HAS_DSB check with dsb->cm
== Series Details ==
Series: series starting with [1/9] drm/i915/dsb: Replace HAS_DSB check with
dsb->cmd_buf check
URL : https://patchwork.freedesktop.org/series/72737/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7838 -> Patchwork_16319
On Wed, 2020-01-29 at 23:59 +, Chris Wilson wrote:
> Quoting Souza, Jose (2020-01-29 23:53:21)
> > On Wed, 2020-01-29 at 23:33 +, Chris Wilson wrote:
> > > Quoting José Roberto de Souza (2020-01-29 23:23:45)
> > > > Only the first and the last nodes were being added to
> > > > ref->prealloc
== Series Details ==
Series: series starting with [1/2] drm/i915/display/fbc: Make fences a
nice-to-have for GEN9+ (rev2)
URL : https://patchwork.freedesktop.org/series/72698/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7839 -> Patchwork_16320
==
== Series Details ==
Series: drm/i915/ddi: Ensure that the value assigned to ddi_clk_needed is a bool
URL : https://patchwork.freedesktop.org/series/72743/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7839 -> Patchwork_16321
===
== Series Details ==
Series: drm/i915/hotplug: Use phy to get the hpd_pin instead of the port
URL : https://patchwork.freedesktop.org/series/72747/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
43a8820537ab drm/i915/hotplug: Use phy to get the hpd_pin instead of the port
-:34:
== Series Details ==
Series: drm/i915/hotplug: Use phy to get the hpd_pin instead of the port
URL : https://patchwork.freedesktop.org/series/72747/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7839 -> Patchwork_16322
Summa
1 - 100 of 107 matches
Mail list logo
