On Fri, Mar 08, 2019 at 02:39:36PM -0800, Rodrigo Vivi wrote:
Given that every platform so far has had different oa configurations,
that looks to be a hasty assumption that future platforms will be fixed.
I know... But my hope is that at some point it gets stabilized.
Well, or at least start w
== Series Details ==
Series: drm/i915: Add new ICL PCI ID
URL : https://patchwork.freedesktop.org/series/57769/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5728_full -> Patchwork_12427_full
Summary
---
**SUCCESS**
== Series Details ==
Series: HDCP2.2 Phase II (rev3)
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5729 -> Patchwork_12430
Summary
---
**SUCCESS**
No regressio
== Series Details ==
Series: drm/i915/icl: split pll functions (rev2)
URL : https://patchwork.freedesktop.org/series/57618/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5729 -> Patchwork_12429
Summary
---
**SUCCESS*
== Series Details ==
Series: HDCP2.2 Phase II (rev3)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: debugfs: HDCP2.2 capability read
Okay!
Commit: drm: Add Content protection type propert
== Series Details ==
Series: HDCP2.2 Phase II (rev3)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
60917522d34f drm/i915: debugfs: HDCP2.2 capability read
009fe1f15b74 drm: Add Content protection type property
-:58: CHECK:LI
== Series Details ==
Series: series starting with [1/3] drm/i915/gen11+: First assume next platforms
will inherit stuff
URL : https://patchwork.freedesktop.org/series/57768/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5728_full -> Patchwork_12426_full
==
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
Binary Sysfs entry is created to pass the HDCP SRM table into
kerel for the HDCP authentication purpose.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_sysfs.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/dri
This patch adds a optional CP downstream info blob property to the
connectors. This enables the Userspace to read the information of HDCP
authenticated downstream topology.
Driver will updated this blob with all downstream information at the
end of the authentication.
In case userspace configures
Populates the downstream info for HDCP2.2 encryption also. On success
of encryption Blob is updated.
Additional two variable are added to downstream info blob. Such as
ver_in_force and content type.
v2:
s/cp_downstream/content_protection_downstream [daniel]
Signed-off-by: Ramalingam C
---
dr
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected dis
Implements the SRM table parsing for HDCP 1.4 and 2.2.
And also revocation check is added at authentication of HDCP1.4
and 2.2
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/
Implements drm blob property content_protection_downstream_info
property on HDCP capable connectors.
Downstream topology info is gathered across authentication stages
and stored in intel_hdcp. When HDCP authentication is complete,
new blob with latest downstream topology information is updated to
HDCP2.2 phase-II mojorly adds below features:
Addition of three connector properties
CP_Content_Type
CP_Downstream_Info
Addition of binary sysfs "hdcp_srm"
parsing for HDCP1.4 and 2.2 SRM table
Once HDCP1.4/2.2 authentication is comple
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
drivers/gpu/drm/i915/intel
Like was done for MG and combo, now finish the per-type split of the
vfunc by moving TBT out of the combo functions. Now we can completely
remove icl_pll_id_to_enable_reg() since each PLL type passes all the
information via arguments.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel
Let's start using the vfuncs to differentiate MG and Combo PLLs. The end
goal is to decouple the type of the PLL from the IDs since the latter
are likely to change from one platform to another. This also makes the
code easier to read by not having lots of if/else chains on leaf
functions.
Signed-o
Create separate functions to 1) enable power, 2) write pll config, and
3) enable pll. Doing this it makes it easier to share the functions for
the different PLL types by passing the right arguments.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 56 ++-
Like was done in the enable case, split the implementation of the
disable for MG and Combo PLLs.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 30 ---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp
This is only used in intel_display() and shouldn't be needed there.
We don't want to keep converting from pll id to pll type so just remove
the function.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_display.c | 3 ---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 5 -
2 files cha
v2 of https://patchwork.freedesktop.org/series/57618/
Only difference is that patch 2 got replaced with a different one.
Instead of passing a function pointer to write the pll, split the
function in three and pass the different arguments for each type of
plls as suggested by Ville. I think this is
== Series Details ==
Series: series starting with [1/5] drm/i915: Add broadcast RGB property for DP
MST
URL : https://patchwork.freedesktop.org/series/57766/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5728_full -> Patchwork_12424_full
==
On 2019.03.08 08:31:51 +, Chris Wilson wrote:
> Quoting Zhenyu Wang (2019-03-08 07:52:37)
> > Current GVT created context is marked closed as not to be used for
> > host user. But its hw_id should still be used. So this is to relax
> > debug BUG_ON() in __i915_gem_context_pin_hw_id() for GVT co
== Series Details ==
Series: series starting with [01/19] i915/gem_ppgtt: Estimate resource usage
and bail if it means swapping!
URL : https://patchwork.freedesktop.org/series/57764/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5729 -> IGTPW_2581
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix bit name in PP_STATUS register
(rev2)
URL : https://patchwork.freedesktop.org/series/57454/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5729 -> Patchwork_12428
== Series Details ==
Series: drm/i915: Add new ICL PCI ID
URL : https://patchwork.freedesktop.org/series/57769/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5728 -> Patchwork_12427
Summary
---
**SUCCESS**
No regr
This register was placed in the middle of the PP_STATUS definition
instead of together with the PP_CONTROL where it should. Since it's not
used and there are no current plans to use it, just remove the
definition.
v2: remove the define rather than moving it.
Signed-off-by: Lucas De Marchi
---
d
== Series Details ==
Series: series starting with [1/3] drm/i915/gen11+: First assume next platforms
will inherit stuff
URL : https://patchwork.freedesktop.org/series/57768/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5728 -> Patchwork_12426
On Fri, Mar 08, 2019 at 10:23:20PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2019-03-08 21:42:58)
> > This exactly same approach was already used from gen9
> > to gen10 and from gen10 to gen11. Let's also use it
> > for gen11+.
> >
> > Let's first assume that we inherit a similar platform
Quoting Rodrigo Vivi (2019-03-08 21:42:58)
> This exactly same approach was already used from gen9
> to gen10 and from gen10 to gen11. Let's also use it
> for gen11+.
>
> Let's first assume that we inherit a similar platform
> and than we apply the differences on top.
>
> Different from the previ
== Series Details ==
Series: series starting with [1/3] drm/i915/gen11+: First assume next platforms
will inherit stuff
URL : https://patchwork.freedesktop.org/series/57768/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gen11+: First assume
A new PCI ID for ICL was added to BSpec, lets keep it in tight sync
as ICL is not protected by the alpha support flag anymore.
v2: Keeping BSpec order(Rodrigo)
BSepc: 21141
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
include/drm/i915_pciids.h | 3 ++-
1 file changed, 2 i
So we can later use PCH >= comparisons. The ultimate goal
is to make it easier for us to introduce a new platform
with south display engine on PCH just by reusing the previous
one.
Suggested-by: Lucas De Marchi
Cc: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
Reviewed-by: Lucas De Marchi
---
d
In order to make it easier to bring up new platforms
without having to take care about all corner cases
that was previously taken care for previous platforms
we already use comparative INTEL_GEN statements.
Let's start doing the same with PCH.
The only caveats are:
- less-than comparisons need t
This exactly same approach was already used from gen9
to gen10 and from gen10 to gen11. Let's also use it
for gen11+.
Let's first assume that we inherit a similar platform
and than we apply the differences on top.
Different from the previous attempts this will be
done this time with coccinelle. W
On Fri, 2019-03-08 at 13:17 -0800, Rodrigo Vivi wrote:
> On Thu, Mar 07, 2019 at 12:56:55PM -0800, José Roberto de Souza
> wrote:
> > Lets keep it sorted to make easy to spot missing PCI IDs.
>
> Hmm... In my opinion leaving it as the identical order
> of the spec is the way to make it easier to s
On Thu, Mar 07, 2019 at 12:56:56PM -0800, José Roberto de Souza wrote:
> A new PCI ID for ICL was added to BSpec, lets keep it in tight sync
> as ICL is not protected by the alpha support flag anymore.
>
> BSepc: 21141
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> include/dr
On Thu, Mar 07, 2019 at 12:56:55PM -0800, José Roberto de Souza wrote:
> Lets keep it sorted to make easy to spot missing PCI IDs.
Hmm... In my opinion leaving it as the identical order
of the spec is the way to make it easier to spot if we missed
something...
Otherwise when reviewing I have to s
== Series Details ==
Series: series starting with [1/5] drm/i915: Add broadcast RGB property for DP
MST
URL : https://patchwork.freedesktop.org/series/57766/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5728 -> Patchwork_12424
== Series Details ==
Series: drm/i915: Zero initialize this_cpu in busywait_stop (rev2)
URL : https://patchwork.freedesktop.org/series/57718/
State : failure
== Summary ==
Applying: drm/i915: Zero initialize this_cpu in busywait_stop
error: sha1 information is lacking or useless
(drivers/gpu/
On Tue, Mar 05, 2019 at 05:26:33PM -0800, Lucas De Marchi wrote:
> This allows us to share the icl_pll_enable() between the different types
> of PLL while allowing the caller to differentiate how to write the
> registers.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_dpll
== Series Details ==
Series: series starting with [1/5] drm/i915: Add broadcast RGB property for DP
MST
URL : https://patchwork.freedesktop.org/series/57766/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3a9a15b38816 drm/i915: Add broadcast RGB property for DP MST
8f0b667de193
On Fri, Mar 8, 2019 at 12:27 AM Chris Wilson wrote:
>
> Quoting Nathan Chancellor (2019-03-08 01:20:24)
> > When building with -Wsometimes-uninitialized, Clang warns:
> >
> > drivers/gpu/drm/i915/i915_request.c:1032:6: warning: variable 'this_cpu'
> > is used uninitialized whenever '&&' condition
From: Ville Syrjälä
Allow DP MST to output any color depth. This means deep color as
well as falling back to 6bpc if we would otherwise require too
much bandwidth.
TODO: We should probably extend bw_contstrained scheme to force
all streams on the link to 6bpc if we can't fit the new stream(s)
ot
From: Ville Syrjälä
Add the "Broadcast RGB" property to MST connectors, and implement
the same logic for it as we have in the SST code.
Cc: Ivan Vlk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108821
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp_mst.c | 29
From: Ville Syrjälä
We already expose the force_audio property with SST. Do the same
with MST.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp_mst.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gp
From: Ville Syrjälä
Update the DP MSA MISC bits for fastsets. This is needed
when we change between limited and full range RGB output.
On HSW+ changing limited_range does not currently result in a
full modeset since we have don't have the readout code for it
(for DP we could, and probably should
From: Ville Syrjälä
Allow the user to limit the output bpc with DP MST.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index df8b396cbcdc..23ca2a
== Series Details ==
Series: drm/i915: Suppress the "Failed to idle" warning for gem_eio
URL : https://patchwork.freedesktop.org/series/57740/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5722_full -> Patchwork_12418_full
And pushed to dinq
On Fri, 2019-03-08 at 05:33 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v6,1/9] drm/i915/psr: Remove PSR2 FIXME
> URL : https://patchwork.freedesktop.org/series/57716/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_
On Thu, 2019-03-07 at 16:00 -0800, José Roberto de Souza wrote:
> If PSR1 is active when pipe CRC is enabled the CRC calculations will
> be inhibit by the transition to low power states that PSR1 brings.
> So lets force a PSR1 exit and as soon as pipe CRC is enabled it will
> block PSR1 activation
commit 364df3d04d51f0aad13b898f3dffca8c2d03d2b3 (HEAD)
Author: Chris Wilson
Date: Fri Jun 30 13:40:53 2017 +0100
drm/i915: Allow specification of parallel execbuf
Signed-off-by: Chris Wilson
---
include/drm-uapi/i915_drm.h | 352
1 file changed, 279 i
Exercise the in-kernel load balancer checking that we can distribute
batches across the set of ctx->engines to avoid load.
Signed-off-by: Chris Wilson
---
tests/Makefile.am | 1 +
tests/Makefile.sources | 1 +
tests/i915/gem_exec_balancer.c | 627
Check that the GPU even exists before submitting a batch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109589
Signed-off-by: Chris Wilson
---
tests/kms_fence_pin_leak.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/kms_fence_pin_leak.c b/tests/kms_fence_pin_leak.c
index 62c
We removed next_seqno in 5.1, so time to wave goodbye.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 12
1 file changed, 12 deletions(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index d5afc8119..61b8d6dac 100644
--- a/tests/i915/g
The submit-fence + load_balancing apis allow for us to execute a named
pair of engines in parallel; that this by submitting a request to one
engine, we can then use the generated submit-fence to submit a second
request to another engine and have it execute at the same time.
Furthermore, by specifyi
Read the RAPL power metrics courtesy of perf. Or your local HW
equivalent?
v2: uselocale()
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_gpu_power.c | 114 +++
lib/igt_gpu_power.h | 59 ++
lib/meson.build
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
To exercise the new I915_CONTEXT_PARAM_ENGINES and interactions with
gem_execbuf().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
tests/Makefile.sources | 1 +
tests/i915/gem_ctx_engines.c | 368 +++
tests/meson.build| 1
Show the total power consumed across all the whispers.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index 0b15fe431..6c3b53756 100644
---
In order to correctly serialise the order of execution between rings, we
need to flag the scratch address as being written. Make it so.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_nop.c | 152 +-
1 file changed, 133 insertions(+), 19 deletions(-)
diff
Queues are a form of contexts that share vm and enfore a single timeline
across all engines. Test switching between them, just like ordinary
contexts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_switch.c | 75 +++--
1 file changed, 55 insertions(+), 20 dele
fi-kbl-guc's swap ran dry while running blt-vs-render-ctxN, which is
midly concerning but conceivable as we never checked there was enough
memory to run the test to begin with.
Each child needs to keep its own surface and possible a pair of logical
contexts (one for rcs and one for bcs) so check t
To make the demonstration of the cheeky preemption more impactful, make
the second context a nop to contrast the first being 1024
MI_STORE_DWORD_IMM. Then if we execute and wait on the second context
before executing the first, the client latency is even more drastically
reduced.
To more clearly s
We may use HW semaphores to schedule nearly-ready work such that they
are already spinning on the GPU waiting for the completion on another
engine. However, we don't want for that spinning task to actually block
any real work should it be scheduled.
Signed-off-by: Chris Wilson
---
tests/i915/gem
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
tests/i915/
The invalid set/get tests do not serve the purpose of detecting whether
or not invalid parameters are indeed detect correctly -- simply because
the kernel is the arbiter of what is invalid and this test second
guesses that and is wrong.
The intent of this test was to ensure that we didn't include
Add a new mode for some more stress, submit the all-engines tests
simultaneously, a stream per engine.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_exec_whisper.c b/te
v2: Test each shared context is its own timeline and allows request
reordering between shared contexts.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michal Wajdeczko
---
lib/i915/gem_context.c| 68 +++
lib/i915/gem_context.h| 13 +
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
== Series Details ==
Series: series starting with [CI,1/7] drm/i915: Track active engines within a
context
URL : https://patchwork.freedesktop.org/series/57738/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5722_full -> Patchwork_12417_full
===
To exercise the new I915_CONTEXT_PARAM_ENGINES and interactions with
gem_execbuf().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
tests/Makefile.sources | 1 +
tests/i915/gem_ctx_engines.c | 368 +++
tests/meson.build| 1
== Series Details ==
Series: HDCP2.2 Phase II (rev2)
URL : https://patchwork.freedesktop.org/series/57232/
State : failure
== Summary ==
Series 57232 revision 2 Test-with: 20190308163049.9016-2-ramalinga...@intel.com
not found
___
Intel-gfx mailing
Quoting Tvrtko Ursulin (2019-03-08 16:31:51)
> Looks okay. But one more thing is needed:
>
> https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=media&id=38266bfe99469de9e13774a13fa641c377988c67
drm/i915: Allow SSEU configuration to be set on virtual engine
/* Only render engine s
Implements drm blob property content_protection_downstream_info
property on HDCP capable connectors.
Downstream topology info is gathered across authentication stages
and stored in intel_hdcp. When HDCP authentication is complete,
new blob with latest downstream topology information is updated to
Binary Sysfs entry is created to pass the HDCP SRM table into
kerel for the HDCP authentication purpose.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_sysfs.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/dri
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected dis
Implements the SRM table parsing for HDCP 1.4 and 2.2.
And also revocation check is added at authentication of HDCP1.4
and 2.2
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/
This patch adds a optional CP downstream info blob property to the
connectors. This enables the Userspace to read the information of HDCP
authenticated downstream topology.
Driver will updated this blob with all downstream information at the
end of the authentication.
In case userspace configures
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
Populates the downstream info for HDCP2.2 encryption also. On success
of encryption Blob is updated.
Additional two variable are added to downstream info blob. Such as
ver_in_force and content type.
v2:
s/cp_downstream/content_protection_downstream [daniel]
Signed-off-by: Ramalingam C
---
dr
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
drivers/gpu/drm/i915/intel
HDCP2.2 phase-II mojorly adds below features:
Addition of three connector properties
CP_Content_Type
CP_Downstream_Info
Addition of binary sysfs "hdcp_srm"
parsing for HDCP1.4 and 2.2 SRM table
Once HDCP1.4/2.2 authentication is comple
Quoting Tvrtko Ursulin (2019-03-08 16:31:51)
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > Allow the user to specify a local engine index (as opposed to
> > class:index) that they can use to refer to a preset engine inside the
> > ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENG
== Series Details ==
Series: HDCP2.2 Content Type support
URL : https://patchwork.freedesktop.org/series/57757/
State : failure
== Summary ==
Series 57757 revision 1 Test-with: 20190308163049.9016-2-ramalinga...@intel.com
not found
___
Intel-gfx ma
== Series Details ==
Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev3)
URL : https://patchwork.freedesktop.org/series/57619/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5724 -> Patchwork_12420
===
Quoting Tvrtko Ursulin (2019-03-08 16:27:22)
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > Over the last few years, we have debated how to extend the user API to
> > support an increase in the number of engines, that may be sparse and
> > even be heterogeneous within a class (not all video deco
== Series Details ==
Series: series starting with [01/13] drm/i915: Suppress the "Failed to idle"
warning for gem_eio (rev2)
URL : https://patchwork.freedesktop.org/series/57742/
State : failure
== Summary ==
Applying: drm/i915: Suppress the "Failed to idle" warning for gem_eio
Applying: drm/
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
drivers/gpu/drm/i915/intel
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected dis
Quoting Tvrtko Ursulin (2019-03-08 16:13:56)
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > A usecase arose out of handling context recovery in mesa, whereby they
> > wish to recreate a context with fresh logical state but preserving all
> > other details of the original. Currently, they create
This series adds a property called Content_protection_type
onto HDCP2.2 capable intel connectors.
Using this property userspace app can set the Content Type
of the stream as per HDCP2.2 specification.
v2:
Separated from the other patches for SRM and Downstream_info
Restrictions at atomic_set_
On 08/03/2019 14:12, Chris Wilson wrote:
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on vi
On 08/03/2019 14:12, Chris Wilson wrote:
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance)
== Series Details ==
Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev3)
URL : https://patchwork.freedesktop.org/series/57619/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e6f80925d5d2 drm/i915/icl: Fix CRC mismatch error for DP link layer complian
On 08/03/2019 14:12, Chris Wilson wrote:
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy
On 08/03/2019 14:12, Chris Wilson wrote:
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the use
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
v2: Replace global barrier for swapping over the ppgtt and tlbs with a
local context barrier (Tvrtko)
v3: serialise
1 - 100 of 170 matches
Mail list logo