== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Also use async bind for
PIN_USER into bsw/bxt ggtt
URL : https://patchwork.freedesktop.org/series/72809/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
363fa0343c9f drm/i915/gt: Also use async bind for
On Thu, Jan 30, 2020 at 08:07:07PM +, Souza, Jose wrote:
> On Thu, 2020-01-30 at 19:25 +0200, Ville Syrjälä wrote:
> > On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Roberto de Souza
> > wrote:
> > > TGL timeouts when disabling MST transcoder and fifo underruns over
> > > MST
> > > transcoders
Chris Wilson writes:
> A masked register does not need rmw to update, and it is best not to use
> such a sequence.
>
> Reported-by: Ville Syrjälä
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 32
On Fri, Jan 31, 2020 at 12:55:45PM +0200, Jani Nikula wrote:
> On Fri, 31 Jan 2020, "Bharadiya,Pankaj"
> wrote:
> > I am exploring the way of implementing the pipe writeback feature in i915
> > and
> > would like to get early feedback on design.
> >
> > We have a Wireless display(WD) transcoder
Creating a mapping to a userptr backed GEM object may cause a currently
unavoidable lockdep splat inside the i915 driver. Then, such operation
is expected to fail to prevent from that badness to happen.
Add a respective subtest for each mapping type.
Signed-off-by: Janusz Krzysztofik
Cc:
I'm adding a cover letter in case it is required for having a related
kernel side patch been tested with this one. Since I've proposed to
change an error code returned by an IOCTL, this patch is expected to
fail when tested alone, without the kernel side counterpart.
Thanks,
Janusz
Janusz
Quoting Akeem G Abodunrin (2020-01-30 18:57:21)
> From: Prathap Kumar Valsan
>
> On gen7 and gen7.5 devices, there could be leftover data residuals in
> EU/L3 from the retiring context. This patch introduces workaround to clear
> that residual contexts, by submitting a batch buffer with
Op 30-01-2020 om 12:58 schreef Chris Wilson:
> On seqno rollover, we need to allocate ourselves a new cacheline. This
> might incur grabbing a new page and pinning it into the GGTT, with some
> rather unfortunate lockdep implications.
>
> To avoid a mutex, and more specifically pinning in the GGTT
Quoting Chris Wilson (2020-01-30 18:45:53)
> To enable non-persistent contexts, we require a means of cancelling any
> inflight work from that context. This is first done "gracefully" by
> using preemption to kick the active context off the engine, and then
> forcefully by resetting the engine if
On 31/01/2020 01:54, Umesh Nerlige Ramappa wrote:
On Mon, Jan 27, 2020 at 11:16:32AM +0200, Lionel Landwerlin wrote:
[snip]
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1323,7 +1323,12 @@ static int oa_get_render_ctx_id(struct
i915_perf_stream *stream)
On Fri, Jan 31, 2020 at 03:04:17PM +0530, Manna, Animesh wrote:
>
> On 30-01-2020 23:43, Souza, Jose wrote:
> > On Wed, 2020-01-29 at 20:20 +0200, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> We may want to not use the DSB even if the platform has one.
> >> So replace the HAS_DSB
Quoting Patchwork (2020-01-31 09:13:18)
> Participating hosts (43 -> 45)
> --
>
> Additional (7): fi-hsw-peppy fi-skl-6770hq fi-snb-2520m fi-ivb-3770
> fi-elk-e7500 fi-bsw-kefka fi-skl-6700k2
> Missing(5): fi-icl-1065g7 fi-hsw-4200u fi-byt-squawks fi-bwr-2160
If lmem is supported DSB should use local memeory instead
of system memory. Using local memory surely bring performance
improvement as local memory is close to gpu. Also want to avoid
multiple gpu using system memory.
Used LMEM api to create gem object needed for DSB command buffer.
v1: Initial
Quoting Mika Kuoppala (2020-01-31 11:51:44)
> Chris Wilson writes:
>
> > A masked register does not need rmw to update, and it is best not to use
> > such a sequence.
> >
> > Reported-by: Ville Syrjälä
> > Signed-off-by: Chris Wilson
> > Cc: Ville Syrjälä
> > Cc: Tvrtko Ursulin
> > ---
> >
If the heartbeat fires in the middle of the preempt-hang test, it
consumes our forced hang disrupting the test.
Reported-by: Daniel Vetter
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
== Series Details ==
Series: drm/i915: conversion to new struct drm_device based logging macros.
URL : https://patchwork.freedesktop.org/series/72812/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7850 -> Patchwork_16352
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-01-31 11:51:44)
>> Chris Wilson writes:
>>
>> > A masked register does not need rmw to update, and it is best not to use
>> > such a sequence.
>> >
>> > Reported-by: Ville Syrjälä
>> > Signed-off-by: Chris Wilson
>> > Cc: Ville Syrjälä
>> >
Commit 4f2a572eda67 ("drm/i915/userptr: Never allow userptr into the
mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when atepmted
on a userptr object in order to protect from a lockdep splat. Later
on, new mapping types were introduced by commit cc662126b413
("drm/i915: Introduce
Test-with: <20200131131234.23058-2-janusz.krzyszto...@linux.intel.com>
As I'm proposing to change an error code returned by an IOCTL, this
patch must be tested with a corresponding patch on the IGT side.
Janusz Krzysztofik (1):
drm/i915: Never allow userptr into the new mapping types
Quoting Mika Kuoppala (2020-01-31 13:22:38)
> Chris Wilson writes:
>
> > If the heartbeat fires in the middle of the preempt-hang test, it
> > consumes our forced hang disrupting the test.
> >
> > Reported-by: Daniel Vetter
> > Signed-off-by: Chris Wilson
> > ---
> >
To enable non-persistent contexts, we require a means of cancelling any
inflight work from that context. This is first done "gracefully" by
using preemption to kick the active context off the engine, and then
forcefully by resetting the engine if it is active. If we are unable to
reset the engine
Lift the routines to emit a request to update the SSEU on the
intel_context out of i915_gem_context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_context.c | 85 -
drivers/gpu/drm/i915/gt/intel_context.h
Since PIN_GLOBAL is no longer guaranteed to be synchronous, we must no
forget to include a wait-for-vma prior to execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 9 +
1 file changed, 9 insertions(+)
diff --git
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Steve Carbonari
Reviewed-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/Makefile | 1 +
We want to separate the utility functions for controlling the logical
ring context from the execlists submission mechanism (which is an
overgrown scheduler).
This is similar to Daniele's work to split up the files, but being
selfish I wanted to base it after my own changes to intel_lrc.c petered
In the rare cases where we are using the global GGTT for execution in
the selftests, we have marked them with PIN_USER knowing that they will
be bound as PIN_GLOBAL as well. However, we need to catch the extra flag
in deciding to use the async worker for such binds as well.
Signed-off-by: Chris
When modifying the register state of the context, we can use the
ce->lrc_reg_state of the shadow context as we have it pinned.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/scheduler.c | 35 +++-
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
Cc: Steve Carbonari
---
drivers/gpu/drm/i915/i915_active.c | 42 ++
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
Cleanup intel_lrc.h by moving some of the residual common register
definitions into intel_lrc_reg.h, prior to rebranding and splitting off
the submission backends.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc:
On Fri, Jan 31, 2020 at 05:12:58PM +0530, Animesh Manna wrote:
> If lmem is supported DSB should use local memeory instead
> of system memory. Using local memory surely bring performance
> improvement as local memory is close to gpu. Also want to avoid
> multiple gpu using system memory.
>
> Used
On Fri, Jan 31, 2020 at 05:36:15PM +0530, Manna, Animesh wrote:
>
> On 31-01-2020 17:12, Ville Syrjälä wrote:
> > On Fri, Jan 31, 2020 at 03:04:17PM +0530, Manna, Animesh wrote:
> >> On 30-01-2020 23:43, Souza, Jose wrote:
> >>> On Wed, 2020-01-29 at 20:20 +0200, Ville Syrjala wrote:
> From:
Quoting Mika Kuoppala (2020-01-31 13:14:38)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-01-31 11:51:44)
> >> Chris Wilson writes:
> >>
> >> > A masked register does not need rmw to update, and it is best not to use
> >> > such a sequence.
> >> >
> >> > Reported-by: Ville Syrjälä
Quoting Maarten Lankhorst (2020-01-31 10:12:36)
> Op 30-01-2020 om 12:58 schreef Chris Wilson:
> > On seqno rollover, we need to allocate ourselves a new cacheline. This
> > might incur grabbing a new page and pinning it into the GGTT, with some
> > rather unfortunate lockdep implications.
> >
> >
Since PIN_GLOBAL is no longer guaranteed to be synchronous, we must no
forget to include a wait-for-vma prior to execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c| 10 ++
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 9 +
2 files
On Fri, Jan 31, 2020 at 12:00:39PM +0530, Bharadiya,Pankaj wrote:
> I am exploring the way of implementing the pipe writeback feature in i915 and
> would like to get early feedback on design.
>
> We have a Wireless display(WD) transcoder which can be used for capturing
> display pipe output to
On 31-01-2020 17:12, Ville Syrjälä wrote:
On Fri, Jan 31, 2020 at 03:04:17PM +0530, Manna, Animesh wrote:
On 30-01-2020 23:43, Souza, Jose wrote:
On Wed, 2020-01-29 at 20:20 +0200, Ville Syrjala wrote:
From: Ville Syrjälä
We may want to not use the DSB even if the platform has one.
So
On Fri, 31 Jan 2020, "Bharadiya,Pankaj"
wrote:
> I am exploring the way of implementing the pipe writeback feature in i915 and
> would like to get early feedback on design.
>
> We have a Wireless display(WD) transcoder which can be used for capturing
> display pipe output to memory. It is
== Series Details ==
Series: drm/i915: conversion to new struct drm_device based logging macros.
URL : https://patchwork.freedesktop.org/series/72812/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
be9ed48fe6e7 drm/i915: conversion to drm_device logging macros when
On Fri, Jan 31, 2020 at 02:12:33PM +0100, Janusz Krzysztofik wrote:
> I'm adding a cover letter in case it is required for having a related
> kernel side patch been tested with this one.
For the record, Test-With doesn't require the IGT side to have a cover
letter.
--
Petri Latvala
Chris Wilson writes:
> If the heartbeat fires in the middle of the preempt-hang test, it
> consumes our forced hang disrupting the test.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 10 ++
> 1 file changed, 10
We already have guc_is_running function, but it only reflects
firmware status, while to fully use GuC we need to know if we've
already established communication with it.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Tuesday, January 28, 2020 9:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915: move intel_dp_set_m_n() to encoder
> for DDI platforms
>
> intel_dp_set_m_n()
This patch series continues the conversion of the printk based logging
macros to the struct drm_device based logging macros in drm/i915. This
series focuses on the root drm/i915 driver folder with patches achieved
manually and using coccinelle.
Wambui Karuga (5):
drm/i915: conversion to
On 30-01-2020 23:43, Souza, Jose wrote:
On Wed, 2020-01-29 at 20:20 +0200, Ville Syrjala wrote:
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.
Reviewed-by: José
Converts various instances of the printk drm logging macros to the
struct drm_device based logging macros in the drm/i915 folder using the
following coccinelle script that transforms based on the existence of
the struct drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...) {
...
struct
Manually convert printk based drm logging macros to the struct
drm_device based logging macros in i915/i915_cmd_parser.c.
This also involves extracting the drm_i915_private device from various
intel types for use in the macros.
Instances of the DRM_DEBUG macro are not converted due to the lack of
Manual conversion of instances of printk based drm logging macros to the
struct drm_device based logging macros in i915/i915_perf.c.
Also involves extraction of the struct drm_i915_private device from
various intel types for use in the macros.
Instances of the DRM_DEBUG printk macro were not
On Thu, 30 Jan 2020, Vivek Kasireddy wrote:
> 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.
Quoting Patchwork (2020-01-31 03:03:37)
> Participating hosts (47 -> 42)
> --
>
> Additional (4): fi-bdw-gvtdvm fi-gdg-551 fi-elk-e7500 fi-kbl-7500u
> Missing(9): fi-hsw-4770r fi-icl-1065g7 fi-hsw-4200u fi-byt-j1900
> fi-bsw-cyan fi-hsw-4770 fi-ivb-3770
Manual conversion of printk based logging macros to the struct
drm_device based logging macros in i915/i915_debugfs.c.
Also involves extracting the struct drm_i915_private device from various
intel types to use in the macros.
This does not convert various instances of the DRM_DEBUG macro due to
Since PIN_GLOBAL is no longer guaranteed to be synchronous, we must no
forget to include a wait-for-vma prior to execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 9 +
1 file changed, 9 insertions(+)
diff --git
In the rare cases where we are using the global GGTT for execution in
the selftests, we have marked them with PIN_USER knowing that they will
be bound as PIN_GLOBAL as well. However, we need to catch the extra flag
in deciding to use the async worker for such binds as well.
Signed-off-by: Chris
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gt: Skip rmw for masked registers
URL : https://patchwork.freedesktop.org/series/72804/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7849 -> Patchwork_16350
On Thu, 30 Jan 2020, Akeem G Abodunrin wrote:
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index b0ade76bec90..7ac5b3565845 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -172,6 +172,11 @@
On Wed, 29 Jan 2020, "Kulkarni, Vandita" wrote:
>> -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
On Tue, 28 Jan 2020, Ville Syrjälä wrote:
> On Tue, Jan 28, 2020 at 05:19:42PM +0200, Jani Nikula wrote:
>> The debugfs is not the place to print duplicated info about VBT data.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 11 +--
>> 1 file changed,
Manual conversion of instances of printk based drm logging macros to the
struct drm_device based logging macros in i915/i915_pci.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Since PIN_GLOBAL is no longer guaranteed to be synchronous, we must no
forget to include a wait-for-vma prior to execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 ++
drivers/gpu/drm/i915/gt/selftest_lrc.c| 33 +++
Chris Wilson writes:
> In the rare cases where we are using the global GGTT for execution in
> the selftests, we have marked them with PIN_USER knowing that they will
> be bound as PIN_GLOBAL as well. However, we need to catch the extra flag
> in deciding to use the async worker for such binds
On Friday, January 31, 2020 3:32:21 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-31 13:20:37)
> > Commit 4f2a572eda67 ("drm/i915/userptr: Never allow userptr into the
> > mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when atepmted
> > on a userptr object in order to
== Series Details ==
Series: drm/i915/dsb: Enable lmem for dsb
URL : https://patchwork.freedesktop.org/series/72818/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1dd958225f8b drm/i915/dsb: Enable lmem for dsb
-:6: WARNING:TYPO_SPELLING: 'memeory' may be misspelled - perhaps
On Friday, January 31, 2020 3:37:05 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-31 13:12:34)
> > Creating a mapping to a userptr backed GEM object may cause a currently
> > unavoidable lockdep splat inside the i915 driver. Then, such operation
> > is expected to fail to
On Mon, Jan 20, 2020 at 07:47:12PM +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
>
== Series Details ==
Series: drm/i915/dsb: Enable lmem for dsb
URL : https://patchwork.freedesktop.org/series/72818/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7850 -> Patchwork_16355
Summary
---
**SUCCESS**
Quoting Michal Wajdeczko (2020-01-31 14:58:34)
> While we are always using CT "send" buffer to send request messages
> to GuC, we usually don't ask GuC to use CT "receive" buffer to send
> back response messages, since almost all returned data can fit into
> reserved bits in status dword inside CT
On Fri, Jan 31, 2020 at 03:33:55PM +, Chris Wilson wrote:
Quoting Michal Wajdeczko (2020-01-31 14:58:34)
While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use CT "receive" buffer to send
back response messages, since almost all returned
Quoting Michal Wajdeczko (2020-01-31 13:26:10)
> We already have guc_is_running function, but it only reflects
> firmware status, while to fully use GuC we need to know if we've
> already established communication with it.
"Ready, set, go!"
ready has connotations of being before running, whereas
== Series Details ==
Series: series starting with [01/12] drm/i915/gem: Require per-engine reset
support for non-persistent contexts
URL : https://patchwork.freedesktop.org/series/72813/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d94430028946 drm/i915/gem: Require
Commit 4f2a572eda67 ("drm/i915/userptr: Never allow userptr into the
mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when attempted
on a userptr object in order to protect from a lockdep splat. Later
on, new mapping types were introduced by commit cc662126b413
("drm/i915: Introduce
== Series Details ==
Series: series starting with [01/12] drm/i915/gem: Require per-engine reset
support for non-persistent contexts
URL : https://patchwork.freedesktop.org/series/72813/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7850 -> Patchwork_16353
Quoting Janusz Krzysztofik (2020-01-31 13:12:34)
> Creating a mapping to a userptr backed GEM object may cause a currently
> unavoidable lockdep splat inside the i915 driver. Then, such operation
> is expected to fail to prevent from that badness to happen.
>
> Add a respective subtest for each
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Also use async bind for
PIN_USER into bsw/bxt ggtt (rev2)
URL : https://patchwork.freedesktop.org/series/72809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7850 -> Patchwork_16354
While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use CT "receive" buffer to send
back response messages, since almost all returned data can fit into
reserved bits in status dword inside CT descriptor. However, relying
on data modifications
On Tue, Jan 28, 2020 at 03:37:06PM -0800, Matt Roper wrote:
> On Fri, Jan 24, 2020 at 10:44:56AM +0200, Stanislav Lisovskiy wrote:
> > During full modeset, global state(i.e dev_priv) is protected
> > by locking the crtcs in state, otherwise global state is not
> > serialized. Also if it is not a
On Friday, January 31, 2020 3:32:21 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-31 13:20:37)
> > Commit 4f2a572eda67 ("drm/i915/userptr: Never allow userptr into the
> > mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when atepmted
> > on a userptr object in order to
We already have guc_is_running function, but it only reflects
firmware status, while to fully use GuC we need to know if we've
already established communication with it.
v2: also s/intel_guc_is_running/intel_guc_is_fw_running (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Quoting Michal Wajdeczko (2020-01-31 15:37:06)
> We already have guc_is_running function, but it only reflects
> firmware status, while to fully use GuC we need to know if we've
> already established communication with it.
>
> v2: also s/intel_guc_is_running/intel_guc_is_fw_running (Chris)
>
>
Reducing audience as this series is of high interest externally.
I fully agree with Joonas' suggestion here, and we have been looking at doing
just that. But can we iterate as a follow up patch series? Putting in the infra
to support igt assembly from source will take a little time (igt
On Fri, 31 Jan 2020 16:33:55 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-31 14:58:34)
While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use CT "receive" buffer to send
back response messages, since almost all returned
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Also use async bind for
PIN_USER into bsw/bxt ggtt (rev2)
URL : https://patchwork.freedesktop.org/series/72809/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bb9f5c3f2305 drm/i915/gt: Also use async bind for
Quoting Janusz Krzysztofik (2020-01-31 13:20:37)
> Commit 4f2a572eda67 ("drm/i915/userptr: Never allow userptr into the
> mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when atepmted
> on a userptr object in order to protect from a lockdep splat. Later
> on, new mapping types were
Chris Wilson writes:
> Since PIN_GLOBAL is no longer guaranteed to be synchronous, we must no
> forget to include a wait-for-vma prior to execution.
Dunno if we got em all, we soon know.
Cried for helper but lets move first,
Reviewed-by: Mika Kuoppala
>
> Signed-off-by: Chris Wilson
> ---
On Tue, Jan 28, 2020 at 03:33:11PM -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
On Fri, 31 Jan 2020 17:40:12 +0100, Matthew Brost
wrote:
On Fri, Jan 31, 2020 at 03:33:55PM +, Chris Wilson wrote:
Quoting Michal Wajdeczko (2020-01-31 14:58:34)
While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use CT "receive"
== Series Details ==
Series: drm/i915/guc: Stop using mutex while sending CTB messages
URL : https://patchwork.freedesktop.org/series/72827/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7853 -> Patchwork_16359
Summary
On Fri, Jan 31, 2020 at 10:19:51PM -0500, Matt Atwood wrote:
> On Tiger Lake we do not support source keying in the pixel formats P010,
> P012, P016.
>
> v2: Move WA to end of function. Create helper function for format
> check. Less verbose debugging messaging.
>
> Bspec: 52890
> Cc: Matt Roper
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Also use async bind for
PIN_USER into bsw/bxt ggtt (rev3)
URL : https://patchwork.freedesktop.org/series/72809/
State : failure
== Summary ==
Applying: drm/i915/gt: Also use async bind for PIN_USER into bsw/bxt ggtt
== Series Details ==
Series: disable drm_global_mutex for most drivers (rev4)
URL : https://patchwork.freedesktop.org/series/72711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7853 -> Patchwork_16357
Summary
---
On Fri, Jan 31, 2020 at 09:15:46AM -0800, Manasi Navare wrote:
> This patch pushes out the computation of master and slave
> transcoders in crtc states after encoder's compute_config hook.
> This ensures that the assigned master slave crtcs have exact same
> mode and timings which is a requirement
On 1/31/20 2:45 AM, Chris Wilson wrote:
We want to separate the utility functions for controlling the logical
ring context from the execlists submission mechanism (which is an
overgrown scheduler).
This is similar to Daniele's work to split up the files, but being
selfish I wanted to base it
== Series Details ==
Series: drm/i915/selftests: Disable heartbeat around hang tests
URL : https://patchwork.freedesktop.org/series/72821/
State : failure
== Summary ==
Applying: drm/i915/selftests: Disable heartbeat around hang tests
Using index info to reconstruct a base tree...
M
On Fri, Jan 31, 2020 at 07:53:23PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 31, 2020 at 09:15:47AM -0800, Manasi Navare wrote:
> > If one of the synced crtcs needs a full modeset, we need
> > to make sure all the synced crtcs are forced a full
> > modeset.
> >
> > Suggested-by: Ville Syrjälä
>
On Fri, Jan 31, 2020 at 11:46:25AM -0800, Manasi Navare wrote:
> On Fri, Jan 31, 2020 at 07:53:23PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 31, 2020 at 09:15:47AM -0800, Manasi Navare wrote:
> > > If one of the synced crtcs needs a full modeset, we need
> > > to make sure all the synced crtcs
This patch pushes out the computation of master and slave
transcoders in crtc states after encoder's compute_config hook.
This ensures that the assigned master slave crtcs have exact same
mode and timings which is a requirement for Port sync mode
to be enabled.
Suggested-by: Ville Syrjälä
Cc:
On 31-01-2020 17:33, Ville Syrjälä wrote:
On Fri, Jan 31, 2020 at 05:12:58PM +0530, Animesh Manna wrote:
If lmem is supported DSB should use local memeory instead
of system memory. Using local memory surely bring performance
improvement as local memory is close to gpu. Also want to avoid
On Tiger Lake we do not support source keying in the pixel formats P010,
P012, P016.
v2: Move WA to end of function. Create helper function for format
check. Less verbose debugging messaging.
Bspec: 52890
Cc: Matt Roper
Cc: Manasi Navare
CC: Ville Syrjälä
Signed-off-by: Matt Atwood
---
== Series Details ==
Series: drm/i915: Add missing HDMI audio pixel clocks for gen12 (rev2)
URL : https://patchwork.freedesktop.org/series/72617/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7835_full -> Patchwork_16310_full
== Series Details ==
Series: disable drm_global_mutex for most drivers (rev4)
URL : https://patchwork.freedesktop.org/series/72711/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ec6b1085531d drm: Complain if drivers still use the ->load callback
-:48:
1 - 100 of 158 matches
Mail list logo
