Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

On Mon, Apr 02, 2018 at 05:20:22PM +0530, Ramalingam C wrote: > As per DP spec when R0 mismatch is detected, HDCP source supported > re-read the R0 atleast twice. > > And For HDMI and DP minimum wait required for the R0 availability is > 100mSec. So this patch changes the wait time to 100mSec but

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Read Vprime thrice incase of mismatch

On Mon, Apr 02, 2018 at 03:40:32PM +0530, Ramalingam C wrote: > In case of V prime mismatch, DP HDCP spec mandates the re-read of > Vprime atleast twice. > > This patch needed for DP HDCP1.4 CTS Test: 1B-05. > > v2: > Moved the V' validation into a function for retry. [Sean Paul] > v3: >

[Intel-gfx] [PATCH v2] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

The following call trace may exist in linux guest dmesg when guest i915 driver is unloaded. [ 90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space: range [0x0 - 0x0] 0 KiB. [ 90.776621] BUG: unable to handle kernel NULL pointer dereference at 00c0 [ 90.776691] IP:

Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of 4 for NV12

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Thursday, March 29, 2018 5:03 PM > To: Maarten Lankhorst > Cc: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Subject: Re:

[Intel-gfx] [PATCH v19 09/18] drm/i915/skl: split skl_compute_ddb function

From: Mahesh Kumar This patch splits skl_compute_wm/ddb functions into two parts. One adds all affected pipes after the commit to atomic_state structure and second part does compute the DDB. v2: Added reviewed by tag from Shashank Sharma v3: Added reviewed by from

[Intel-gfx] [PATCH v19 10/18] drm/i915: Display WA 827

Display WA 827 applies to GEN9 (excluede GLK) and CNL. Switching the plane format from NV12 to RGB and leaving system idle results in display underrun and corruption. WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL register for the pipe in which NV12 plane is enabled. v2: Addressed

[Intel-gfx] [PATCH v19 12/18] drm/i915: Set scaler mode for NV12

From: Chandra Konduru This patch sets appropriate scaler mode for NV12 format. In this mode, skylake scaler does either chroma-upsampling or chroma-upsampling and resolution scaling v2: Review comments from Ville addressed NV12 case to be checked first for setting the

[Intel-gfx] [PATCH v19 00/18] Add NV12 support

This patch series is adding NV12 support for Broxton display after rebasing on latest drm-tip. Initial series of the patches can be found here: https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html Previous revision history: The first version of patches were reviewed when floated

[Intel-gfx] [PATCH v19 02/18] drm/i915/skl+: refactor WM calculation for NV12

From: Mahesh Kumar Current code calculates DDB for planar formats in such a way that we store DDB of plane-0 in plane 1 & vice-versa. In order to make this clean this patch refactors WM/DDB calculation for NV12 planar formats. v2: Addressed review comments by Maarten

[Intel-gfx] [PATCH v19 16/18] drm/i915: Add NV12 as supported format for sprite plane

From: Chandra Konduru This patch adds NV12 to list of supported formats for sprite plane. v2: Rebased (me) v3: Review comments by Ville addressed - Removed skl_plane_formats_with_nv12 and added NV12 case in existing skl_plane_formats - Added the 10bpc RGB formats

[Intel-gfx] [PATCH v19 13/18] drm/i915: Update format_is_yuv() to include NV12

From: Chandra Konduru This patch adds NV12 to format_is_yuv() function for sprite planes. v2: -Use intel_ prefix for format_is_yuv (Ville) v3: Rebased (me) v4: Rebased and addressed review comments from Clinton A Taylor. "static function in intel_sprite.c is not

Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size mult of 4 for NV12

> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Thursday, March 29, 2018 2:19 PM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v18 18/18] drm/i915: Keep plane size

[Intel-gfx] [PATCH v19 14/18] drm/i915: Upscale scaler max scale for NV12

From: Chandra Konduru This patch updates scaler max limit support for NV12 v2: Rebased (me) v3: Rebased (me) v4: Missed the Tested-by/Reviewed-by in the previous series Adding the same to commit message in this version. v5: Addressed review comments from Ville and

