Re: [Intel-gfx] [PATCH 1/3] drm/i915/gen11+: First assume next platforms will inherit stuff

2019-03-08 Thread Lucas De Marchi
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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add new ICL PCI ID

2019-03-08 Thread Patchwork
== 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**

[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP2.2 Phase II (rev3)

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: split pll functions (rev2)

2019-03-08 Thread Patchwork
== 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*

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP2.2 Phase II (rev3)

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev3)

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/gen11+: First assume next platforms will inherit stuff

2019-03-08 Thread Patchwork
== 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 ==

[Intel-gfx] [PATCH v2 3/8] drm/i915: Attach content type property

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 5/8] drm/i915/sysfs: Node for hdcp srm

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 6/8] drm: Add CP downstream_info property

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 8/8] drm/i915: Populate downstream info for HDCP2.2

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 2/8] drm: Add Content protection type property

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 4/8] drm/i915: HDCP SRM parsing and revocation check

2019-03-08 Thread Ramalingam C
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/

[Intel-gfx] [PATCH v2 7/8] drm/i915: Populate downstream info for HDCP1.4

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 0/8] HDCP2.2 Phase II

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 1/8] drm/i915: debugfs: HDCP2.2 capability read

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 4/5] drm/i915/icl: split combo and tbt pll funcs

2019-03-08 Thread Lucas De Marchi
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

[Intel-gfx] [PATCH v2 1/5] drm/i915/icl: split combo and mg pll enable

2019-03-08 Thread Lucas De Marchi
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

[Intel-gfx] [PATCH v2 2/5] drm/i915/icl: split pll enable in three steps

2019-03-08 Thread Lucas De Marchi
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 ++-

[Intel-gfx] [PATCH v2 3/5] drm/i915/icl: split combo and mg pll disable

2019-03-08 Thread Lucas De Marchi
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

[Intel-gfx] [PATCH v2 5/5] drm/i915/icl: remove intel_dpll_is_combophy()

2019-03-08 Thread Lucas De Marchi
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

[Intel-gfx] [PATCH v2 0/5] drm/i915/icl: split pll functions

2019-03-08 Thread Lucas De Marchi
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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915: Add broadcast RGB property for DP MST

2019-03-08 Thread Patchwork
== 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 ==

Re: [Intel-gfx] [PATCH] drm/i915: relax debug BUG_ON() for closed context in hw_id pin

2019-03-08 Thread Zhenyu Wang
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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/19] i915/gem_ppgtt: Estimate resource usage and bail if it means swapping!

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix bit name in PP_STATUS register (rev2)

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add new ICL PCI ID

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] [PATCH v2] drm/i915: remove ICP_PP_CONTROL

2019-03-08 Thread Lucas De Marchi
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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/gen11+: First assume next platforms will inherit stuff

2019-03-08 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gen11+: First assume next platforms will inherit stuff

2019-03-08 Thread Rodrigo Vivi
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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gen11+: First assume next platforms will inherit stuff

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/gen11+: First assume next platforms will inherit stuff

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] [PATCH v2] drm/i915: Add new ICL PCI ID

2019-03-08 Thread José Roberto de Souza
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

[Intel-gfx] [PATCH 2/3] drm/i915: Move PCH_NOP to -1

2019-03-08 Thread Rodrigo Vivi
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

[Intel-gfx] [PATCH 3/3] drm/i915: Start using comparative INTEL_PCH_TYPE

2019-03-08 Thread Rodrigo Vivi
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

[Intel-gfx] [PATCH 1/3] drm/i915/gen11+: First assume next platforms will inherit stuff

2019-03-08 Thread Rodrigo Vivi
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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Sort ICL PCI IDs

2019-03-08 Thread Souza, Jose
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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add new ICL PCI ID

2019-03-08 Thread Rodrigo Vivi
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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Sort ICL PCI IDs

2019-03-08 Thread Rodrigo Vivi
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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Add broadcast RGB property for DP MST

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Zero initialize this_cpu in busywait_stop (rev2)

2019-03-08 Thread Patchwork
== 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/

Re: [Intel-gfx] [PATCH 2/5] drm/i915/icl: use a function pointer for pll_write when enabling

2019-03-08 Thread Ville Syrjälä
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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Add broadcast RGB property for DP MST

2019-03-08 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH] drm/i915: Zero initialize this_cpu in busywait_stop

2019-03-08 Thread Nick Desaulniers
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

[Intel-gfx] [PATCH 3/5] drm/i915: Remove the 8bpc shackles from DP MST

2019-03-08 Thread Ville Syrjala
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

[Intel-gfx] [PATCH 1/5] drm/i915: Add broadcast RGB property for DP MST

2019-03-08 Thread Ville Syrjala
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

[Intel-gfx] [PATCH 2/5] drm/i915: Expose the force_audio property with DP MST

2019-03-08 Thread Ville Syrjala
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

[Intel-gfx] [PATCH 5/5] drm/i915: Update TRANS_MSA_MISC for fastsets

