On Wed, May 06, 2020 at 06:15:28PM +0300, Imre Deak wrote:
> On Wed, Mar 11, 2020 at 05:54:20PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's get rid of the platform if ladders in
> > intel_digital_port_connected() and make it a vfunc. Now the if
> > ladders are at the encoder
On Wed, May 06, 2020 at 07:03:41PM +0300, Imre Deak wrote:
> On Wed, Mar 11, 2020 at 05:54:21PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Instead of constnantly having to figure out which hpd status bit
> > array to use let's store them under dev_priv.
> >
> > Should perhaps ta
Quoting Mika Kuoppala (2020-05-06 17:53:10)
> Aux table invalidation can fail on update. So
> next access may cause memory access to be into stale entry.
>
> Proposed workaround is to invalidate entries between
> all batchbuffers.
>
> v2: correct register address (Yang)
> v3: respect the order (C
On Fri, Mar 06, 2020 at 05:26:00PM -0800, Lucas De Marchi wrote:
> This avoids the annoying message
> "Failed to get panel details from OpRegion (-19)" while initializing.
> On DGFX there is no access to OpRegion, so just avoid any calls related
> to it.
>
> Signed-off-by: Lucas De Marchi
> ---
>
== Series Details ==
Series: drm/i915/dsi: Dont forget to clean up the connector on error
URL : https://patchwork.freedesktop.org/series/77011/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8439_full -> Patchwork_17596_full
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/panel/panel-visionox-rm69299.o
see include/linux/module.h for more information
Introduced by commit
c7f66d32dd43 ("drm/
Hi Mika,
> -Original Message-
> From: Mika Kuoppala
> Sent: Thursday, May 7, 2020 12:53 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Mika Kuoppala ; Chris Wilson
> ; Liu, Chuansheng ;
> Antognolli, Rafael ; Shi, Yang A
>
> Subject: [PATCH 4/4] drm/i915/gen12: Invalidate aux table entri
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/display/intel_fbc.c
between commit:
82152d424b6c ("Make the "Reducing compressed framebufer size" message be
DRM_INFO_ONCE()")
from the drm-intel-fixes tree and commit:
97ed48b5c8b1 ("drm/i915/fbc:
== Series Details ==
Series: Introduce Rocket Lake (rev5)
URL : https://patchwork.freedesktop.org/series/76826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8438_full -> Patchwork_17595_full
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/dsi: Dont forget to clean up the connector on error
URL : https://patchwork.freedesktop.org/series/77011/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8439 -> Patchwork_17596
Summary
-
== Series Details ==
Series: series starting with [01/15] drm/i915: Mark concurrent submissions with
a weak-dependency
URL : https://patchwork.freedesktop.org/series/77008/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8438_full -> Patchwork_17594_full
===
During the DSI initialization setup, after instantiating the relevant
drm connector and encoder objects, the connector also needs to be
cleaned up along with the encoder if an error is encountered. The error
can happen due to a missing mode in the VBT or for other reasons.
Signed-off-by: Vivek Kas
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags
across submit fences").
The bot has tested the following trees: v5.6.10.
v5.6.10: Failed to apply! Possible dependenci
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags
across submit fences").
The bot has tested the following trees: v5.6.10.
v5.6.10: Failed to apply! Possible dependenci
== Series Details ==
Series: series starting with [1/4] Revert "drm/i915/tgl: Include ro parts of l3
to invalidate" (rev3)
URL : https://patchwork.freedesktop.org/series/77000/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8437_full -> Patchwork_17592_full
===
== Series Details ==
Series: Introduce Rocket Lake (rev5)
URL : https://patchwork.freedesktop.org/series/76826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17595
Summary
---
**SUCCESS**
No regr
On Wed, May 06, 2020 at 06:17:28PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2020-05-06 16:55:07)
> > Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> > > Btw, there are other patches on the list of failed cherry-picks:
> > >
> > > 614654abe847 ("drm/i915: Check current i915_vma.pin_count sta
== Series Details ==
Series: Introduce Rocket Lake (rev5)
URL : https://patchwork.freedesktop.org/series/76826/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
992fe0e5bf6f drm/i915/rkl: Add RKL platform info and PCI ids
-:35: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - pos
== Series Details ==
Series: series starting with [01/15] drm/i915: Mark concurrent submissions with
a weak-dependency
URL : https://patchwork.freedesktop.org/series/77008/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17594
=
== Series Details ==
Series: series starting with [01/15] drm/i915: Mark concurrent submissions with
a weak-dependency
URL : https://patchwork.freedesktop.org/series/77008/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e532b66dff06 drm/i915: Mark concurrent submissions with a
== Series Details ==
Series: series starting with [1/3] drm/i915: Mark concurrent submissions with a
weak-dependency
URL : https://patchwork.freedesktop.org/series/77007/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17593
===
Some Cc to try to get it reviewed.
Lucas De Marchi
On Fri, Mar 6, 2020 at 5:26 PM Lucas De Marchi wrote:
>
> This avoids the annoying message
> "Failed to get panel details from OpRegion (-19)" while initializing.
> On DGFX there is no access to OpRegion, so just avoid any calls related
> to it.
There are a couple places in our driver that loop over transcoders A..D
for gen11+; since RKL only has three pipes/transcoders, this can lead to
unclaimed register reads/writes. We should add checks for transcoder
existence where appropriate.
v2: Move one transcoder check that wound up in the wro
There are a couple places in our driver that loop over transcoders A..D
for gen11+; since RKL only has three pipes/transcoders, this can lead to
unclaimed register reads/writes. We should add checks for transcoder
existence where appropriate.
v2: Move one transcoder check that wound up in the wro
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signe
This timeout is only used in one place, to provide a tiny bit of grace
for slow igt to cleanup after themselves. If we are a bit stricter and
opt to kill outstanding requsts rather than wait, we can speed up igt by
not waiting for 200ms after a hang.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
option, primarily to allow brave systems to disable the timeout and
solely rely on correct signaling.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.profile | 12
dri
As a means for a small code consolidation, but primarily to start
thinking more carefully about internal-vs-external linkage, pull the
pair of i915_sw_fence_await_dma_fence() calls into a common routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16 ++--
1
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Link: https://gitlab.freed
While this does not appear to fix any issues, the backend itself knows
when it wants to emit a breadcrumb, so let it make the final call.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 3 +--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 3 +--
2 files changed, 2
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
We allow exported sync_file fences to be used as submit fences, but they
are not the only source of user fences. We also accept an array of
syncobj, and as with sync_file these are dma_fences underneath and so
feature the same set of controls. The submit-fence allows for a request
to be scheduled a
While we ordinarily do not skip submit-fences due to the accompanying
hook that we want to callback on execution, a submit-fence on the same
timeline is meaningless.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 +++
1 file changed, 3 insertions(+)
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
Just tidy up the return handling for completed dma-fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 7daf81
The downside of using semaphores is that we lose metadata passing
along the signaling chain. This is particularly nasty when we
need to pass along a fatal error such as EFAULT or EDEADLK. For
fatal errors we want to scrub the request before it is executed,
which means that we cannot preload the req
These were used to set various timeouts for the reset procedure
(deciding when the engine was dead, and even if the reset itself was not
making forward progress). No longer used.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --g
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the sof
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the sof
While we ordinarily do not skip submit-fences due to the accompanying
hook that we want to callback on execution, a submit-fence on the same
timeline is meaningless.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 +++
1 file changed, 3 insertions(+)
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
On Mon, May 04, 2020 at 03:52:21PM -0700, Matt Roper wrote:
> There are a couple places in our driver that loop over transcoders A..D
> for gen11+; since RKL only has three pipes/transcoders, this can lead to
> unclaimed register reads/writes. We should add checks for transcoder
> existence where
== Series Details ==
Series: drm/i915: Propagate error from completed fences
URL : https://patchwork.freedesktop.org/series/77003/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8434_full -> Patchwork_17591_full
Summary
== Series Details ==
Series: series starting with [1/4] Revert "drm/i915/tgl: Include ro parts of l3
to invalidate" (rev3)
URL : https://patchwork.freedesktop.org/series/77000/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8437 -> Patchwork_17592
=
== Series Details ==
Series: drm/i915: Propagate error from completed fences
URL : https://patchwork.freedesktop.org/series/77003/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8434 -> Patchwork_17591
Summary
---
**S
Quoting Mika Kuoppala (2020-05-06 15:47:33)
> Flush TDL,L3 and EUs
>
> Signed-off-by: Mika Kuoppala
I bow to your interpretation of the docs,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fre
Quoting Chris Wilson (2020-05-06 16:55:07)
> Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> > Btw, there are other patches on the list of failed cherry-picks:
> >
> > 614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
> > unbind")
>
> We need that to fix a deadlock.
>
> > c
== Series Details ==
Series: series starting with [1/2] drm/i915: Mark concurrent submissions with a
weak-dependency
URL : https://patchwork.freedesktop.org/series/76999/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8434 -> Patchwork_17590
===
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
v2: correct register address (Yang)
v3: respect the order (Chris)
References bspec#43904, hsdes#1809175790
Cc: Chris Wi
On Wed, May 06, 2020 at 06:49:06AM -0700, Srivatsa, Anusha wrote:
>
>
> > -Original Message- From: Intel-gfx
> > On Behalf Of Matt Roper
> > Sent: Tuesday, May 5, 2020 4:22 AM To:
> > intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v2
> > 10/22] drm/i915/rkl: RKL only uses PH
Quoting Mika Kuoppala (2020-05-06 16:58:55)
> Aux table invalidation can fail on update. So
> next access may cause memory access to be into stale entry.
>
> Proposed workaround is to invalidate entries between
> all batchbuffers.
>
> v2: correct register address (Yang)
>
> References bspec#4390
On Wed, Mar 11, 2020 at 05:54:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of several platform specific variants of
> intel_digital_port_connected() and just use the ISR bits we've
> stashed away.
>
> v2: Duplicate stuff to avoid exposing platform specific
> functions a
We need to preserve fatal errors from fences that are being terminated
as we hook them up.
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_request.c | 4 +++-
1 fil
On Wed, Mar 11, 2020 at 05:54:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of constnantly having to figure out which hpd status bit
> array to use let's store them under dev_priv.
>
> Should perhaps take this further and stash even more stuff to
> make the hpd handling more
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
v2: correct register address (Yang)
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc:
Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> On Wed, Apr 29, 2020 at 09:54:44PM +0100, Chris Wilson wrote:
> > As with the realisation for soft-rc6, we respond to idling the engines
> > within microseconds, far faster than the response times for HW RC6 and
> > RPS. Furthermore, our fast parking upo
On 05/05/2020 22:52, Chris Wilson wrote:
We need to preserve fatal errors from fences that are being terminated
as we hook them up.
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Quoting Mika Kuoppala (2020-05-06 16:20:22)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-05-06 15:47:34)
> >> Aux table invalidation can fail on update. So
> >> next access may cause memory access to be into stale entry.
> >>
> >> Proposed workaround is to invalidate entries between
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-05-06 15:47:34)
>> Aux table invalidation can fail on update. So
>> next access may cause memory access to be into stale entry.
>>
>> Proposed workaround is to invalidate entries between
>> all batchbuffers.
>
> This sounds like it should have a
On Wed, Mar 11, 2020 at 05:54:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's get rid of the platform if ladders in
> intel_digital_port_connected() and make it a vfunc. Now the if
> ladders are at the encoder initialization which makes them a bit
> less convoluted.
>
> v2: Add
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
URL : https://patchwork.freedesktop.org/series/73036/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8433_full -> Patchwork_17589_full
=
Quoting Mika Kuoppala (2020-05-06 15:47:34)
> Aux table invalidation can fail on update. So
> next access may cause memory access to be into stale entry.
>
> Proposed workaround is to invalidate entries between
> all batchbuffers.
This sounds like it should have a sunset clause. Do we anticipate
This reverts commit 62037229b7d94f1db5ef8d2e2ec819832ef3.
L3 ro cache invalidation is part of the dword0 of pipe
control. Also it is not relevant to this gen.
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 -
drivers/gpu/drm/i915
Flush TDL,L3 and EUs
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 78f879ed4aa7..e1235d504837 100644
--- a/drivers/gpu/drm/i915/gt/intel_l
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael ANtognolli
Signed-off-by: Mik
HDC pipeline flush is bit on the first dword of
the PIPE_CONTROL, not the second. Make it so.
v2: function naming (Chris)
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h | 34
drivers/gpu/drm/i915/gt/intel_gpu_command
Quoting Chris Wilson (2020-05-06 15:36:16)
> Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
> timeslicing, as we do not treat it as a preemption request but as a soft
> ordering hint. If we apply the hint, then when we recompute the ordering
> after unwinding for the timeslice, we
On Wed, Apr 29, 2020 at 09:54:44PM +0100, Chris Wilson wrote:
> As with the realisation for soft-rc6, we respond to idling the engines
> within microseconds, far faster than the response times for HW RC6 and
> RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
> running for many des
Hey,
I've been testing on re-tgl1-display, but series fails.
The 8k mode is rejected because of htotal exceeding limits.
When testing 5120x3200@120 Hz, I get:
[18352.624231] i915 :00:02.0: [drm:intel_crtc_compute_min_cdclk [i915]]
required cdclk (1056740 kHz) exceeds max (652800 kHz)
Latt
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the sof
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 107 +
1 file changed, 107 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 7274ffbf3..a1523277b 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/test
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_fence.c | 124
1 file changed, 124 insertions(+)
diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
index 4b0d87e4d..a75188c9c 100644
--- a/tests/i915/gem_exec_fence.c
+++ b/tests/i915/ge
On 2020-04-29 at 15:54:49 -0400, Sean Paul wrote:
> From: Sean Paul
>
> HDCP signalling should not be left on, WARN if it is
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Reviewed-by: Ramalingam C
Just reconfirming the R-b.
-Ram
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesk
On 2020-04-29 at 15:54:50 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
> aux messages and add the aksv flag in the aux transfer hook.
>
> IIRC, this was the original implementation and folks wanted this hack to
> be isolat
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
URL : https://patchwork.freedesktop.org/series/73036/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433 -> Patchwork_17589
Summa
On 2020-04-29 at 15:54:48 -0400, Sean Paul wrote:
> From: Sean Paul
>
> On HDCP disable, clear the repeater bit. This ensures if we connect a
> non-repeater sink after a repeater, the bit is in the state we expect.
>
> Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
> Cc
On 2020-04-29 at 15:54:47 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch fixes a few bugs:
>
> 1- We weren't taking into account sha_leftovers when adding multiple
>ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
>the beginning of ksv[j]
>
> 2- In the sha_
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 10/22] drm/i915/rkl: RKL only uses PHY_MISC for
> PHY's A and B
>
> Since the number of platforms with this restr
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev2)
URL : https://patchwork.freedesktop.org/series/76993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433_full -> Patchwork_17588_full
Summ
On Wed, May 06, 2020 at 04:16:36PM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 03:12:10PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 0
Op 01-05-2020 om 01:09 schreef Manasi Navare:
> From: Maarten Lankhorst
>
> Small changes to intel_dp_mode_valid(), allow listing modes that
> can only be supported in the bigjoiner configuration, which is
> not supported yet.
>
> eDP does not support bigjoiner, so do not expose bigjoiner only
> m
On Wed, May 06, 2020 at 04:17:20PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 03:58:21PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > GLK wants the +1 adjustement for the "blocks per line" value
> > for x-tile/y-tile, just like cnl+.
> >
> > Also the x-tile and l
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No change is dsb write/commit functions.
Now dsb get/put function is refactored and currently used only for
reference counting. Below dsb api added to do respective job
On Thu, Apr 30, 2020 at 03:58:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> GLK wants the +1 adjustement for the "blocks per line" value
> for x-tile/y-tile, just like cnl+.
>
> Also the x-tile and linear cases are almost identical. The only
> difference is this +1 which is always d
On Wed, May 06, 2020 at 03:12:10PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> > On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 0
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev2)
URL : https://patchwork.freedesktop.org/series/76993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433 -> Patchwork_17588
Summary
--
On 2020-05-05 at 19:09:54 +0300, Imre Deak wrote:
> On Tue, May 05, 2020 at 07:39:04AM -0700, Matt Roper wrote:
> > On Tue, May 05, 2020 at 10:20:58AM +0530, Anshuman Gupta wrote:
> > > On 2020-05-04 at 15:52:13 -0700, Matt Roper wrote:
> > > > RKL power wells are similar to TGL power wells, but ha
On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 05, 2020 at 01:22:44PM +0300, Stanislav Lisovskiy wrote:
> > > > Starting from
Quoting Lionel Landwerlin (2020-05-06 13:04:57)
> On 04/05/2020 14:23, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-05-04 12:12:49)
> >> Add 2 new properties to the i915-perf open ioctl to specify an array
> >> of GEM context handles as well as the length of the array.
> >>
> >> This can
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
th
On 06/05/2020 15:04, Lionel Landwerlin wrote:
On 04/05/2020 14:23, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-05-04 12:12:49)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers usi
On 04/05/2020 14:23, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-05-04 12:12:49)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: [Intel-gfx] [PATCH v2 02/22] x86/gpu: add RKL stolen memory support
>
> RKL re-uses the same stolen memory regi
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code
URL : https://patchwork.freedesktop.org/series/76993/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
th
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ä
Now that we've plumbed the crtc state all the way down we can
eliminate the DP_TP_{CTL,STATUS} register offsets from intel_dp,
and instead we derive them directly from the crtc state.
And thus we can get rid of the nasty hack in intel_ddi_get_config()
which mutates intel_dp d
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
1 - 100 of 117 matches
Mail list logo
