On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > +void component_match_add_typed(struct device *master,
> > + struct component_match **matchptr,
> > + int (*compare_typed)(struct device *, int, void *), void
On Thu, Jan 31, 2019 at 12:29:31PM +0530, Ramalingam C wrote:
> Since DP ERRATA message is not defined at spec, those structure
> definition is removed from drm_hdcp.h
>
> Signed-off-by: Ramalingam C
> Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_hdcp.h | 6
On Thu, Jan 31, 2019 at 12:29:34PM +0530, Ramalingam C wrote:
> Implements the
> Waitqueue is created to wait for CP_IRQ
> Signaling the CP_IRQ arrival through atomic variable.
> For applicable DP HDCP2.2 msgs read wait for CP_IRQ.
>
> As per HDCP2.2 spec "HDCP Transmitters must
On Thu, Jan 31, 2019 at 09:00:30AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > > +void component_match_add_typed(struct device *master,
> > > + struct component_match **matchp
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev13)
URL : https://patchwork.freedesktop.org/series/38254/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5517 -> Patchwork_12101
Summary
---
**SUCCESS**
On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is equipped
On Thu, Jan 31, 2019 at 12:29:52PM +0530, Ramalingam C wrote:
> Mei hdcp driver is designed as component slave for the I915 component
> master.
>
> v2: Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
> v4:
> Made static dummy functions as inline in mei_hdcp.h
> API
On Tue, Jan 29, 2019 at 03:31:21PM +0200, Jani Nikula wrote:
> We've supported the opregion RVDA/RVDS fields for VBT size >= 6 KB since
> commit 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6
> KB"). That's three years, almost to the date.
>
> The implementation was based on spec
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev27)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
243407f1d47a drm/i915: Record the sseu configuration per-context & engine
af1c48afcfc8 drm/i915/p
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev27)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Record the sseu configuration per-context & engine
-drivers/
On Thu, Jan 31, 2019 at 12:29:53PM +0530, Ramalingam C wrote:
> Commits the content protection change of a connector,
> without crtc modeset. This improves the user experience.
>
> Originally proposed by Sean Paul at v3 of HDCP1.4 framework
> https://patchwork.freedesktop.org/patch/191759/. For so
On Thu, Jan 31, 2019 at 09:12:45AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 31, 2019 at 09:00:30AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > > > +void component_ma
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
r
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev27)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12102
Summary
---
== Series Details ==
Series: series starting with [1/3] drm/i915: Generalise GPU activity tracking
URL : https://patchwork.freedesktop.org/series/56010/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5514_full -> Patchwork_12098_full
== Series Details ==
Series: series starting with [1/4] drm/i915: Enable transition watermarks for
glk
URL : https://patchwork.freedesktop.org/series/56025/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12103
=
Quoting Tvrtko Ursulin (2019-01-31 08:47:37)
> + /*
> +* Some future proofing on the types since the uAPI is wider than the
> +* current internal implementation.
> +*/
> + if (WARN_ON((fls(user->slice_mask) >
> +sizeof(context->slice_mask) * B
On 30/01/2019 18:14, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-30 18:05:42)
On 30/01/2019 02:19, Chris Wilson wrote:
In the next patch, we add another user that wants to check whether
requests can be merge into a single HW execution, and in the future we
want to add more conditions
Quoting Tvrtko Ursulin (2019-01-31 09:19:18)
>
> On 30/01/2019 18:14, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-30 18:05:42)
> >>
> >> On 30/01/2019 02:19, Chris Wilson wrote:
> >>> @@ -827,8 +836,7 @@ static void execlists_dequeue(struct intel_engine_cs
> >>> *engine)
> >>>
On 31/01/2019 09:15, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-31 08:47:37)
+ /*
+* Some future proofing on the types since the uAPI is wider than the
+* current internal implementation.
+*/
+ if (WARN_ON((fls(user->slice_mask) >
+
Op 31-01-2019 om 01:58 schreef José Roberto de Souza:
> Changing the i915_edp_psr_debug was enabling, disabling or switching
> PSR version by directly calling intel_psr_disable_locked() and
> intel_psr_enable_locked(), what is not the default PSR path that will
> be executed by real users.
>
> So l
Quoting Tvrtko Ursulin (2019-01-31 09:19:18)
>
> On 30/01/2019 18:14, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-30 18:05:42)
> >>> @@ -766,8 +774,10 @@ static void execlists_dequeue(struct intel_engine_cs
> >>> *engine)
> >>> * second request, and so we never
://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Generalise-GPU-activity-tracking/20190131-160548
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-defconfig (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
# save the attached
On 30/01/2019 16:21, Chris Wilson wrote:
igt doesn't handle skipping from inside igt_fork very gracefully and
crashes instead of reporting the lack of requirements. One solution
would be to fix igt, but far easier is to just move the requirement
checking around to do it before we even fork.
Bug
On Thu, 24 Jan 2019, Zhenyu Wang wrote:
> Hi,
>
> Here's one fix for gvt to destroy shadow batch and indirect context
> properly.
I seem to have failed to let you know that I've pulled this.
Thanks,
Jani.
>
> Thanks.
> --
> The following changes since commit 51b00d8509dc69c98740da2ad07308b630
== Series Details ==
Series: drm/i915/opregion: rvda is relative from opregion base, not absolute
(rev3)
URL : https://patchwork.freedesktop.org/series/53996/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12104
===
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev28)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f3fce16bb1d7 drm/i915: Record the sseu configuration per-context & engine
9272354cb1cd drm/i915/p
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev28)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Record the sseu configuration per-context & engine
-drivers/
://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Generalise-GPU-activity-tracking/20190131-160548
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-s1-201904 (attached as .config)
compiler: gcc-6 (Debian 6.5.0-2) 6.5.0 20181026
reproduce:
# save
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev28)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12105
Summary
---
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
r
Quoting Tvrtko Ursulin (2019-01-31 10:47:51)
> From: Tvrtko Ursulin
>
> We want to allow userspace to reconfigure the subslice configuration on a
> per context basis.
>
> This is required for the functional requirement of shutting down non-VME
> enabled sub-slices on Gen11 parts.
>
> To do so,
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev29)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
65d9322d71e7 drm/i915: Record the sseu configuration per-context & engine
0c2b9f0bab2f drm/i915/p
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev29)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Record the sseu configuration per-context & engine
-drivers/
On 30/01/2019 20:50, Chris Wilson wrote:
We currently track GPU memory usage inside VMA, such that we never
release memory used by the GPU until after it has finished accessing it.
However, we may want to track other resources aside from VMA, or we may
want to split a VMA into multiple independe
Quoting Tvrtko Ursulin (2019-01-31 11:25:10)
>
> On 30/01/2019 20:50, Chris Wilson wrote:
> > We currently track GPU memory usage inside VMA, such that we never
> > release memory used by the GPU until after it has finished accessing it.
> > However, we may want to track other resources aside from
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev29)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12106
Summary
---
On 30/01/2019 20:50, Chris Wilson wrote:
As soon as we detect that the active tracker is idle and we prepare to
call the retire callback, release the storage for our tree of
per-timeline nodes. We expect these to be infrequently usage and quick
s/usage/used/
to allocate, so there is little b
On 31/01/2019 11:32, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-31 11:25:10)
On 30/01/2019 20:50, Chris Wilson wrote:
We currently track GPU memory usage inside VMA, such that we never
release memory used by the GPU until after it has finished accessing it.
However, we may want to tr
On 30/01/2019 20:50, Chris Wilson wrote:
Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and hopefully better fragmentation reduction.
v2 where art thou? :)
v3: Nothing device specific left, it's just a slabcache that we can
make global.
Signed-off-by:
Quoting Tvrtko Ursulin (2019-01-31 11:39:46)
>
>
> On 30/01/2019 20:50, Chris Wilson wrote:
> > Wrap the active tracking for a GPU references in a slabcache for faster
> > allocations, and hopefully better fragmentation reduction.
> >
>
> v2 where art thou? :)
You killed v2!
> > v3: Nothing de
Quoting Tvrtko Ursulin (2019-01-31 12:47:51)
> From: Tvrtko Ursulin
>
> We want to allow userspace to reconfigure the subslice configuration on a
> per context basis.
>
> This is required for the functional requirement of shutting down non-VME
> enabled sub-slices on Gen11 parts.
>
> To do so,
On Tue, 29 Jan 2019, Jani Nikula wrote:
> This is obviously a backward/forward incompatible change. I've been
> told there are no systems out there using the field.
There are systems like that, in our CI too. Back to the drawing board.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Cent
Since we use the debugfs to recover the device after modifying the
i915.reset parameter, we need to be sure that we apply the reset and not
piggy-back onto a concurrent one in order for the parameter to take
effect.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +++
On wedging, we mark all executing requests as complete and all pending
requests completed as soon as they are ready. Before unwedging though we
wish to flush those pending requests prior to restoring default
execution, and so we must wait. Do so interruptibly as we do not provide
the EINTR graceful
Prevent concurrent set-wedge with ongoing resets (and vice versa) by
taking the same wedge_mutex around both operations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 71 ++-
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/drivers
When declaring the GPU wedged, we do need to hit the GPU with the reset
hammer so that its state matches our presumed state during cleanup. If
the reset fails, it fails, and we may be unhappy but wedged. However, if
we are testing our wedge/unwedged handling, the desync carries over into
the next t
Previously, we were able to rely on the recursive properties of
struct_mutex to allow us to serialise revoking mmaps and reacquiring the
FENCE registers with them being clobbered over a global device reset.
I then proceeded to throw out the baby with the bath water in order to
pursue a struct_mutex
On Wed, Jan 30, 2019 at 06:11:16PM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > > Some display controllers can be programmed to present non-black colors
> > > for pixels not covered by a
Prevent concurrent set-wedge with ongoing resets (and vice versa) by
taking the same wedge_mutex around both operations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 70 ++-
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/drivers
Prevent concurrent set-wedge with ongoing resets (and vice versa) by
taking the same wedge_mutex around both operations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 68 ++-
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/drivers
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset
URL : https://patchwork.freedesktop.org/series/56042/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Revoke mma
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset
URL : https://patchwork.freedesktop.org/series/56042/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12107
==
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset (rev3)
URL : https://patchwork.freedesktop.org/series/56042/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Rev
== Series Details ==
Series: drm/i915/psr: Execute the default PSR code path when setting
i915_edp_psr_debug (rev2)
URL : https://patchwork.freedesktop.org/series/56013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5515_full -> Patchwork_12099_full
==
On Thu, Jan 31, 2019 at 09:08:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 12:29:34PM +0530, Ramalingam C wrote:
> > Implements the
> > Waitqueue is created to wait for CP_IRQ
> > Signaling the CP_IRQ arrival through atomic variable.
> > For applicable DP HDCP2.2 msgs read
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset (rev3)
URL : https://patchwork.freedesktop.org/series/56042/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12108
===
Previously, we were able to rely on the recursive properties of
struct_mutex to allow us to serialise revoking mmaps and reacquiring the
FENCE registers with them being clobbered over a global device reset.
I then proceeded to throw out the baby with the bath water in order to
pursue a struct_mutex
When calling debugfs functions, they can now return error values if
something went wrong. If that happens, return a NULL as a *dentry to
the relay core instead of passing it an illegal pointer.
The relay core should be able to handle an illegal pointer, but add this
check to be safe.
Cc: Jani Ni
On 30/01/2019 02:19, Chris Wilson wrote:
Having introduced per-context seqno, we now have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that o
== Series Details ==
Series: series starting with drm/i915: Revoke mmaps and prevent access to fence
registers across reset (rev4)
URL : https://patchwork.freedesktop.org/series/56042/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Revoke mm
Op 29-01-2019 om 15:22 schreef Hans de Goede:
> We really want to have fastboot enabled by default to avoid an ugly
> modeset during boot.
>
> Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
> The intention is to enable it on older generations after it has seen more
> te
Quoting Tvrtko Ursulin (2019-01-31 13:19:31)
>
> On 30/01/2019 02:19, Chris Wilson wrote:
> > Having introduced per-context seqno, we now have a means to identity
> > progress across the system without feel of rollback as befell the
> > global_seqno. That is we can program a MI_SEMAPHORE_WAIT oper
On 1/31/2019 1:47 PM, Daniel Vetter wrote:
On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
On 1/31/2019 1:26 PM, Daniel Vetter wrote:
On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.
On CP_IRQ
== Series Details ==
Series: series starting with drm/i915: Revoke mmaps and prevent access to fence
registers across reset (rev4)
URL : https://patchwork.freedesktop.org/series/56042/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12109
=
== Series Details ==
Series: drm/i915: do not return invalid pointers as a *dentry
URL : https://patchwork.freedesktop.org/series/56044/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12110
Summary
---
On Fri, Dec 21, 2018 at 04:02:07PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915/ddi: Move DDI port detection to
> the corresponding helper (rev2)
> URL : https://patchwork.freedesktop.org/series/54341/
> State : success
Pushed patch 3 too from
On Mon, Jan 28, 2019 at 08:29:51PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
> URL : https://patchwork.freedesktop.org/series/55733/
> State : success
Pushed to -dinq, thanks for the review.
>
> == Summary ==
>
> CI
== Series Details ==
Series: drm: prefix header search paths with $(srctree)/
URL : https://patchwork.freedesktop.org/series/56020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5516_full -> Patchwork_12100_full
Summary
---
Read the RAPL power metrics courtesy of perf. Or your local HW
equivalent?
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_gpu_power.c | 106 +++
lib/igt_gpu_power.h | 51 +
lib/meson.build | 2 +
4 files
How much energy does spinning on a semaphore consume relative to plain
old spinning?
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 72 +-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/g
Include whether the scheduler is using HW semaphore assistance in our
pretty debug strings, and make the caps known for requires.
Signed-off-by: Chris Wilson
---
lib/i915/gem_scheduler.c | 22 +++---
lib/i915/gem_scheduler.h | 2 ++
2 files changed, 21 insertions(+), 3 deletions
Quoting Chris Wilson (2019-01-31 13:39:50)
> Quoting Tvrtko Ursulin (2019-01-31 13:19:31)
> >
> > On 30/01/2019 02:19, Chris Wilson wrote:
> > > Having introduced per-context seqno, we now have a means to identity
> > > progress across the system without feel of rollback as befell the
> > > global
Quoting Tvrtko Ursulin (2019-01-31 13:19:31)
>
> On 30/01/2019 02:19, Chris Wilson wrote:
> > Having introduced per-context seqno, we now have a means to identity
> > progress across the system without feel of rollback as befell the
> > global_seqno. That is we can program a MI_SEMAPHORE_WAIT oper
On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, they can now return error values if
> something went wrong. If that happens, return a NULL as a *dentry to
> the relay core instead of passing it an illegal pointer.
>
> The relay core should be
On Thu, Jan 24, 2019 at 01:40:48PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here is gvt-next stuff. This includes Coffeelake support for GVT,
> making kvmgt as self load module to have better dependence with
> vfio/mdev, with some const treatment and kernel type change.
ops, I also failed to let yo
On Thu, Jan 31, 2019 at 09:42:13AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We are mistakenly skipping transition watermarks on glk. Fix
> up the condition for glk, and toss in the w/a name from
> the database.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
>
On Thu, Jan 31, 2019 at 09:42:14AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Display w/a #1140 tells us we have to program the transition
> watermark to the minimum value on glk/cnl. Let's do that.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/dr
On Thu, Jan 31, 2019 at 09:42:15AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Display w/a #1141 is also known as WaIncreaseLatencyIPCEnabled.
> Add that to the comment.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 -
>
On Thu, Jan 31, 2019 at 09:42:16AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for
> early cnl steppings. Also switch the kbl/cfl case to check
> for IS_GEN9_BC() for brevity. It ends up being the same thing
> because IPC is disabled on
On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, they can now return error values if
> > something went wrong. If that happens, return a NULL as a *dentry to
> > the relay core in
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev13)
URL : https://patchwork.freedesktop.org/series/38254/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5517_full -> Patchwork_12101_full
Summary
---
**SUC
== Series Details ==
Series: series starting with [1/4] drm/i915: Enable transition watermarks for
glk
URL : https://patchwork.freedesktop.org/series/56025/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12103_full
===
SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
Signed-off-by: Gwan-gyeong Mun
---
include/drm/drm_dp_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_dp_helper.h
pipe_bpp value was assumed RGB therefore it was multiplied with 3.
But YCbCr 4:2:0 requires multiplier value to 1.5 therefore it divides
pipe_bpp to 2.
- RGB bpp = bpc x 3
- YCbCr 4:2:0 bpp = bpc x 1.5
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +-
drivers/gpu
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
This patches are RFC patches that add a VSC structure for handling
Pixel Encodi
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/56059/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
646f25f459f0 drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
-:20: WARNING:TABSTOP
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/56059/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
Okay!
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5520 -> Patchwork_12111
Summary
---
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev29)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12106_full
Summary
== Series Details ==
Series: series starting with drm/i915: Revoke mmaps and prevent access to fence
registers across reset (rev4)
URL : https://patchwork.freedesktop.org/series/56042/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12109_full
===
Quoting Patchwork (2019-01-31 22:33:09)
> Possible regressions
>
> * igt@gem_eio@unwedge-stress:
> - shard-snb: PASS -> FAIL
Old, random 2s delay.
> Possible fixes
>
> * igt@gem_eio@reset-stress:
> - shard-hsw: INCOMPLETE [fdo#103540] / [fdo#109
On Wed, 2019-01-30 at 16:58 -0800, José Roberto de Souza wrote:
> Changing the i915_edp_psr_debug was enabling, disabling or switching
> PSR version by directly calling intel_psr_disable_locked() and
> intel_psr_enable_locked(), what is not the default PSR path that will
> be executed by real users
== Series Details ==
Series: drm/i915: do not return invalid pointers as a *dentry
URL : https://patchwork.freedesktop.org/series/56044/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12110_full
Summar
Previous patch series/discussion was here:
https://lists.freedesktop.org/archives/dri-devel/2019-January/205504.html
Reviewed userspace (chromeos) is here:
https://chromium-review.googlesource.com/c/chromium/src/+/1278858
https://chromium-review.googlesource.com/c/chromiumos/platform/drm-te
1 - 100 of 133 matches
Mail list logo