2019-03-08 Thread Ville Syrjala
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

[Intel-gfx] [PATCH 4/5] drm/i915: Add max_bpc property for DP MST

2019-03-08 Thread Ville Syrjala
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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Suppress the "Failed to idle" warning for gem_eio

2019-03-08 Thread Patchwork
== 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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v6,1/9] drm/i915/psr: Remove PSR2 FIXME

2019-03-08 Thread Souza, Jose
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_

Re: [Intel-gfx] [PATCH v6 8/9] drm/i915: Force PSR1 exit when getting pipe CRC

2019-03-08 Thread Souza, Jose
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

[Intel-gfx] [PATCH i-g-t 12/19] drm-uapi: Import i915_drm.h upto 364df3d04d51

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 18/19] i915: Add gem_exec_balancer

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 11/19] kms_fence_pin_leak: Ask for the GPU before use

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 16/19] i915/gem_exec_whisper: debugfs/next_seqno is defunct

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 19/19] i915/gem_exec_balancer: Exercise bonded pairs

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 03/19] lib: Add GPU power measurement

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 04/19] i915/gem_exec_schedule: Measure semaphore power consumption

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 17/19] i915: Add gem_ctx_engines

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 05/19] i915/gem_exec_whisper: Measure total power consumed

2019-03-08 Thread Chris Wilson
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 ---

[Intel-gfx] [PATCH i-g-t 07/19] i915/gem_exec_nop: poll-sequential requires ordering between rings

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 14/19] igt/gem_ctx_switch: Exercise queues

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 01/19] i915/gem_ppgtt: Estimate resource usage and bail if it means swapping!

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 08/19] i915/gem_sync: Make switch-default asymmetric

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 06/19] i915/gem_exec_schedule: Verify that using HW semaphores doesn't block

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 10/19] i915/gem_exec_big: Add a single shot test

2019-03-08 Thread Chris Wilson
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/

[Intel-gfx] [PATCH i-g-t 09/19] i915/gem_ctx_param: Remove kneecapping

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 15/19] igt/gem_exec_whisper: Fork all-engine tests one-per-engine

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t 13/19] i915: Exercise creating context with shared GTT

2019-03-08 Thread Chris Wilson
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 +

[Intel-gfx] [PATCH i-g-t 02/19] lib/i915: Pretty print HW semaphores

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/7] drm/i915: Track active engines within a context

2019-03-08 Thread Patchwork
== 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 ===

[Intel-gfx] [PATCH i-g-t] i915: Add gem_ctx_engines

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDCP2.2 Phase II (rev2)

2019-03-08 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[]

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH v2 7/8] drm/i915: Populate downstream info for HDCP1.4

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 5/8] drm/i915/sysfs: Node for hdcp srm

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 2/8] drm: Add Content protection type property

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 4/8] drm/i915: HDCP SRM parsing and revocation check

2019-03-08 Thread Ramalingam C
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/

[Intel-gfx] [PATCH v2 6/8] drm: Add CP downstream_info property

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 3/8] drm/i915: Attach content type property

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 8/8] drm/i915: Populate downstream info for HDCP2.2

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 1/8] drm/i915: debugfs: HDCP2.2 capability read

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 0/8] HDCP2.2 Phase II

2019-03-08 Thread Ramalingam C
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

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[]

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDCP2.2 Content Type support

2019-03-08 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev3)

2019-03-08 Thread Patchwork
== 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 ===

Re: [Intel-gfx] [PATCH 08/13] drm/i915: Allow a context to define its set of engines

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/13] drm/i915: Suppress the "Failed to idle" warning for gem_eio (rev2)

2019-03-08 Thread Patchwork
== 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/

[Intel-gfx] [PATCH v2 1/8] drm/i915: debugfs: HDCP2.2 capability read

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 2/2] drm/i915: Attach content type property

2019-03-08 Thread Ramalingam C
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

[Intel-gfx] [PATCH v2 1/2] drm: Add Content protection type property

2019-03-08 Thread Ramalingam C
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

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Allow userspace to clone contexts on creation

2019-03-08 Thread Chris Wilson
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

[Intel-gfx] [PATCH v2 0/2] HDCP2.2 Content Type support

2019-03-08 Thread Ramalingam C
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_

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[]

2019-03-08 Thread Tvrtko Ursulin
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

Re: [Intel-gfx] [PATCH 08/13] drm/i915: Allow a context to define its set of engines

2019-03-08 Thread Tvrtko Ursulin
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)

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev3)

2019-03-08 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Allow userspace to clone contexts on creation

2019-03-08 Thread Tvrtko Ursulin
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

Re: [Intel-gfx] [PATCH 06/13] drm/i915: Allow contexts to share a single timeline across all engines

2019-03-08 Thread Tvrtko Ursulin
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

[Intel-gfx] [PATCH v2] drm/i915: Create/destroy VM (ppGTT) for use with contexts

2019-03-08 Thread Chris Wilson
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   2   >