[Intel-gfx] [PATCH v19 01/18] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

From: Mahesh Kumar skl_wm_values struct contains values of pipe/plane DDB only. so rename it for better readability of code. Similarly skl_copy_wm_for_pipe copies DDB values. s/skl_wm_values/skl_ddb_values s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe Changes since V1:

[Intel-gfx] [PATCH v19 03/18] drm/i915/skl+: add NV12 in skl_format_to_fourcc

From: Mahesh Kumar Add support of recognizing DRM_FORMAT_NV12 from plane_format register value. v2: Added reviewed by tag from Mika Kahola v3: Added reviewed by from Juha-Pekka Heikkila v4: Rebased the series Reviewed-by: Juha-Pekka Heikkila

[Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

As per display WA 1106, to avoid corruption issues NV12 plane height needs to be multiplier of 4 We expect the src dimensions to be multiplier of 4 We fail the case where src width or height is not multiple of 4 for NV12. We also set the scaler destination height and width to be multiple of 4.

[Intel-gfx] [PATCH v19 17/18] drm/i915: Add NV12 support to intel_framebuffer_init

From: Chandra Konduru This patch adds NV12 as supported format to intel_framebuffer_init and performs various checks. v2: -Fix an issue in checks added (Chandra Konduru) v3: rebased (me) v4: Review comments by Ville addressed Added platform check for NV12 in

[Intel-gfx] [PATCH v19 05/18] drm/i915/skl+: NV12 related changes for WM

From: Mahesh Kumar NV12 requires WM calculation for UV plane as well. UV plane WM should also fulfill all the WM related restrictions. v2: Addressed review comments from Shashank Sharma. v3: Addressed review comments from Shashank Sharma Changed plane_num to plane_id

[Intel-gfx] [PATCH v19 06/18] drm/i915/skl+: pass skl_wm_level struct to wm compute func

From: Mahesh Kumar This patch passes skl_wm_level structure itself to watermark computation function skl_compute_plane_wm function (instead of its internal parameters). It reduces number of arguments required to be passed. v2: Addressed review comments by Shashank

[Intel-gfx] [PATCH v19 15/18] drm/i915: Add NV12 as supported format for primary plane

From: Chandra Konduru This patch adds NV12 to list of supported formats for primary plane v2: Rebased (Chandra Konduru) v3: Rebased (me) v4: Review comments by Ville addressed Removed the skl_primary_formats_with_nv12 and added NV12 case in existing

[Intel-gfx] ✗ Fi.CI.IGT: failure for HDCP1.4 fixes (rev5)

== Series Details == Series: HDCP1.4 fixes (rev5) URL : https://patchwork.freedesktop.org/series/38978/ State : failure == Summary == Possible new issues: Test drv_module_reload: Subgroup basic-no-display: pass -> INCOMPLETE (shard-snb) Test kms_cursor_crc:

Re: [Intel-gfx] [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

On Fri, 30 Mar 2018 16:01:31 +0100 Chris Wilson wrote: > Across suspend, we may see a very large drift in timestamps if the sched > clock is unstable, prompting the global trace's ringbuffer code to warn > and suggest switching to the global clock. Preempt this request

[Intel-gfx] [PATCH v3 0/4] HDCP1.4 fixes

First two patches needed for below DP HDCP compliance tests 1A-06 and 1B-05 Third patch fixes the HDCP1.4 Key loadability check. where as fourth one fixes the downstream device count read. Fix for HDMI HDCP1.4 CTS tests: 1A-04 and 1A-07a are functional. But the change from v2, as

[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP1.4 fixes (rev4)

== Series Details == Series: HDCP1.4 fixes (rev4) URL : https://patchwork.freedesktop.org/series/38978/ State : success == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: dmesg-warn -> PASS (shard-snb) Known issues:

[Intel-gfx] [PATCH v4 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

As per DP spec when R0 mismatch is detected, HDCP source supported re-read the R0 atleast twice. And For HDMI and DP minimum wait required for the R0 availability is 100mSec. So this patch changes the wait time to 100mSec but retries twice with the time interval of 100mSec for each attempt. This

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)

== Series Details == Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3) URL : https://patchwork.freedesktop.org/series/40851/ State : warning == Summary == $ dim checkpatch origin/drm-tip b0bcc0a1ee76 drm/i915: Move vgpu balloon info into i915_virtual_gpu struct

[Intel-gfx] [PATCH v19 11/18] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

If the fb format is YUV, enable the plane CSC mode bits for the conversion. v2: Addressed review comments from Shashank Sharma Alignment issue fixed in i915_reg.h v3: Adding Reviewed By from Shashank Sharma v4: Rebased the patch. As part of rebasing, re-using the color series defines which are

[Intel-gfx] [PATCH v19 04/18] drm/i915/skl+: support verification of DDB HW state for NV12

From: Mahesh Kumar For YUV 420 Planar formats like NV12, buffer allocation is done for Y and UV surfaces separately. For NV12 plane formats, the UV buffer allocation must be programmed in the Plane Buffer Config register and the Y buffer allocation must be programmed in

[Intel-gfx] [PATCH v19 07/18] drm/i915/skl+: make sure higher latency level has higher wm value

From: Mahesh Kumar DDB allocation optimization algorithm requires/assumes ddb allocation for any memory C-state level DDB value to be as high as level below the current level. Render decompression requires level WM to be as high as wm level-0. This patch fulfils both the

[Intel-gfx] [PATCH v19 08/18] drm/i915/skl+: nv12 workaround disable WM level 1-7

From: Mahesh Kumar Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A) Hardware sometimes fails to wake memory from pkg C states fetching the last few lines of planar YUV 420 (NV12) planes. This causes intermittent underflow and corruption. WA: Disable package C

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support (rev7)

== Series Details == Series: Add NV12 support (rev7) URL : https://patchwork.freedesktop.org/series/39670/ State : warning == Summary == $ dim checkpatch origin/drm-tip b485c8e3c47f drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values aba1b53bed73 drm/i915/skl+: refactor WM

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Check hdcp key loadability

On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote: On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote: HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk is enabled. Using the I915 power well infrastruture, above requirement is verified. This patch

[Intel-gfx] [PATCH v3 4/4] drm/i915: Fix reading downstream dev count

In both HDMI and DP, device count is represented by 6:0 bits of a register(BInfo/Bstatus) So macro for bitmasking the device_count is fixed(0x3F->0x7F). v3: Retained the Rb-ed Signed-off-by: Ramalingam C cc: Sean Paul Reviewed-by: Sean Paul

[Intel-gfx] [PATCH v3 2/4] drm/i915: Read Vprime thrice incase of mismatch

In case of V prime mismatch, DP HDCP spec mandates the re-read of Vprime atleast twice. This patch needed for DP HDCP1.4 CTS Test: 1B-05. v2: Moved the V' validation into a function for retry. [Sean Paul] v3: Removed Inline keyword and DRM_DEBUG_KMS are used [Sean Paul] Signed-off-by:

[Intel-gfx] [PATCH v3 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

As per DP spec when R0 mismatch is detected, HDCP source supported re-read the R0 atleast twice. And For HDMI and DP minimum wait required for the R0 availability is 100mSec. So this patch changes the wait time to 100mSec but retries twice with the time interval of 100mSec for each attempt. This

[Intel-gfx] ✓ Fi.CI.BAT: success for Add NV12 support (rev7)

== Series Details == Series: Add NV12 support (rev7) URL : https://patchwork.freedesktop.org/series/39670/ State : success == Summary == Series 39670v7 Add NV12 support https://patchwork.freedesktop.org/api/1.0/series/39670/revisions/7/mbox/ fi-bdw-5557u total:285 pass:264 dwarn:0

[Intel-gfx] [PATCH v3 3/4] drm/i915: Check hdcp key loadability

HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk is enabled. Using the I915 power well infrastruture, above requirement is verified. This patch enables the hdcp initialization for HSW, BDW, and BXT. v2: Choose the PW# based on the platform. v3: No Changes.

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

On Thursday 29 March 2018 08:05 PM, Sean Paul wrote: On Thu, Mar 29, 2018 at 07:39:05PM +0530, Ramalingam C wrote: As per DP spec when R0 mismatch is detected, HDCP source supported re-read the R0 atleast twice. And For HDMI and DP minimum wait required for the R0 availability is 100mSec. So

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Read Vprime thrice incase of mismatch

On Thursday 29 March 2018 08:08 PM, Sean Paul wrote: On Thu, Mar 29, 2018 at 07:39:06PM +0530, Ramalingam C wrote: In case of V prime mismatch, DP HDCP spec mandates the re-read of Vprime atleast twice. This patch needed for DP HDCP1.4 CTS Test: 1B-05. v2: Moved the V' validation into a

[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP1.4 fixes (rev4)

== Series Details == Series: HDCP1.4 fixes (rev4) URL : https://patchwork.freedesktop.org/series/38978/ State : success == Summary == Series 38978v4 HDCP1.4 fixes https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/4/mbox/ fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add NV12 support (rev7)

== Series Details == Series: Add NV12 support (rev7) URL : https://patchwork.freedesktop.org/series/39670/ State : failure == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: dmesg-warn -> PASS (shard-snb) Test

[Intel-gfx] [PATCH] drm/i915: Move vgpu balloon info into i915_virtual_gpu struct

vgpu ballon info consists of four drm_mm_node which is used to reserve ggtt space, then linux guest won't use these reserved ggtt space. Each vgpu has its own ballon info, so move ballon info into i915_virtual_gpu structure. Signed-off-by: Xiong Zhang ---

Re: [Intel-gfx] [PATCH 06/11] drm/i915/psr: Add intel_psr_activate_block_get()/put()

On Fri, Mar 30, 2018 at 03:23:31PM -0700, José Roberto de Souza wrote: > intel_psr_activate_block_get() should be called when by some reason > PSR should not be activated for some time, it will increment counter > and it should the decremented by intel_psr_activate_block_put() > when PSR can be

Re: [Intel-gfx] [PATCH 09/11] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink

On Fri, Mar 30, 2018 at 03:23:34PM -0700, José Roberto de Souza wrote: > eDP spec states that sink device will do a short pulse in HPD > line when there is a PSR/PSR2 error that needs to be handled by > source, this is handling the first and most simples error: > DP_PSR_SINK_INTERNAL_ERROR. > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

On Sat, 2018-03-31 at 00:17 +, Souza, Jose wrote: > On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote: > > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote: > > > This was my bad, spec says that the name of this bit is > > > 'Y-coordinate valid' but the values for

Re: [Intel-gfx] [PATCH] drm/i915: Store preemption capability in engine->flags

On 31/03/18 03:42, Chris Wilson wrote: Let's avoid having to delve down the pointer chain to see if the i915 device has support for preemption and store that on the engine, which made the decision in the first place! Signed-off-by: Chris Wilson Cc: Tomasz Lis

Re: [Intel-gfx] [PATCH 02/11] drm/i915/psr: Move PSR exit specific code to hardware specific function

On Fri, Mar 30, 2018 at 03:23:27PM -0700, José Roberto de Souza wrote: > To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to > differentiate between VLV/CHV and HSW+ hardware, so here moving each > hardware handling to his own function. > > Signed-off-by: José Roberto de Souza

Re: [Intel-gfx] [PATCH 05/11] drm/i915/psr: Export intel_psr_activate/exit()

On Fri, Mar 30, 2018 at 03:23:30PM -0700, José Roberto de Souza wrote: > Export this functions so other modules can activate and exit PSR. "module" is not a right word here. But I also don't like the approach. In the past we had the use spread on our driver and it was confusing and hard to deal

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

On Mon, Apr 02, 2018 at 10:42:23AM -0700, Pandiyan, Dhinakaran wrote: > > > > On Sat, 2018-03-31 at 00:17 +, Souza, Jose wrote: > > On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote: > > > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote: > > > > This was my bad,

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Track begin/end of execlists submission sequences

Chris Wilson writes: > We would like to start doing some bookkeeping at the beginning, between > contexts and at the end of execlists submission. We already mark the > beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication > when the HW is idle. This

Re: [Intel-gfx] [PATCH 01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

On Fri, Mar 30, 2018 at 03:23:26PM -0700, José Roberto de Souza wrote: > It was reading some random register in VLV and CHV. > > Signed-off-by: José Roberto de Souza > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi I'm

Re: [Intel-gfx] [PATCH 04/11] drm/i915/psr: Remove intel_crtc_state parameter from disable()

On Fri, Mar 30, 2018 at 03:23:29PM -0700, José Roberto de Souza wrote: > It is not necessary as is possible to get the pipe information > from intel_dp. > > Signed-off-by: José Roberto de Souza > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi

Re: [Intel-gfx] [PATCH 08/11] drm/i915: Keep IGT PSR and frontbuffer tests functional

On Fri, Mar 30, 2018 at 03:23:33PM -0700, José Roberto de Souza wrote: > 'drm/i915/dp: Exit PSR before do a aux channel transaction' cause all > IGT PSR and frontbuffer tracking tests to not be userful. > Those tests depend in reading the calculated CRC value of the > frontbuffer in sink and doing

Re: [Intel-gfx] [PATCH 03/11] drm/i915/psr: Share code between disable and exit

On Fri, Mar 30, 2018 at 03:23:28PM -0700, José Roberto de Souza wrote: > The disable and exit sequence are very similar with a lot common > code between both, so here sharing the code. I don't believe that we should do this. Disable as is has some extra wait/timeouts that could slow things down.

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote: > When PSR/PSR2 is enabled hardware can do aux ch transactions by it > self. > Spec requires that PSR is inactive before do any aux ch transaction > in HSW and BDW, for skl+ there is a aux ch mutex but the use is not >

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote: > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote: > > When PSR/PSR2 is enabled hardware can do aux ch transactions by it > > self. > > Spec requires that PSR is inactive before do any aux ch transaction > > in HSW and

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status

== Series Details == Series: series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/41022/ State : success == Summary == Series 41022v1 series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status

[Intel-gfx] [PATCH] i915/dp_mst: Keep AUX block running when disabling DPMS

While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote: > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza wrote: > > When PSR/PSR2 is enabled hardware can do aux ch transactions by it > > self. > > Spec requires that PSR is inactive before do any aux ch transaction > > in HSW and

Re: [Intel-gfx] [PATCH 03/11] drm/i915/psr: Share code between disable and exit

On Mon, 2018-04-02 at 11:11 -0700, Rodrigo Vivi wrote: > On Fri, Mar 30, 2018 at 03:23:28PM -0700, José Roberto de Souza > wrote: > > The disable and exit sequence are very similar with a lot common > > code between both, so here sharing the code. > > I don't believe that we should do this. >

[Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when

[Intel-gfx] [PATCH v2 1/2] drm/i915/debugfs: Print sink PSR status

IGT tests could be improved with sink status, knowing for sure that hardware have activate or exit PSR. Reviewed-by: Dhinakaran Pandiyan Cc: Rodrigo Vivi Signed-off-by: José Roberto de Souza ---

[Intel-gfx] [PATCH v2 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

This was my bad, spec says that the name of this bit is 'Y-coordinate valid' but the values for it is: 0: Include Y-coordinate valid eDP1.4a 1: Do not include Y-coordinate valid eDP 1.4 So not setting it. Cc: Rodrigo Vivi Reviewed-by: Dhinakaran Pandiyan

[Intel-gfx] [PATCH v5 06/10] drm/dp_mst: Add reset_state callback to topology mgr

This gives drivers subclassing drm_dp_mst_topology_state the ability to prepare their topology states for a new hub to be connected whenever it's detected that the currently connected topology has been disconnected from the system. We'll need this in order to correctly track RX capabilities in

[Intel-gfx] [PATCH v5 07/10] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

[Intel-gfx] [PATCH v5 05/10] drm/dp_mst: Make drm_dp_mst_topology_state subclassable

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology.

[Intel-gfx] [PATCH v5 01/10] drm/atomic: Print debug message on atomic check failure

Does what it says on the label, it's a little confusing debugging atomic check failures otherwise. Cc: Manasi Navare Cc: Ville Syrjälä Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_atomic.c | 5 - 1 file

[Intel-gfx] [PATCH v5 02/10] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[Intel-gfx] [PATCH v5 03/10] drm/dp_mst: Fix naming on drm_atomic_get_mst_topology_state()

Since these functions are dealing with an atomic state that needs to be modified during atomic check and commit, change the naming on this function to drm_atomic_dp_mst_get_topology_state() since we're the only one using the function, and it's more consistent with the naming scheme used in

[Intel-gfx] [PATCH v5 00/10] Implement proper MST fallback retraining in i915

Latest version of https://patchwork.freedesktop.org/series/39642/ , hopefully patchwork understands this and doesn't break anything! Lots of changes. Lyude Paul (10): drm/atomic: Print debug message on atomic check failure drm/i915: Move DP modeset retry work into intel_dp drm/dp_mst: Fix

[Intel-gfx] [PATCH v5 04/10] drm/dp_mst: Remove all evil duplicate state pointers

There's no reason to track the atomic state three times. Unfortunately, this is currently what we're doing, and even worse is that there is only one actually correct state pointer: the one in mst_state->base.state. mgr->state never seems to be used, along with the one in mst_state->state. This

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/debugfs: Print sink PSR status

On Mon, Apr 02, 2018 at 03:38:26PM -0700, Pandiyan, Dhinakaran wrote: > On Mon, 2018-04-02 at 13:51 -0700, José Roberto de Souza wrote: > > IGT tests could be improved with sink status, knowing for sure that > > hardware have activate or exit PSR. > > > > Reviewed-by: Dhinakaran Pandiyan

[Intel-gfx] [PATCH 3/3] HAX enable guc, huc for CI

Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..1d23c41 100644 ---

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status

== Series Details == Series: series starting with [v2,1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/41022/ State : warning == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-b-64x64-top-edge:

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values

On 03/26/2018 12:15 AM, Joonas Lahtinen wrote: Quoting Yaodong Li (2018-03-23 19:33:15) As I said, I agree that we would likely solve the enable_guc=1 then enable_guc=3 case with these changes which I think this the the only benefit that we can get from the starting from the top way. But my

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC, HuC Loading Support for Cannonlake. (rev2)

== Series Details == Series: GuC, HuC Loading Support for Cannonlake. (rev2) URL : https://patchwork.freedesktop.org/series/41031/ State : failure == Summary == Series 41031v2 GuC, HuC Loading Support for Cannonlake. https://patchwork.freedesktop.org/api/1.0/series/41031/revisions/2/mbox/

Re: [Intel-gfx] [PATCH 06/11] drm/i915/psr: Add intel_psr_activate_block_get()/put()

On Mon, 2018-04-02 at 11:20 -0700, Rodrigo Vivi wrote: > On Fri, Mar 30, 2018 at 03:23:31PM -0700, José Roberto de Souza > wrote: > > intel_psr_activate_block_get() should be called when by some reason > > PSR should not be activated for some time, it will increment > > counter > > and it should

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

On Mon, 2018-04-02 at 12:00 -0700, Pandiyan, Dhinakaran wrote: > > > On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote: > > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza > > wrote: > > > When PSR/PSR2 is enabled hardware can do aux ch transactions by > > > it > > > self. >

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

On Mon, 2018-04-02 at 11:42 -0700, Pandiyan, Dhinakaran wrote: > > > On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote: > > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza > > wrote: > > > When PSR/PSR2 is enabled hardware can do aux ch transactions by > > > it > > > self. >

Re: [Intel-gfx] [PATCH] i915/dp_mst: Keep AUX block running when disabling DPMS

On Mon, 2018-04-02 at 17:21 -0400, Lyude Paul wrote: > While enabling/disabling DPMS before link training with MST hubs is > perfectly valid; unfortunately disabling DPMS results in some devices > disabling their AUX CH block as well. For SST this isn't as much of a > problem, but for MST we

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/debugfs: Print sink PSR status

On Mon, 2018-04-02 at 13:51 -0700, José Roberto de Souza wrote: > IGT tests could be improved with sink status, knowing for sure that > hardware have activate or exit PSR. > > Reviewed-by: Dhinakaran Pandiyan Please don't merge this patch yet. While the patch

[Intel-gfx] [PATCH v5 10/10] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[Intel-gfx] [PATCH v5 09/10] drm/dp_mst: Add MST fallback retraining helpers

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[Intel-gfx] [PATCH v5 08/10] drm/i915: Make intel_dp_mst_atomic_check() idempotent

The current way of handling changing VCPI allocations doesn't make a whole ton of sense. Since drm_atomic_helper_check_modeset() can be called multiple times which means that intel_dp_mst_atomic_check() can also be called multiple times. However, since we make the silly mistake of trying to free

Re: [Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

On Mon, 2018-04-02 at 22:16 +, Souza, Jose wrote: > On Mon, 2018-04-02 at 11:42 -0700, Pandiyan, Dhinakaran wrote: > > > > > > On Mon, 2018-04-02 at 11:23 -0700, Rodrigo Vivi wrote: > > > On Fri, Mar 30, 2018 at 03:23:32PM -0700, José Roberto de Souza > > > wrote: > > > > When PSR/PSR2 is

Re: [Intel-gfx] [PATCH v5 04/10] drm/dp_mst: Remove all evil duplicate state pointers

On Mon, 2018-04-02 at 18:47 -0400, Lyude Paul wrote: > There's no reason to track the atomic state three times. Unfortunately, > this is currently what we're doing, and even worse is that there is only > one actually correct state pointer: the one in mst_state->base.state. > mgr->state never seems

[Intel-gfx] [PATCH 1/3] linux-firmware/guc/cnl: Load GuC on Cannonlake

GuC is now available for Cannonlake. Load GuC v11.102 on Cannonlake. Cc: Tomi Sarvela Cc: Jani Saarinen Cc: Rodrigo vivi Signed-off-by: Anusha Srivatsa ---

[Intel-gfx] [PATCH 2/3] linux-firmware/huc/cnl: Load HuC on Cannonlake

Huc is available now for cannonlake. Load v9.01.2719 on Cannonlake. Cc: Tomi Sarvela Cc: Jani Saarinen Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc_fw.c

[Intel-gfx] [PATCH 0/3] GuC, HuC Loading Support for Cannonlake.

Load the latest version of GuC and HuC. Pull Request: The following changes since commit a3be6d433f843d71edaa0f9a291297589d571ce4: Merge https://github.com/Netronome/linux-firmware into netro (2018-03-30 10:10:27 -0400) are available in the git repository at:

Re: [Intel-gfx] [PATCH] drm/i915: Move vgpu balloon info into i915_virtual_gpu struct

On 2018.04.02 16:37:55 +0800, Xiong Zhang wrote: > vgpu ballon info consists of four drm_mm_node which is used to reserve > ggtt space, then linux guest won't use these reserved ggtt space. > > Each vgpu has its own ballon info, so move ballon info into > i915_virtual_gpu structure. > >

Re: [Intel-gfx] [PATCH 5/8] drm/i915/guc: Use GuC FW size and HW restrictions to determine WOPCM partition

On 03/26/2018 03:04 AM, Michał Winiarski wrote: On Fri, Mar 23, 2018 at 01:00:35PM -0700, Yaodong Li wrote: On 03/23/2018 05:34 AM, Michał Winiarski wrote: We need GuC to load HuC, but it's also possible for GuC to operate on its own. We don't know what the size of HuC FW may be, so, not

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

On 04/02/2018 02:26 PM, Lyude Paul wrote: While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3)

== Series Details == Series: drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev3) URL : https://patchwork.freedesktop.org/series/40851/ State : failure == Summary == Series 40851v3 drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP1.4 fixes (rev5)

== Series Details == Series: HDCP1.4 fixes (rev5) URL : https://patchwork.freedesktop.org/series/38978/ State : success == Summary == Series 38978v5 HDCP1.4 fixes https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/5/mbox/ Known issues: Test kms_pipe_crc_basic: