[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, some i915 fixes for v4.8. BR, Jani. The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-09-08 for you to

[Intel-gfx] [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume

From: "Lee, Shawn C" SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity (minimum increment) of the PWM backlight control counter. PWM frequency adjustment on 128 clock increments when this bit was 1. And 16 clock increments when it was 0. PWM frequency

[Intel-gfx] [PATCH 08/18] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface, where Driver will have to just use a relay API to store snapshots of the GuC log buffer in the

[Intel-gfx] [PATCH 17/18] drm/i915: Early creation of relay channel for capturing boot time logs

From: Akash Goel As per the current i915 Driver load sequence, debugfs registration is done at the end and so the relay channel debugfs file is also created after that but the GuC firmware is loaded much earlier in the sequence. As a result Driver could miss capturing the

[Intel-gfx] [PATCH 07/18] relay: Use per CPU constructs for the relay channel buffer pointers

From: Akash Goel relay essentially needs to maintain the per CPU array of channel buffer pointers but it manually creates that array. Instead its better to avail the per CPU constructs, provided by the kernel, to allocate & access the array of pointer to channel buffers.

[Intel-gfx] [PATCH 12/18] drm/i915: Increase GuC log buffer size to reduce flush interrupts

From: Akash Goel In cases where GuC generate logs at a very high rate, correspondingly the rate of flush interrupts is also very high. So far total 8 pages were allocated for storing both ISR & DPC logs. As per the half-full draining protocol followed by GuC, by doubling

[Intel-gfx] [PATCH 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

From: Sagar Arun Kamble GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state structure, once it has consumed the log buffer contents by copying them to a file or buffer. Even

[Intel-gfx] [PATCH 10/18] drm/i915: Add stats for GuC log buffer flush interrupts

From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full. GuC firmware also tracks how many times the buffer overflowed. It would be useful to maintain a statistics of how many flush interrupts were received and for which type of

[Intel-gfx] [PATCH 02/18] drm/i915: Add GuC ukernel logging related fields to fw interface file

From: Sagar Arun Kamble The first page of the GuC log buffer contains state info or meta data which is required to parse the logs contained in the subsequent pages. The structure representing the state info is added to interface file as Driver would need to handle log

[Intel-gfx] [PATCH 11/18] drm/i915: Optimization to reduce the sampling time of GuC log buffer

From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full, so Driver doesn't really need to sample the complete buffer and can just copy only the newly written data by GuC into the local buffer, i.e. as per the read & write pointer

[Intel-gfx] [PATCH 15/18] drm/i915: Debugfs support for GuC logging control

From: Sagar Arun Kamble This patch provides debugfs interface i915_guc_output_control for on the fly enabling/disabling of logging in GuC firmware and controlling the verbosity level of logs. The value written to the file, should have bit 0 set to enable logging and

[Intel-gfx] [PATCH 03/18] drm/i915: New structure to contain GuC logging related fields

From: Akash Goel So far there were 2 fields related to GuC logs in 'intel_guc' structure. For the support of capturing GuC logs & storing them in a local buffer, multiple new fields would have to be added. This warrants a separate structure to contain the fields related to

[Intel-gfx] [PATCH 01/18] drm/i915: Decouple GuC log setup from verbosity parameter

From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level module param i915.guc_log_level. User would be given a provision to enable firmware logging at runtime, through a host2guc action, and not necessarily during Driver load time. But the

[Intel-gfx] [PATCH 05/18] drm/i915: Support for GuC interrupts

From: Sagar Arun Kamble There are certain types of interrupts which Host can receive from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel. This patch adds support to receive interrupts from

[Intel-gfx] [PATCH 04/18] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set

From: Akash Goel So far PM IER/IIR/IMR registers were being used only for Turbo related interrupts. But interrupts coming from GuC also use the same set. As a precursor to supporting GuC interrupts, added new low level routines so as to allow sharing the programming of PM

[Intel-gfx] [PATCH 14/18] drm/i915: Support for forceful flush of GuC log buffer

From: Sagar Arun Kamble GuC firmware sends a flush interrupt to Host when the log buffer is half full and at that time only it updates the log buffer state. But in certain cases, as described below, it could be useful to have all that even when log buffer is only

[Intel-gfx] [PATCH 18/18] drm/i915: Mark the GuC log buffer flush interrupts handling WQ as freezable

From: Akash Goel The GuC log buffer flush work item has to do a register access to send the ack to GuC and this work item, if not synced before suspend, can potentially get executed after the GFX device is suspended. This work item function uses rpm get/put calls around the

[Intel-gfx] [PATCH 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer

From: Akash Goel Added the dump of GuC log buffer to i915 error state, as the contents of GuC log buffer would also be useful to determine that why the GPU reset was triggered. v2: - For uniformity use existing helper function print_error_obj() to dump out contents of

[Intel-gfx] [PATCH 16/18] drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer

From: Akash Goel To ensure that we always get the up-to-date data from log buffer, its better to access the buffer through an uncached CPU mapping. Also the way buffer is accessed from GuC & Host side, manually doing cache flush may not be effective always if cached CPU

Re: [Intel-gfx] [PATCH v3 9/14] drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2

Reviewed-by: Mika Kahola On Wed, 2016-09-07 at 11:28 -0700, Manasi Navare wrote: > From: Dhinakaran Pandiyan > > This function cleans up clock recovery loop in link training > compliant > tp Dp Spec 1.2. It tries the clock recovery 5 times

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave - Here's a drm-misc pull request mainly to get some fixes moving forward. BR, Jani. The following changes since commit 2b2fd56d7e92f134ecaae5c89e20f64dd0f95aa2: Revert "drm: make DRI1 drivers depend on BROKEN" (2016-09-01 06:16:12 +1000) are available in the git repository at:

Re: [Intel-gfx] [PATCH 2/8] drm/i915: introduce intel_has_sagv()

On Wed, 07 Sep 2016, Lyude wrote: > On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote: >> And use it to move knowledge about the SAGV-supporting platforms from >> the callers to the SAGV code. >> >> We'll add more platforms to intel_has_sagv(), so IMHO it makes more >>

Re: [Intel-gfx] [PATCH] drm: Fix error path in drm_mode_page_flip_ioctl()

On Thu, 08 Sep 2016, Michel Dänzer wrote: > On 08/09/16 02:23 AM, Imre Deak wrote: >> This fixes the error path for platforms that don't define the new >> page_flip_target() hook. >> >> Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2") >> Testcase:

Re: [Intel-gfx] [PATCH v4 11/14] drm/i915: Fallback to lower link rate and lane count during link training

Reviewed-by: Mika Kahola On Wed, 2016-09-07 at 17:30 -0700, Manasi Navare wrote: > According to the DisplayPort Spec, in case of Clock Recovery failure > the link training sequence should fall back to the lower link rate > followed by lower lane count until CR succeeds. >

[Intel-gfx] [PATCH v2] drm: Move property validation to a helper, v2.

Property lifetimes are equal to the device lifetime, so the separate drm_property_find is not needed. The pointer can be retrieved from the properties member, which saves us some locking and a extra lookup. The lifetime for properties is until the device is destroyed, which happens late in the

[Intel-gfx] [PATCH v3] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and by default stored into a file 'guc_log_dump.dat'. The name, including the

Re: [Intel-gfx] [PATCH] Revert "drm/i915/psr: Make idle_frames sensible again"

On Thu, 08 Sep 2016, Ville Syrjälä wrote: > On Wed, Sep 07, 2016 at 05:42:31PM -0700, Rodrigo Vivi wrote: >> This reverts commit 1c80c25fb622973dd135878e98d172be20859049. >> >> There are panels that needs 4 idle frames before entering PSR, >> but VBT is unproperly

Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/dp/mst: Add support for upfront link training for DP MST

On Wed, 2016-09-07 at 09:40 -0700, Jim Bride wrote: > On Wed, Sep 07, 2016 at 01:53:31PM +0300, Mika Kahola wrote: > > > > On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote: > > > > > > From: Jim Bride > > > > > > Add upfront link training to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915 : Restore PWM_GRANULARITY after resume

== Series Details == Series: drm/i915 : Restore PWM_GRANULARITY after resume URL : https://patchwork.freedesktop.org/series/12165/ State : success == Summary == Series 12165v1 drm/i915 : Restore PWM_GRANULARITY after resume

[Intel-gfx] [PATCH v9 00/18] Support for sustained capturing of GuC firmware logs

From: Akash Goel GuC firmware log its debug messages into a Host-GuC shared memory buffer and when the buffer is half full it sends a Flush interrupt to Host. GuC firmware follows the half-full draining protocol where it expects that while it is writing to 2nd half of the

Re: [Intel-gfx] [PATCH v2 11/22] drm/i915: Perform a direct reset of the GPU from the waiter

Chris Wilson writes: > If a waiter is holding the struct_mutex, then the reset worker cannot > reset the GPU until the waiter returns. We do not want to return -EAGAIN > form i915_wait_request as that breaks delicate operations like > i915_vma_unbind() which often

[Intel-gfx] [PATCH 09/18] drm/i915: New lock to serialize the Host2GuC actions

From: Akash Goel With the addition of new Host2GuC actions related to GuC logging, there is a need of a lock to serialize them, as they can execute concurrently with each other and also with other existing actions. v2: Use mutex in place of spinlock to serialize, as sleep

Re: [Intel-gfx] [PATCH v2 18/22] drm/i915: Ignore valid but unknown semaphores

On ke, 2016-09-07 at 15:45 +0100, Chris Wilson wrote: > If we find a ring waiting on a semaphore for another assigned but not yet > emitted request, treat it as valid and waiting. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: use symbolic names for module parameter values (rev5)

== Series Details == Series: drm/i915/guc: use symbolic names for module parameter values (rev5) URL : https://patchwork.freedesktop.org/series/10188/ State : failure == Summary == Series 10188v5 drm/i915/guc: use symbolic names for module parameter values

Re: [Intel-gfx] [PATCH] Revert "drm/i915/psr: Make idle_frames sensible again"

On Wed, Sep 07, 2016 at 05:42:31PM -0700, Rodrigo Vivi wrote: > This reverts commit 1c80c25fb622973dd135878e98d172be20859049. > > There are panels that needs 4 idle frames before entering PSR, > but VBT is unproperly set. > > Also lately it was identified that idle frame count calculated at HW >

Re: [Intel-gfx] [PATCH v3 8/14] drm/i915/dp: Move max. vswing check to it's own function

This compiler warning is fixed with the next patch of the series. drivers/gpu/drm/i915/intel_dp_link_training.c: In function ‘intel_dp_link_training_clock_recovery’: drivers/gpu/drm/i915/intel_dp_link_training.c:131:6: warning: unused variable ‘i’ [-Wunused-variable] Therefore, Reviewed-by:

Re: [Intel-gfx] [PATCH v8 08/12] drm/i915: Read DP branch device SW revision

> -Original Message- > From: Jim Bride [mailto:jim.br...@linux.intel.com] > Sent: Thursday, September 8, 2016 12:20 AM > To: Kahola, Mika > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > ville.syrj...@linux.intel.com;

[Intel-gfx] [PATCH v2 8/9] drm/i915/bxt: set chicken bit as IPC y-tile WA

From: Mahesh Kumar It implements the WA to enable IDLE_WAKEMEM bit of CHICKEN_DCPR_1 register for Broxton platform. When IPC is enabled & Y-tile is enabled in any of the enabled plane, above bit should be set. Without this WA system observes random hang. Signed-off-by:

[Intel-gfx] [PATCH v2 9/9] drm/i915/bxt: Implement Transition WM

From: Mahesh Kumar This patch enables Transition WM for SKL+ platforms. Transition WM are used if IPC is enabled, to decide, number of blocks to be fetched before reducing the priority of display to fetch from memory. Changes since v1: - Don't enable transition WM for

[Intel-gfx] [PATCH v2 2/9] drm/i915/skl+: use linetime latency instead of ddb size

From: Mahesh Kumar This patch make changes to use linetime latency instead of allocated DDB size during plane watermark calculation in switch case, This is required to implement new DDB allocation algorithm. In New Algorithm DDB is allocated based on WM values, because

Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/dp/mst: Add support for upfront link training for DP MST

Reviewed-by: Mika Kahola On Wed, 2016-09-07 at 13:53 +0300, Mika Kahola wrote: > On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote: > > > > From: Jim Bride > > > > Add upfront link training to intel_dp_mst_mode_valid() so that we > > know

[Intel-gfx] ✗ Fi.CI.BAT: failure for Implement New DDB allocation algorithm

== Series Details == Series: Implement New DDB allocation algorithm URL : https://patchwork.freedesktop.org/series/11720/ State : failure == Summary == Series 11720v1 Implement New DDB allocation algorithm http://patchwork.freedesktop.org/api/1.0/series/11720/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v2 13/22] drm/i915: Update reset path to fix incomplete requests

Chris Wilson writes: > Update reset path in preparation for engine reset which requires > identification of incomplete requests and associated context and fixing > their state so that engine can resume correctly after reset. > > The request that caused the hang will be

[Intel-gfx] [PATCH v2 3/9] drm/i915/skl: New ddb allocation algorithm

From: Mahesh Kumar This patch implements new DDB allocation algorithm as per HW team suggestion. This algo takecare of scenario where we allocate less DDB for the planes with lower relative pixel rate, but they require more DDB to work. It also takes care of enabling

[Intel-gfx] [PATCH v2 6/9] drm/i915/skl+: change WM calc to fixed point 16.16

From: Mahesh Kumar This patch changes Watermak calculation to fixed point calculation. Problem with current calculation is during plane_blocks_per_line calculation we divide intermediate blocks with min_scanlines and takes floor of the result because of integer

[Intel-gfx] [PATCH v2 0/9] New DDB Algo and WM fixes

From: Mahesh Kumar This series implements new DDB allocation algorithm to solve the cases, where we have sufficient DDB available to enable multiple planes, But due to the current algorithm not dividing it properly among planes, we end-up failing the flip. It also takes

[Intel-gfx] [PATCH v2 5/9] drm/i915/gen9: WM memory bandwidth related workaround

From: Mahesh Kumar This patch implemnets Workariunds related to display arbitrated memory bandwidth. These WA are applicabe for all gen-9 based platforms. Changes since v1: - Rebase on top of Paulo's patch series Signed-off-by: Mahesh Kumar

[Intel-gfx] [PATCH v2 4/9] drm/i915: Decode system memory bandwidth

From: Mahesh Kumar This patch adds support to decode system memory bandwidth which will be used for arbitrated display memory percentage calculation in GEN9 based system. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_drv.c | 96

[Intel-gfx] [PATCH v2 7/9] drm/i915/bxt: Enable IPC support

From: Mahesh Kumar This patch adds IPC support for platforms. This patch enables IPC only for BXT platform as for SKL recommendation is to keep is disabled This patch also adds kernel command-line option to enable/disable the IPC if required. Signed-off-by: Mahesh Kumar

[Intel-gfx] [PATCH v2 1/9] drm/i915/skl: pass pipe_wm in skl_compute_(wm_level/plane_wm) functions

From: Mahesh Kumar This patch make use of plane_wm variable directly instead of passing skl_plane_wm struct. this way reduces number of argument requirement in watermark calculation functions. It also gives more freedom of decision making to implement Bspec WM

Re: [Intel-gfx] [PATCH v8 12/12] drm/i915: Check TMDS clock DP to HDMI dongle

On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote: > Respect max TMDS clock frequency from DPCD for active > DP to HDMI adapters. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_drv.h | 3 +++ > drivers/gpu/drm/i915/intel_hdmi.c | 27

Re: [Intel-gfx] [PATCH v2 12/22] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker

Chris Wilson writes: > Since we have a cooperative mode now with a direct reset, we can avoid > the contention on struct_mutex and instead try then sleep on the > I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is > cleared, all is fine. Otherwise, we

Re: [Intel-gfx] [PATCH v13 13/14] drm/i915/dp: Enable Upfront link training for typeC DP support on HSW/BDW/SKL/BXT (DDI platforms)

On Wed, 2016-09-07 at 11:28 -0700, Manasi Navare wrote: > From: Durgadoss R > > To support USB type C alternate DP mode, the display driver needs to > know the number of lanes required by the DP panel as well as number > of lanes that can be supported by the type-C cable.

Re: [Intel-gfx] [PATCH v8 10/12] drm/i915: Update bits per component for display info

Thanks for the review. I'll fix those indentations. > -Original Message- > From: Jim Bride [mailto:jim.br...@linux.intel.com] > Sent: Thursday, September 8, 2016 12:27 AM > To: Kahola, Mika > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >

[Intel-gfx] [PATCH i-g-t 1/2] lib/debugfs: Support new generic ABI for CRC capture

The kernel has now a new debugfs ABI that can also allow capturing frame CRCs for drivers other than i915. Add alternative codepaths so the new ABI is used if the kernel is recent enough, and fall back to the legacy ABI if not. Signed-off-by: Tomeu Vizoso ---

[Intel-gfx] [PATCH i-g-t 2/2] lib/debugfs: Report failures when starting CRC capture

For drivers other than i915, the "auto" source for a given CRTC may be only able to generate CRCs in specific modeset configurations. So allow the tests to find out if CRC generation is possible by returning an error when CRC capture would start so tests can be skipped. Signed-off-by: Tomeu

Re: [Intel-gfx] [PATCH v6 0/4] New debugfs API for capturing CRC of frames

On 7 September 2016 at 11:27, Tomeu Vizoso wrote: > Hi, > > this series basically takes the facility for continuously capturing CRCs > of frames from the i915 driver and into the DRM core. > > The idea is that test suites such as IGT use this information to check >

Re: [Intel-gfx] [PATCH v8 03/12] drm: Helper to read max clock rate

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Thursday, September 8, 2016 4:02 PM > To: Kahola, Mika > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > jim.br...@linux.intel.com;

Re: [Intel-gfx] [PATCH v6 3/4] drm/i915: Use new CRC debugfs API

Hi Tomeu, Just a couple of nitpicks. Nothing that has to be fixed or (if you agree) cannot be done on top/later on. On 7 September 2016 at 11:27, Tomeu Vizoso wrote: > The core provides now an ABI to userspace for generation of frame CRCs, > so implement the

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: use symbolic names for module parameter values (rev5)

On 08/09/16 08:52, Patchwork wrote: == Series Details == Series: drm/i915/guc: use symbolic names for module parameter values (rev5) URL : https://patchwork.freedesktop.org/series/10188/ State : failure == Summary == Series 10188v5 drm/i915/guc: use symbolic names for module parameter

Re: [Intel-gfx] [PATCH v8 03/12] drm: Helper to read max clock rate

On Wed, Aug 17, 2016 at 01:49:39PM +0300, Mika Kahola wrote: > Helper routine to read out maximum supported pixel rate > for DisplayPort legay VGA converter or TMDS clock rate > for other digital legacy converters. The helper returns > clock rate in kHz. > > v2: Return early if detailed port cap

Re: [Intel-gfx] [PATCH v8 04/12] drm: Helper to read max bits per component

On Wed, Aug 17, 2016 at 01:49:40PM +0300, Mika Kahola wrote: > Helper routine to read out maximum supported bits per > component for DisplayPort legay converters. > > v2: Return early if detailed port cap info is not available. > Replace if-else ladder with switch-case (Ville) > >

Re: [Intel-gfx] [PATCH v2 12/22] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker

On Thu, Sep 08, 2016 at 01:52:21PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > Since we have a cooperative mode now with a direct reset, we can avoid > > the contention on struct_mutex and instead try then sleep on the > > I915_RESET_IN_PROGRESS bit. If the

[Intel-gfx] [PATCH] drm/i915: Avoid incrementing hangcheck whilst waiting for external fence

If we are waiting upon an external fence, from the pov of hangcheck the engine is stuck on the last submitted seqno. Currently we give a small increment to the hangcheck score in order to catch a stuck waiter / driver. Now that we both have an independent wait hangcheck and may be stuck waiting on

[Intel-gfx] [PATCH v7 1/4] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. v6: Rebased. v7: Fix whitespace issue. Signed-off-by: Tomeu

[Intel-gfx] [PATCH v7 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

Use drm_accurate_vblank_count so we have the full 32 bit to represent the frame counter and userspace has a simpler way of knowing when the counter wraps around. Signed-off-by: Tomeu Vizoso Reviewed-by: Emil Velikov ---

[Intel-gfx] [PATCH v7 0/4] New debugfs API for capturing CRC of frames

Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers

Re: [Intel-gfx] [PATCH 12/14] drm/i915: Reverse the loop in intel_dp_compute_config

On Fri, Sep 02, 2016 at 04:08:27PM +0300, Mika Kahola wrote: > On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote: > > While configuring the pipe during modeset, it should loop > > starting from max clock and max lane count reducing the > > lane count and clock in each iteration until the

Re: [Intel-gfx] [PATCH 2/8] drm/i915: introduce intel_has_sagv()

On Thu, 2016-09-08 at 11:59 +0300, Jani Nikula wrote: > On Wed, 07 Sep 2016, Lyude wrote: > > > > On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote: > > > > > > And use it to move knowledge about the SAGV-supporting platforms from > > > the callers to the SAGV code. > > >

[Intel-gfx] [PATCH v7 3/4] drm/i915: Use new CRC debugfs API

The core provides now an ABI to userspace for generation of frame CRCs, so implement the ->set_crc_source() callback and reuse as much code as possible with the previous ABI implementation. When handling the pageflip interrupt, we skip 1 or 2 frames depending on the HW because they contain wrong

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid incrementing hangcheck whilst waiting for external fence

== Series Details == Series: drm/i915: Avoid incrementing hangcheck whilst waiting for external fence URL : https://patchwork.freedesktop.org/series/12182/ State : success == Summary == Series 12182v1 drm/i915: Avoid incrementing hangcheck whilst waiting for external fence

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

On 08/09/16 00:02, Nicolas Iooss wrote: On 07/09/16 18:03, Dave Gordon wrote: On 06/09/16 21:36, Nicolas Iooss wrote: On 06/09/16 12:21, Dave Gordon wrote: On 04/09/16 19:58, Nicolas Iooss wrote: When building the kernel with clang and some warning flags, the compiler reports that the return

Re: [Intel-gfx] [PATCH v6 3/4] drm/i915: Use new CRC debugfs API

On 8 September 2016 at 15:35, Emil Velikov wrote: > Hi Tomeu, > > Just a couple of nitpicks. Nothing that has to be fixed or (if you > agree) cannot be done on top/later on. > > On 7 September 2016 at 11:27, Tomeu Vizoso wrote: >> The core

[Intel-gfx] [RFC] drm/i915: Emit to ringbuffer directly

From: Tvrtko Ursulin This removes the usage of intel_ring_emit in favour of directly writing to the ring buffer. intel_ring_emit was preventing the compiler for optimising fetch and increment of the current ring buffer pointer and therefore generating very verbose code

Re: [Intel-gfx] [PATCH v13 13/14] drm/i915/dp: Enable Upfront link training for typeC DP support on HSW/BDW/SKL/BXT (DDI platforms)

On Thu, Sep 08, 2016 at 03:10:43PM +0300, Mika Kahola wrote: > On Wed, 2016-09-07 at 11:28 -0700, Manasi Navare wrote: > > From: Durgadoss R > > > > To support USB type C alternate DP mode, the display driver needs to > > know the number of lanes required by the DP panel

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Emit to ringbuffer directly

== Series Details == Series: drm/i915: Emit to ringbuffer directly URL : https://patchwork.freedesktop.org/series/12186/ State : failure == Summary == Series 12186v1 drm/i915: Emit to ringbuffer directly http://patchwork.freedesktop.org/api/1.0/series/12186/revisions/1/mbox/ Test

[Intel-gfx] [PATCH v14 13/14] drm/i915/dp: Enable Upfront link training for typeC DP support on HSW/BDW/SKL/BXT (DDI platforms)

From: Durgadoss R To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel

Re: [Intel-gfx] [RFC] drm/i915: Emit to ringbuffer directly

On Thu, Sep 08, 2016 at 04:12:55PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > This removes the usage of intel_ring_emit in favour of > directly writing to the ring buffer. I have the same patch! But I called it out, for historical reasons. Oh, except mine

[Intel-gfx] [PATCH v2 12/14] drm/i915: Remove the link rate and lane count loop in compute config

While configuring the pipe during modeset, it should use max clock and max lane count and reduce the bpp until the requested mode rate is less than or equal to available link BW. This is required to pass DP Compliance. v2: * Removed the loop since we use max values of clock and lane count

[Intel-gfx] [PATCH v15 13/14] drm/i915/dp: Enable Upfront link training for typeC DP support on HSW/BDW/SKL/BXT (DDI platforms)

From: Durgadoss R To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel

[Intel-gfx] Handling DP compliance short pulse for DP MST

Hi, I have been working on adding DP compliance test request support in i915 driver. Unigraf DPR-120 is used as a DP Compliance reference sink device that generates a short pulse for the compliance test requests. In case of DP SST, these short pulses get handled in the i915 driver's short pulse

Re: [Intel-gfx] Handling DP compliance short pulse for DP MST

On 9 September 2016 at 11:28, Manasi Navare wrote: > Hi, > > I have been working on adding DP compliance test request support in > i915 driver. Unigraf DPR-120 is used as a DP Compliance reference > sink device that generates a short pulse for the compliance test

Re: [Intel-gfx] [PATCH v4 11/14] drm/i915: Fallback to lower link rate and lane count during link training

On Wed, Sep 7, 2016 at 5:30 PM, Manasi Navare wrote: > According to the DisplayPort Spec, in case of Clock Recovery failure > the link training sequence should fall back to the lower link rate > followed by lower lane count until CR succeeds. > On CR success, the