[Intel-gfx] ✓ Fi.CI.BAT: success for Disassociate display version from INTEL_GEN()

== Series Details == Series: Disassociate display version from INTEL_GEN() URL : https://patchwork.freedesktop.org/series/88198/ State : success == Summary == CI Bug Log - changes from CI_DRM_9878 -> Patchwork_19817 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Disassociate display version from INTEL_GEN()

== Series Details == Series: Disassociate display version from INTEL_GEN() URL : https://patchwork.freedesktop.org/series/88198/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Disassociate display version from INTEL_GEN()

== Series Details == Series: Disassociate display version from INTEL_GEN() URL : https://patchwork.freedesktop.org/series/88198/ State : warning == Summary == $ dim checkpatch origin/drm-tip 56a5c428be9d drm/i915/display: Convert gen5/gen6 tests to IS_IRONLAKE/IS_SANDYBRIDGE -:130:

[Intel-gfx] [PATCH 6/6] drm/i915/display: Simplify GLK display version tests

GLK has always been a bit of a special case since it reports INTEL_GEN() as 9, but has version 10 display IP. Now we can properly represent the display version as 10 and simplify the display generation tests throughout the display code. Aside from manually adding the version to the glk_info

[Intel-gfx] [PATCH 5/6] drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in i915_irq.c

Convert the display-specific usage of INTEL_GEN, while leaving the non-display usage as-is for now. In the near-future we'll probably want to think about moving display interrupt handling to its own file under the display/ directory. v2: - Use new IS_DISPLAY_VER() macro. Signed-off-by: Matt

[Intel-gfx] [PATCH 4/6] drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in intel_pm.c

Although most of the code in this file is display-related (watermarks), there's some functions that are not (e.g., clock gating). Thus we need to do the conversions to DISPLAY_VER() manually here rather than using Coccinelle. In the near-future we'll probably want to think about moving watermark

[Intel-gfx] [PATCH 1/6] drm/i915/display: Convert gen5/gen6 tests to IS_IRONLAKE/IS_SANDYBRIDGE

ILK is the only platform that we consider "gen5" and SNB is the only platform we consider "gen6." Add an IS_SANDYBRIDGE() macro and then replace numeric platform tests for these two generations with direct platform tests with the following Coccinelle semantic patch: @@ expression

[Intel-gfx] [PATCH 0/6] Disassociate display version from INTEL_GEN()

As noted in the beginning of the Xe-LPD and ADL-P patch series, going forward we need to track platforms' display versions separately from their graphics/media versions or "INTEL_GEN()" number. Since the first few patches that add DISPLAY_VER() and related conversions already have some good

[Intel-gfx] [PATCH 2/6] drm/i915: Add DISPLAY_VER() and related macros

Although we've long referred to platforms by a single "GEN" number, the hardware teams have recommended that we stop doing this since the various component IP blocks are going to start using independent number schemes with varying cadence. To support this, hardware platforms a bit down the road

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: uAPI clean-ups part 2

== Series Details == Series: drm/i915: uAPI clean-ups part 2 URL : https://patchwork.freedesktop.org/series/88196/ State : failure == Summary == Applying: drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE Applying: drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP Applying: drm/i915: Drop the

[Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj

I'd love to delete the SINGLE_TIMELINE API because it leaks an implementation detail of contexts through to the API and is something that userspace can do itself, trivially. Unfortunately, it's used by the media driver so we can't do that. We can, however, do the next-best thing which is to

[Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API

This API allows one context to grab bits out of another context upon creation. It can be used as a short-cut for setparam(getparam()) for things like I915_CONTEXT_PARAM_VM. However, it's never been used by any real userspace. It's used by a few IGT tests and that's it. Since it doesn't add any

[Intel-gfx] [PATCH 2/4] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP

The idea behind this param is to support OpenCL drivers with relocations because OpenCL reserves 0x0 for NULL and, if we placed memory there, it would confuse CL kernels. It was originally sent out as part of a patch series including libdrm [1] and Beignet [2] support. However, the libdrm and

[Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API has never been used by any real userspace. Signed-off-by: Jason Ekstrand --- drivers/gpu/drm/i915/Makefile | 1 - drivers/gpu/drm/i915/gem/i915_gem_context.c | 112 ++

[Intel-gfx] [PATCH 0/4] drm/i915: uAPI clean-ups part 2

This patch series is the second installment of my quest to clean up the i915 uAPI. The first three patches delete interfaces which have only ever been used by i-g-t and never any real userspace. In the case of NO_ZEROMAP, it's unclear exactly how this happened. There were userspace patches for

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Enable TPS3/4 on all platforms that support them

== Series Details == Series: drm/i915: Enable TPS3/4 on all platforms that support them URL : https://patchwork.freedesktop.org/series/88186/ State : success == Summary == CI Bug Log - changes from CI_DRM_9877_full -> Patchwork_19815_full

Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote: > On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote: > > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote: > > > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote: > > > > On Thu, Mar 18, 2021 at

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Fix enabled_planes bitmask

On Fri, Mar 19, 2021 at 11:20:07PM +0200, Ville Syrjälä wrote: > On Fri, Mar 19, 2021 at 02:17:18PM -0700, Navare, Manasi wrote: > > On Fri, Mar 05, 2021 at 05:36:05PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > The enabled_planes bitmask was supposed to track logically

Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote: > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote: > > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote: > > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote: > > > > So basically we see this

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Fix enabled_planes bitmask

On Fri, Mar 19, 2021 at 02:17:18PM -0700, Navare, Manasi wrote: > On Fri, Mar 05, 2021 at 05:36:05PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > The enabled_planes bitmask was supposed to track logically enabled > > planes (ie. fb!=NULL and crtc!=NULL), but instead we end up

Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote: > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote: > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote: > > > So basically we see this warning only in case of bigjoiner when > > > drm_atomic_check gets

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Fix enabled_planes bitmask

On Fri, Mar 05, 2021 at 05:36:05PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The enabled_planes bitmask was supposed to track logically enabled > planes (ie. fb!=NULL and crtc!=NULL), but instead we end up putting > even disabled planes into the bitmask since >

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs

On Fri, Mar 19, 2021 at 04:44:26PM -0400, Lyude Paul wrote: > > > > [...] > > > > I think it would work if we can make the retries configurable and set it > > > > to > > > > retries = total_timeout / platform_specific_timeout_per_retry > > > > > > > > where total_timeout would be

[Intel-gfx] ✗ Fi.CI.IGT: failure for Simplify intel_setup_outputs() (rev2)

== Series Details == Series: Simplify intel_setup_outputs() (rev2) URL : https://patchwork.freedesktop.org/series/87068/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9877_full -> Patchwork_19814_full Summary ---

Re: [Intel-gfx] [PATCH v2 02/23] drm/i915: Add DISPLAY_VER()

On Wed, Mar 17, 2021 at 07:45:00PM +0200, Jani Nikula wrote: > On Thu, 11 Mar 2021, Matt Roper wrote: > > Although we've long referred to platforms by a single "GEN" number, the > > hardware teams have recommended that we stop doing this since the > > various component IP blocks are going to

Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote: > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote: > > So basically we see this warning only in case of bigjoiner when > > drm_atomic_check gets called without setting the state->allow_modeset flag. > > Considering the

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs

On Fri, 2021-03-19 at 19:29 +0200, Imre Deak wrote: > On Fri, Mar 19, 2021 at 01:25:08PM -0400, Lyude Paul wrote: > > On Fri, 2021-03-19 at 01:17 +0200, Imre Deak wrote: > > > On Fri, Mar 19, 2021 at 12:04:54AM +0200, Almahallawy, Khaled wrote: > > > > On Thu, 2021-03-18 at 20:06 +0200, Imre Deak

Re: [Intel-gfx] [PATCH] drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcoders

On Fri, Mar 19, 2021 at 01:53:33PM +0200, Jani Nikula wrote: > Use the correct DSS CTL registers for ICL DSI transcoders. > > As a side effect, this also brings back the sanity check for trying to > use pipe DSC registers on pipe A on ICL. > > Fixes: 8a029c113b17 ("drm/i915/dp: Modify VDSC

Re: [Intel-gfx] [PATCH 2/3] drm/connector: Add helper to compare HDR metadata

On 2021-03-19 8:49 a.m., Maxime Ripard wrote: All the drivers that support the HDR metadata property have a similar function to compare the metadata from one connector state to the next, and force a mode change if they differ. All these functions run pretty much the same code, so let's turn it

Re: [Intel-gfx] [PATCH v4] vfio/pci: Add support for opregion v2.1+

On Tue, 2 Mar 2021 21:02:20 +0800 Fred Gao wrote: > Before opregion version 2.0 VBT data is stored in opregion mailbox #4, > However, When VBT data exceeds 6KB size and cannot be within mailbox #4 > starting from opregion v2.0+, Extended VBT region, next to opregion, is > used to hold the VBT

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them

== Series Details == Series: drm/i915: Enable TPS3/4 on all platforms that support them URL : https://patchwork.freedesktop.org/series/88186/ State : success == Summary == CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19815 Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for Simplify intel_setup_outputs() (rev2)

== Series Details == Series: Simplify intel_setup_outputs() (rev2) URL : https://patchwork.freedesktop.org/series/87068/ State : success == Summary == CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19814 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Read C0DRB3/C1DRB3 as 16 bits again

== Series Details == Series: series starting with [1/3] drm/i915: Read C0DRB3/C1DRB3 as 16 bits again URL : https://patchwork.freedesktop.org/series/88179/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9875_full -> Patchwork_19813_full

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Simplify intel_setup_outputs() (rev2)

== Series Details == Series: Simplify intel_setup_outputs() (rev2) URL : https://patchwork.freedesktop.org/series/87068/ State : warning == Summary == $ dim checkpatch origin/drm-tip c19909a676f0 drm/i915/display: move vbt check to intel_ddi_init() -:15: ERROR:GIT_COMMIT_ID: Please use git

[Intel-gfx] [PATCH] drm/i915: Enable TPS3/4 on all platforms that support them

From: Ville Syrjälä Stop using HBR2/3 support as a proxy for TPS3/4 support. The two are no longer 1:1 in the hardware, arguably they never were due to HSW ULX which does support TPS3 while being limited to HBR1. In more recent times GLK gained support for TPS4 while being limited to HBR2. And

[Intel-gfx] [PATCH v2 2/3] drm/i915/display: remove FIXME comment for intended feature

Direction on gen >= 9 was to stop using straps and rely on VBT indicating if the port is present or not. Remove FIXME comment since this will never be "fixed". Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_display.c | 6 -- 1 file changed, 6 deletions(-) diff --git

[Intel-gfx] [PATCH v2 3/3] drm/i915/display: remove strap checks from gen 9

Direction on gen9+ was to stop reading the straps and only rely on the VBT for marking the port presence. This happened while dealing with WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on skl straps").

[Intel-gfx] [PATCH v2 1/3] drm/i915/display: move vbt check to intel_ddi_init()

Since commit 45c0673aac97 ("drm/i915/bios: start using the intel_bios_encoder_data directly") we lookup the devdata for each port in intel_ddi_init() and just return if the port is not present in VBT (or if we didn't create a fake devdata for it if VBT is not available). So in intel_display.c we

[Intel-gfx] [PATCH v2 0/3] Simplify intel_setup_outputs()

First and second patches should be straightforward. Third patch is a tentative simplification that may break things in the presence of broken VBTs, but I'm feeling confident. Also, GLK should cover the case for display version 10. Lucas De Marchi (3): drm/i915/display: move vbt check to

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcoders

== Series Details == Series: drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcoders URL : https://patchwork.freedesktop.org/series/88169/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9875_full -> Patchwork_19811_full

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs

On Fri, Mar 19, 2021 at 01:25:08PM -0400, Lyude Paul wrote: > On Fri, 2021-03-19 at 01:17 +0200, Imre Deak wrote: > > On Fri, Mar 19, 2021 at 12:04:54AM +0200, Almahallawy, Khaled wrote: > > > On Thu, 2021-03-18 at 20:06 +0200, Imre Deak wrote: > > > > On Thu, Mar 18, 2021 at 07:49:13PM +0200,

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs

On Fri, 2021-03-19 at 01:17 +0200, Imre Deak wrote: > On Fri, Mar 19, 2021 at 12:04:54AM +0200, Almahallawy, Khaled wrote: > > On Thu, 2021-03-18 at 20:06 +0200, Imre Deak wrote: > > > On Thu, Mar 18, 2021 at 07:49:13PM +0200, Imre Deak wrote: > > > > On Thu, Mar 18, 2021 at 07:33:20PM +0200,

[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP 2.2 MST fixes (rev3)

== Series Details == Series: HDCP 2.2 MST fixes (rev3) URL : https://patchwork.freedesktop.org/series/87475/ State : success == Summary == CI Bug Log - changes from CI_DRM_9875_full -> Patchwork_19810_full Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used

Hi, On 3/1/21 4:43 PM, Hans de Goede wrote: > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down > displays gracefully on reboot"), the DSI panel on a Cherry Trail based > Predia Basic tablet would no longer properly light up after reboot. > > The backlight still turns back on

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Read C0DRB3/C1DRB3 as 16 bits again

== Series Details == Series: series starting with [1/3] drm/i915: Read C0DRB3/C1DRB3 as 16 bits again URL : https://patchwork.freedesktop.org/series/88179/ State : success == Summary == CI Bug Log - changes from CI_DRM_9875 -> Patchwork_19813

Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote: > So basically we see this warning only in case of bigjoiner when > drm_atomic_check gets called without setting the state->allow_modeset flag. Considering the code is 'WARN(!state->allow_modeset, ...' that fact should be rather

[Intel-gfx] [PATCH 3/3] drm/i915: Rewrite CL/CTG L-shaped memory detection

From: Ville Syrjälä Currently we try to detect a symmetric memory configurations using a magic DCC2_MODIFIED_ENHANCED_DISABLE bit. That bit is either only set on a very specific subset of machines or it just does not exist (it's not mentioned in any public chipset datasheets I've found). As it

[Intel-gfx] [PATCH 2/3] drm/i915: Give C0DRB3/C1DRB3 a _BW suffix

From: Ville Syrjälä These are the 965g/g45/g33 specific DRB registers. Give them a suitable suffix so we can add their counterparts for other platforms. Cc: Chris Wilson Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--

[Intel-gfx] [PATCH 1/3] drm/i915: Read C0DRB3/C1DRB3 as 16 bits again

From: Ville Syrjälä We've defined C0DRB3/C0DRB3 as 16 bit registers, so access them as such. Cc: Chris Wilson Fixes: 1c8242c3a4b2 ("drm/i915: Use unchecked writes for setting up the fences") Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- 1 file

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcoders

== Series Details == Series: drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcoders URL : https://patchwork.freedesktop.org/series/88169/ State : success == Summary == CI Bug Log - changes from CI_DRM_9875 -> Patchwork_19811

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/connector: Create a helper to attach the hdr_output_metadata property

== Series Details == Series: series starting with [1/3] drm/connector: Create a helper to attach the hdr_output_metadata property URL : https://patchwork.freedesktop.org/series/88173/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh

[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP 2.2 MST fixes (rev3)

== Series Details == Series: HDCP 2.2 MST fixes (rev3) URL : https://patchwork.freedesktop.org/series/87475/ State : success == Summary == CI Bug Log - changes from CI_DRM_9875 -> Patchwork_19810 Summary --- **SUCCESS** No

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: mst streams type1 capability check (rev2)

== Series Details == Series: drm/i915/hdcp: mst streams type1 capability check (rev2) URL : https://patchwork.freedesktop.org/series/86345/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9874_full -> Patchwork_19809_full

[Intel-gfx] [PATCH 1/3] drm/connector: Create a helper to attach the hdr_output_metadata property

All the drivers that implement HDR output call pretty much the same function to initialise the hdr_output_metadata property, and while the creation of that property is in a helper, every driver uses the same code to attach it. Provide a helper for it as well Signed-off-by: Maxime Ripard ---

[Intel-gfx] [PATCH 3/3] drm/vc4: Add HDR metadata property to the VC5 HDMI connectors

From: Dave Stevenson Now that we can export deeper colour depths, add in the signalling for HDR metadata. Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 53 ++ drivers/gpu/drm/vc4/vc4_hdmi.h | 3 ++ 2 files

[Intel-gfx] [PATCH 2/3] drm/connector: Add helper to compare HDR metadata

All the drivers that support the HDR metadata property have a similar function to compare the metadata from one connector state to the next, and force a mode change if they differ. All these functions run pretty much the same code, so let's turn it into an helper that can be shared across those

[Intel-gfx] [PATCH] drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcoders

Use the correct DSS CTL registers for ICL DSI transcoders. As a side effect, this also brings back the sanity check for trying to use pipe DSC registers on pipe A on ICL. Fixes: 8a029c113b17 ("drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave") References:

Re: [Intel-gfx] [PATCH 1/3] drm/i915/display: move vbt check to intel_ddi_init()

On Sat, 13 Feb 2021, Lucas De Marchi wrote: > On intel_ddi_init() we already check VBT if the port supports HDMI/DP > and bail out otherwise. Instad of checking if a single port is present > using VBT in intel_display.c, move the stronger check to > intel_ddi_init() and return early in case it's

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: mst streams type1 capability check (rev2)

== Series Details == Series: drm/i915/hdcp: mst streams type1 capability check (rev2) URL : https://patchwork.freedesktop.org/series/86345/ State : success == Summary == CI Bug Log - changes from CI_DRM_9874 -> Patchwork_19809 Summary

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix DP LTTPR link training mode initialization (rev2)

On Wed, Mar 17, 2021 at 10:34:24PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix DP LTTPR link training mode initialization (rev2) > URL : https://patchwork.freedesktop.org/series/88070/ > State : success Patchset pushed to drm-intel-next, thanks for the reports,

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hdcp: mst streams type1 capability check (rev2)

== Series Details == Series: drm/i915/hdcp: mst streams type1 capability check (rev2) URL : https://patchwork.freedesktop.org/series/86345/ State : warning == Summary == $ dim checkpatch origin/drm-tip bb93c668b788 drm/i915/hdcp: mst streams type1 capability check -:18: WARNING:BAD_SIGN_OFF:

[Intel-gfx] [PATCH v2 3/3] drm/i915/hdcp: return correct error code

hdcp2_enable_stream_encryption shouldn't get called in case of any port authentication or encryption error, though hdcp2_enable_stream_encryption checks for link encryption before enabling stream encryption and returns error but this return error code won't be correct in case of any error due to

[Intel-gfx] [PATCH v2 2/3] drm/i915/hdcp: link hdcp2 recovery on link enc stopped

When stream encryption enabling fails due to Link encryption status has stopped, prepare HDCP2 for recovery by disabling port authentication and encryption such that it can re-attempt port authentication and encryption. Cc: Ramalingam C Reviewed-by: Ankit Nautiyal Signed-off-by: Anshuman Gupta

[Intel-gfx] [PATCH v2 1/3] drm/i915/hdcp: HDCP2.2 MST Link failure recovery

DP MST Link Check performed only for the connector involved with HDCP port authentication and encryption, for other connector it simply returns link check with true and update the uevent. Therefore in case of HDCP 2.2 link failure, disable HDCP encryption and de-authenticate the port so next time

[Intel-gfx] [PATCH v2 0/3] HDCP 2.2 MST fixes

Rebased. Anshuman Gupta (3): drm/i915/hdcp: HDCP2.2 MST Link failure recovery drm/i915/hdcp: link hdcp2 recovery on link enc stopped drm/i915/hdcp: return correct error code drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +-- 1 file changed, 20 insertions(+), 6

Re: [Intel-gfx] [PATCH] drm: i915: Fix a typo

On Fri, 19 Mar 2021, Bhaskar Chowdhury wrote: > s/nothign/nothing/ > > Signed-off-by: Bhaskar Chowdhury Thanks, pushed. BR, Jani. > --- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[Intel-gfx] [PATCH] drm/i915/hdcp: mst streams type1 capability check

It requires to check streams type1 capability in mst topology by checking Rxinfo instead connector HDCP2.x capability in order to enforce type0 stream encryption in a mix of HDCP {1.x,2.x} mst topology. Rxcaps always shows HDCP 2.x capability of immediate downstream connector. Let's use Rxinfo