Re: [Intel-gfx] [PATCH 12/29] drm/armada: Drop struct_mutex from cursor paths

On Thu, Dec 03, 2015 at 04:08:45PM +, Russell King - ARM Linux wrote: > On Mon, Nov 23, 2015 at 10:32:45AM +0100, Daniel Vetter wrote: > > @@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc > > *crtc, int x, int y) > > if (!dcrtc->variant->has_spu_adv_reg) > >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Store the reset counter when constructing a request

On Tue, Dec 01, 2015 at 11:05:34AM +, Chris Wilson wrote: > As the request is only valid during the same global reset epoch, we can > record the current reset_counter when constructing the request and reuse > it when waiting upon that request in future. This removes a very hairy > atomic check

Re: [Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl

On Thu, Dec 03, 2015 at 09:50:25AM +0100, Daniel Vetter wrote: > On Tue, Dec 01, 2015 at 09:20:02AM +, Chris Wilson wrote: > > On Tue, Dec 01, 2015 at 10:13:10AM +0100, Daniel Vetter wrote: > > > On Tue, Dec 01, 2015 at 09:04:23AM +, Chris Wilson wrote: > > > > On Tue, Dec 01, 2015 at

[Intel-gfx] [PATCH] drm/atomic: Reject async flips on a disabled pipe

Two reasons for that: - This changes aligns atomic with the legacy page flip semantics as established by the i915 driver. - Asking for an async flip on a disabled pipe generally indicates a userspace bug. Worst case userspace will busy-loop rendering (since flips complete immediately). So

[Intel-gfx] [PATCH] drm/atomic-helper: Reject attempts at re-stealing encoders

This can happen when we run out of encoders for a multi-crtc modeset, or also when userspace is silly and tries to clone multiple connectors that need the same encoder on the same crtc. Reported-and-Tested-and-Reviewed-by: Maarten Lankhorst Cc: Maarten

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state

Op 25-11-15 om 17:48 schreef Matt Roper: > The intel_dump_pipe_config() always dumps the currently active plane > state for each plane on a CRTC. If we're calling this function to dump > CRTC state that is in-flight (not yet active), then this mismatch can be > misleading and confusing. Let's

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Clarify plane state during CRTC state dumps (v2)

Op 25-11-15 om 17:48 schreef Matt Roper: > During state dumping, list planes that have an FB but are invisible > (e.g., because they're offscreen or clipped by other planes) as "not > visible" rather than "enabled." While we're at it, dump the FB format > as a human-readable string rather than a

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)

Op 25-11-15 om 17:48 schreef Matt Roper: > Plane state objects contain two copies of src/dest coordinates: the > original (requested by userspace) coordinates in the base > drm_plane_state object, and a second, clipped copy (i.e., what we > actually want to program to the hardware) in

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED

On Thu, Dec 03, 2015 at 12:37:20PM +0200, Ville Syrjälä wrote: > On Thu, Dec 03, 2015 at 09:02:12AM +0100, Daniel Vetter wrote: > > On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > >

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

Hi, On 02/12/15 12:24, Vinay Belgaumkar wrote: These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU. These tests rely on the softpin

Re: [Intel-gfx] [PATCH i-g-t] tests: add exit value constants for shell script tests

1 comment / question inline, otherwise looks ok to me. //Derek > > >-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Thomas Wood >Sent: Thursday, December 3, 2015 11:31 AM >To: intel-gfx@lists.freedesktop.org >Subject: [Intel-gfx] [PATCH

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb

Op 25-11-15 om 17:48 schreef Matt Roper: > If we fail to reconstruct the BIOS fb (e.g., because the FB is too > large), we'll be left with plane state that indicates the primary plane > is visible yet has a NULL fb. This mismatch causes problems later on > (e.g., for the watermark code). Since

Re: [Intel-gfx] [PATCH 9/9] drm/atomic: Add encoder_mask to crtc_state.

Op 03-12-15 om 10:53 schreef Daniel Vetter: > On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote: >> This allows iteration over encoders without requiring connection_mutex. >> >> Signed-off-by: Maarten Lankhorst >> --- >>

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Disable CLKOUT_DP bending on LPT/WPT as needed

2015-12-03 8:03 GMT-02:00 Ville Syrjälä : > On Wed, Dec 02, 2015 at 11:35:00AM -0200, Paulo Zanoni wrote: >> 2015-12-01 11:08 GMT-02:00 : >> > From: Ville Syrjälä >> > >> > When we want to use SPLL for

Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drm_lib.sh: Skip when i915 debugfs wasn't found

On 3 December 2015 at 10:46, Morton, Derek J wrote: >> >> >>-Original Message- >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >>Thomas Wood >>Sent: Thursday, December 3, 2015 10:08 AM >>To: Daniel Vetter >>Cc: Intel Graphics

[Intel-gfx] [PATCH v8 01/25] drm: Create Color Management DRM properties

Color Management is an extension to DRM framework. It allows abstraction of hardware color correction and enhancement capabilities by virtue of DRM properties. There are two major types of color correction supported by DRM color manager: - CTM: color transformation matrix, properties where a

[Intel-gfx] [PATCH v8 03/25] drm: Add color correction blobs in CRTC state

This patch adds new variables in CRTC state, to hold respective color correction blobs. These blobs will be required during the atomic commit for writing the color correction values in correction registers. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi

[Intel-gfx] [PATCH v8 00/25] Color Management for DRM framework

This patch set adds Color Manager implementation in DRM layer. Color Manager is an extension in DRM framework to support color correction/enhancement. Various Hardware platforms can support several color correction capabilities. Color Manager provides abstraction of these capabilities and allows

[Intel-gfx] [PATCH v8 04/25] drm: Add set property support for color manager

As per DRM color manager design, if a userspace wants to set a correction blob, it prepares it and sends the blob_id to kernel via set_property call. DRM framework takes this blob_id, gets the blob, and saves it in the CRTC state, so that, during the atomic_commit, the color correction values from

[Intel-gfx] [PATCH v8 12/25] drm/i915: CHV: Load gamma color correction values

DRM color manager allows the driver to showcase its best color correction capabilities using the specific query property cm_coeff_after_ctm_property. The driver must loads the no. of coefficients for color correction as per the platform capability during the init time. This patch adds no of

[Intel-gfx] [PATCH v8 11/25] drm/i915: Register color correction capabilities

From DRM color management: DRM color manager supports these color properties: 1. "ctm": Color transformation matrix property, where a color transformation matrix of 9 correction values gets applied as correction. 2. "palette_before_ctm": for corrections which get

[Intel-gfx] [PATCH v8 08/25] drm: Add color correction state flag

Add a color correction state flag, to indicate a change in color correction states. This flag will help a core driver to optimize its commit calls, by appling the color correction only when there is a change, not every commit. Signed-off-by: Shashank Sharma ---

[Intel-gfx] [PATCH v8 05/25] drm: Add get property support for color manager

As per the DRM get_property implementation for a blob, framework is supposed to return the blob_id to the caller. All the color management blobs are saved in CRTC state during the set call. This patch adds get_property support for color management properties, by referring to the existing blob for

[Intel-gfx] [PATCH v8 02/25] drm: Create Color Management query properties

DRM color management is written to extract the color correction capabilities of various platforms, and every platform can showcase its capabilities using the query properties. Different hardwares can have different no of coefficients for palette correction. Also the correction can be applied

[Intel-gfx] [PATCH i-g-t] tests: update .gitignore and add a Makefile rule to create it

Signed-off-by: Thomas Wood --- tests/.gitignore | 13 +++-- tests/Makefile.am | 4 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/tests/.gitignore b/tests/.gitignore index ba1becd..9dfc7f3 100644 --- a/tests/.gitignore +++ b/tests/.gitignore

Re: [Intel-gfx] [PATCH 4/4] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation

Hi, On 02/12/15 09:24, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma This patch verifies if the contents of the stolen backed object were preserved across hibernation. This is to validate kernel changes related to moving stolen-backed objects

Re: [Intel-gfx] [PATCH 4/9] drm/i915: Dump pipe config after initial FB is reconstructed

Op 25-11-15 om 17:48 schreef Matt Roper: > We dump during HW state readout, but that's too early to reflect how the > primary plane is actually configured. > > In the future it would be nice if we could just read out HW state and > reconstruct FB's at the same point, but at the moment we don't

Re: [Intel-gfx] [PATCH i-g-t] tests: add exit value constants for shell script tests

On 3 December 2015 at 12:17, Morton, Derek J wrote: > 1 comment / question inline, otherwise looks ok to me. > > //Derek > >> >> >>-Original Message- >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >>Thomas Wood >>Sent: Thursday,

[Intel-gfx] [PATCH v8 17/25] drm/i915: Commit color correction to CRTC

The color correction blob values are loaded during set_property calls. This patch adds a function to find the blob and apply the correction values to the display registers, during the atomic commit call. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi

[Intel-gfx] [PATCH v8 13/25] drm/i915: CHV: Load degamma color correction values

DRM color manager allows the driver to showcase its best color correction capabilities using the specific query property cm_coeff_before_ctm_property. The driver must loads the no. of coefficients for color correction as per the platform capability during the init time. This patch adds no of

[Intel-gfx] [PATCH v8 20/25] drm/i915: BDW: Pipe level Gamma correction

BDW/SKL/BXT platforms support various Gamma correction modes which are: 1. Legacy 8-bit mode 2. 10-bit mode 3. Split mode 4. 12-bit mode This patch does the following: 1. Adds the core function to program Gamma correction values for BDW/SKL/BXT platforms 2. Adds Gamma correction macros/defines

[Intel-gfx] [PATCH v8 16/25] drm/i915: CHV: Pipe level CSC correction

CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix that needs to be programmed into CGM (Color Gamut Mapping) registers. This patch does the following: 1. Attaches CSC property to CRTC 2. Adds the core function to program CSC correction values 3. Adds CSC correction macros

[Intel-gfx] [PATCH v8 15/25] drm/i915: CHV: Pipe level degamma correction

CHV/BSW supports Degamma color correction, which linearizes all the non-linear color values. This will be applied before Color Transformation. This patch does the following: 1. Attach deGamma property to CRTC 2. Add the core function to program DeGamma correction values for CHV/BSW platform 2.

[Intel-gfx] [PATCH v8 23/25] drm/i915: BDW: Pipe level CSC correction

BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix that needs to be programmed into respective CSC registers. This patch does the following: 1. Adds the core function to program CSC correction values for BDW/SKL/BXT platform 2. Adds CSC correction macros/defines

[Intel-gfx] [PATCH v8 14/25] drm/i915: CHV: Pipe level Gamma correction

CHV/BSW platform supports two different pipe level gamma correction modes, which are: 1. Legacy 8-bit mode 2. 10-bit CGM (Color Gamut Mapping) mode This patch does the following: 1. Attaches Gamma property to CRTC 3. Adds the core Gamma correction function for CHV/BSW 4. Adds Gamma correction

[Intel-gfx] [PATCH v8 10/25] drm/i915: Create color management files

This patch create new files intel_color_manager.c which will contain the core color correction code for I915 driver and its header intel_color_manager.h The per color property patches coming up in this patch series will fill the appropriate functions in this file. Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH v8 07/25] drm: Add structure for CTM color property

Color Manager framework defines a DRM property for color space transformation and Gamut mapping. This property is called CTM (Color Transformation Matrix). This patch adds a new structure in DRM layer for CTM. This structure can be used by all user space agents to configure CTM coefficients for

[Intel-gfx] [PATCH v8 09/25] drm/i915: Add set property interface for CRTC

This patch adds set property interface for intel CRTC. This interface will be used for set operation on any DRM properties. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi --- drivers/gpu/drm/i915/intel_display.c | 1 + 1 file

[Intel-gfx] [PATCH v8 19/25] drm/i915: BDW: Load gamma correction values

I915 color manager registers pipe gamma correction as palette correction after CTM property. For BDW and higher platforms, split gamma correction is the best gamma correction. This patch adds the no of coefficients(512) for split gamma correction as "num_samples_after_ctm" parameter in device

[Intel-gfx] [PATCH v8 21/25] drm/i915: BDW: Load degamma correction values

I915 color manager registers pipe degamma correction as palette correction before CTM, DRM property. This patch adds the no of coefficients(512) for degamma correction as "num_samples_before_ctm" parameter in device info structures, for BDW and higher platforms. Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH v8 22/25] drm/i915: BDW: Pipe level degamma correction

BDW/SKL/BXT supports Degamma color correction feature, which linearizes the non-linearity due to gamma encoded color values. This will be applied before Color Transformation. This patch does the following: 1. Adds the core function to program DeGamma correction values for BDW/SKL/BXT platform

[Intel-gfx] [PATCH v8 25/25] drm/i915: Commit color correction only when needed

This patch optimizes the commit path for i915 driver, by applying color corrections, only when required. Pipe level color correction (like CSC/gamma/degamma) once applied, sustain until the next change. DRM layer sets a flag in crtc state (color_correction_changed), whenever there is new

[Intel-gfx] [PATCH v8 24/25] drm/i915: disable plane gamma

In plane enabling sequence, plane gamma bit is by default enabled. Plane gamma gets higher priority than pipe gamma, if both enabled. This patch disables plane gamma from sequence. If required, plane gamma can be enabled via the color manager drm interface. Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH v8 18/25] drm/i915: Attach color properties to CRTC

Function intel_attach_color_properties_to_crtc attaches a color property to its CRTC object. This patch calls this function from crtc initialization sequence. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi ---

[Intel-gfx] [PATCH i-g-t] tests: add exit value constants for shell script tests

Signed-off-by: Thomas Wood --- tests/check_drm_clients | 2 +- tests/debugfs_emon_crash | 2 +- tests/drm_lib.sh | 22 ++ tests/drv_debugfs_reader | 2 +- tests/drv_missed_irq_hang | 14 +++---

[Intel-gfx] [PATCH v2 02/12] drm/i915: Calculate watermark related members in the crtc_state, v4.

This removes pre/post_wm_update from intel_crtc->atomic, and creates atomic state for it in intel_crtc. Changes since v1: - Rebase on top of wm changes. Changes since v2: - Split disable_cxsr into a separate patch. Changes since v3: - Move some of the changes to intel_wm_need_update.

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Only spin whilst waiting on the current request

On Tue, Dec 01, 2015 at 04:44:53PM +, Dave Gordon wrote: > On 01/12/15 15:58, Chris Wilson wrote: > >On Tue, Dec 01, 2015 at 03:47:34PM +, Dave Gordon wrote: > >>On 30/11/15 10:06, Tvrtko Ursulin wrote: > >>> > >>>On 29/11/15 08:48, Chris Wilson wrote: > Limit busywaiting only to the

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Disable FDI after the CRT port on LPT-H

On Wed, Dec 02, 2015 at 12:01:43PM -0200, Paulo Zanoni wrote: > 2015-12-01 11:08 GMT-02:00 : > > From: Ville Syrjälä > > > > Bspec modeset sequence tells us to disable the PCH transcoder and > > FDI after the CRT port on LPT-H, so

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Refactor LPT-H VGA dotclock disabling

On Wed, Dec 02, 2015 at 02:56:01PM -0200, Paulo Zanoni wrote: > 2015-12-01 11:08 GMT-02:00 : > > From: Ville Syrjälä > > > > Extract the LPT-H VGA dotclock disable to a separate function in > > anticipation of further use. > > > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED

On Thu, Dec 03, 2015 at 09:02:12AM +0100, Daniel Vetter wrote: > On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it > > forbidden to set

Re: [Intel-gfx] [PATCH] drm/i915: Extend LRC pinning to cover GPU context writeback

On Wed, Dec 02, 2015 at 05:02:07PM -0800, Yu Dai wrote: > I tested this with GuC submission enabled and it fixes the issue I found > during GPU reset. > > Reviewed-by: Alex Dai Queued for -next, thanks for the patch. -Daniel > > On 12/01/2015 06:48 AM, Nick Hoath wrote: >

Re: [Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl

On Tue, Dec 01, 2015 at 09:20:02AM +, Chris Wilson wrote: > On Tue, Dec 01, 2015 at 10:13:10AM +0100, Daniel Vetter wrote: > > On Tue, Dec 01, 2015 at 09:04:23AM +, Chris Wilson wrote: > > > On Tue, Dec 01, 2015 at 09:28:08AM +0100, Daniel Vetter wrote: > > > > On Mon, Nov 30, 2015 at

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Reject attempts at re-stealing encoders

On Thu, Dec 03, 2015 at 10:49:14AM +0100, Daniel Vetter wrote: > This can happen when we run out of encoders for a multi-crtc modeset, > or also when userspace is silly and tries to clone multiple connectors > that need the same encoder on the same crtc. > > Reported-and-Tested-and-Reviewed-by:

Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drm_lib.sh: Skip when i915 debugfs wasn't found

On 3 December 2015 at 06:45, Daniel Vetter wrote: > Instead of failing. We might want to move this into i915 tests > eventually, but this is good for now. > > Signed-off-by: Daniel Vetter > --- > tests/drm_lib.sh | 7 ++- > 1 file changed, 6

Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drm_lib.sh: Skip when i915 debugfs wasn't found

> > >-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Thomas Wood >Sent: Thursday, December 3, 2015 10:08 AM >To: Daniel Vetter >Cc: Intel Graphics Development >Subject: Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drm_lib.sh: Skip when i915

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Hide the atomic_read(reset_counter) behind a helper

On Tue, Dec 01, 2015 at 11:05:33AM +, Chris Wilson wrote: > This is just a little bit of syntatic sugar to hide the atomic_reads() > throughout the code to retrieve the current reset_counter. It also > provides the other utility functions to check the reset state on the > already read

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Prevent leaking of -EIO from i915_wait_request()

On Thu, Dec 03, 2015 at 10:14:54AM +0100, Daniel Vetter wrote: > > @@ -4078,9 +4067,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct > > drm_file *file) > > if (ret) > > return ret; > > > > - ret = i915_gem_check_wedge(_priv->gpu_error, false); > > - if (ret) > > -

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Leave FDI running after failed link training on LPT-H

On Wed, Dec 02, 2015 at 03:16:56PM -0200, Paulo Zanoni wrote: > 2015-12-01 11:08 GMT-02:00 : > > From: Ville Syrjälä > > > > Currently we disable some parts of FDI setup after a failed link > > training. But despite that we continue

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Hide the atomic_read(reset_counter) behind a helper

On Thu, Dec 03, 2015 at 09:57:01AM +0100, Daniel Vetter wrote: > On Tue, Dec 01, 2015 at 11:05:33AM +, Chris Wilson wrote: > > This is just a little bit of syntatic sugar to hide the atomic_reads() > > throughout the code to retrieve the current reset_counter. It also > > provides the other

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Hide the atomic_read(reset_counter) behind a helper

On Thu, Dec 03, 2015 at 09:02:16AM +, Chris Wilson wrote: > On Thu, Dec 03, 2015 at 09:57:01AM +0100, Daniel Vetter wrote: > > On Tue, Dec 01, 2015 at 11:05:33AM +, Chris Wilson wrote: > > > This is just a little bit of syntatic sugar to hide the atomic_reads() > > > throughout the code to

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Disable CLKOUT_DP bending on LPT/WPT as needed

On Wed, Dec 02, 2015 at 11:35:00AM -0200, Paulo Zanoni wrote: > 2015-12-01 11:08 GMT-02:00 : > > From: Ville Syrjälä > > > > When we want to use SPLL for FDI we want SSC, which means we have to > > disable clock bending for the PCH

Re: [Intel-gfx] [PATCH 09/10] drm/i915: Disable LPT-H VGA dotclock during crtc disable

On Wed, Dec 02, 2015 at 03:02:20PM -0200, Paulo Zanoni wrote: > 2015-12-01 11:08 GMT-02:00 : > > From: Ville Syrjälä > > > > Currently we leave the LPT-H VGA dotclock running after turning > > the pipe/fdi/port/etc. Propoerly disable

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED

On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it > forbidden to set it for LVDS/CRT as well. So let's move it out of the >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Prevent leaking of -EIO from i915_wait_request()

On Tue, Dec 01, 2015 at 11:05:35AM +, Chris Wilson wrote: > Reporting -EIO from i915_wait_request() has proven very troublematic > over the years, with numerous hard-to-reproduce bugs cropping up in the > corner case of where a reset occurs and the code wasn't expecting such > an error. > >

Re: [Intel-gfx] [PATCH 9/9] drm/atomic: Add encoder_mask to crtc_state.

On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote: > This allows iteration over encoders without requiring connection_mutex. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/drm_atomic_helper.c | 4 >

Re: [Intel-gfx] [PATCH v2 02/12] drm/i915: Calculate watermark related members in the crtc_state, v4.

On Thu, Dec 03, 2015 at 01:49:13PM +0100, Maarten Lankhorst wrote: > This removes pre/post_wm_update from intel_crtc->atomic, and > creates atomic state for it in intel_crtc. > > Changes since v1: > - Rebase on top of wm changes. > Changes since v2: > - Split disable_cxsr into a separate

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

Hi Dave - Another batch of drm/i915 fixes for v4.4, on top of the ones from earlier this week. One timeout handling regression fix from Chris, and backport of five patches from our -next to fix a power management related HDMI hotplug regression. BR, Jani. The following changes since commit

Re: [Intel-gfx] [PATCH v2 8/9] ALSA: hda - Skip ELD notification during PM process

On Tue, 01 Dec 2015 17:09:57 +0100, Takashi Iwai wrote: > > The ELD notification can be received asynchronously from the graphics > side, and this may happen just at the moment the sound driver is > processing the suspend or the resume, and it would confuse the whole > procedure. Since the ELD

Re: [Intel-gfx] [PATCH i-g-t 2/5] kms_frontbuffer_tracking: Make sink crc mandatory only for PSR.

2015-12-03 14:39 GMT-02:00 Rodrigo Vivi : > Unfortunately Sink CRC is not 100% reliable for all platforms. > So we cannot block FBC tests nor skip them when we are getting > unreliable Sink CRC results, or not getting them at all. > > Cc: Paulo Zanoni

Re: [Intel-gfx] [PATCH i-g-t 3/5] kms_frontbuffer_tracking: Skip on unreliable CRC.

2015-12-03 14:39 GMT-02:00 Rodrigo Vivi : > Even with all sink crc re-works we still have platforms > where after 6 vblanks it is unable to calculate the > sink crc. But if we don't get the sink crc it isn't true > that test failed, but that we have no ways to say test >

[Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU. These tests rely on the softpin patch in order to pin buffers to a certain VA.

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

Hi, On 03/12/15 08:36, Vinay Belgaumkar wrote: These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU. These tests rely on the softpin

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)

On Thu, Dec 03, 2015 at 01:06:44PM +0100, Maarten Lankhorst wrote: > Op 25-11-15 om 17:48 schreef Matt Roper: > > Plane state objects contain two copies of src/dest coordinates: the > > original (requested by userspace) coordinates in the base > > drm_plane_state object, and a second, clipped

Re: [Intel-gfx] [PATCH 12/29] drm/armada: Drop struct_mutex from cursor paths

On Mon, Nov 23, 2015 at 10:32:45AM +0100, Daniel Vetter wrote: > @@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc > *crtc, int x, int y) > if (!dcrtc->variant->has_spu_adv_reg) > return -EFAULT; > > - mutex_lock(>struct_mutex); >

[Intel-gfx] 4.0 -> 4.1 regression : after resume from s2ram both internal and external display of a docked ThinkPad ate black

> >>> commit e7d6f7d708290da1b7c92f533444b042c79412e0 > >>> Author: Dave Airlie > >>> Date: Mon Dec 8 13:23:37 2014 +1000 > >>> > >>> drm/i915: resume MST after reading back hw state > >> Is there anything else what I can do ? > >> > >> Current kernels up to 4.2.3

[Intel-gfx] [PATCH v7] drm/i915: Slaughter the thundering i915_wait_request herd

One particularly stressful scenario consists of many independent tasks all competing for GPU time and waiting upon the results (e.g. realtime transcoding of many, many streams). One bottleneck in particular is that each client waits on its own results, but every client is woken up after every

Re: [Intel-gfx] [PATCH v2] drm/i915: prevent out of range pt in the PDE macros (take 3)

On 06/10/15 12:53, Chris Wilson wrote: On Tue, Oct 06, 2015 at 12:21:05PM +0100, Dave Gordon wrote: ... although I still think my version is (slightly) easier to read. Or it could be improved even more by moving the increment of 'iter' to the end, making it one line shorter and perhaps helping

Re: [Intel-gfx] [PATCH i-g-t 3/5] kms_frontbuffer_tracking: Skip on unreliable CRC.

2015-12-03 17:44 GMT-02:00 Vivi, Rodrigo : > On Thu, 2015-12-03 at 15:05 -0200, Paulo Zanoni wrote: >> 2015-12-03 14:39 GMT-02:00 Rodrigo Vivi : >> > Even with all sink crc re-works we still have platforms >> > where after 6 vblanks it is unable to

Re: [Intel-gfx] Possible i915 regression with 4.4-rc

On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote: > Hi, > > I've experienced a few graphics issues recently, and I tend to believe > that it has happened since 4.4-rc. Namely, after some long time usage > on my HSW laptop (two or three days), the mouse cursor vanished > suddenly. It

[Intel-gfx] Possible i915 regression with 4.4-rc

Hi, I've experienced a few graphics issues recently, and I tend to believe that it has happened since 4.4-rc. Namely, after some long time usage on my HSW laptop (two or three days), the mouse cursor vanished suddenly. It kept pointing but just became invisible. Also, after some S3 cycles,

[Intel-gfx] [PATCH 6/7] drm/i915: Sanitize watermarks after hardware state readout (v4)

Although we can do a good job of reading out hardware state, the graphics firmware may have programmed the watermarks in a creative way that doesn't match how i915 would have chosen to program them. We shouldn't trust the firmware's watermark programming, but should rather re-calculate how we

[Intel-gfx] [PATCH 7/7] drm/i915: Add two-stage ILK-style watermark programming (v8)

In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means

[Intel-gfx] [PATCH 4/7] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state

When watermark calculation was moved up to the atomic check phase, the code was updated to calculate based on in-flight atomic state rather than already-committed state. However the hsw_compute_linetime_wm() didn't get updated and continued to pull values out of the currently-committed CRTC

[Intel-gfx] [PATCH 3/7] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)

Plane state objects contain two copies of src/dest coordinates: the original (requested by userspace) coordinates in the base drm_plane_state object, and a second, clipped copy (i.e., what we actually want to program to the hardware) in intel_plane_state. We've only been setting up the former

[Intel-gfx] [PATCH 1/7] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2)

If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best

[Intel-gfx] [PATCH 2/7] drm/i915: Extract plane dumping from intel_dump_pipe_config()

The plane information isn't important in most of the places where we dump the pipe config; the one place where it would be valuable is during initial HW state readout, but currently we dump the pipe config before FB's are reconstructed, so the data dumped is misleading anyway. Even worse, in

[Intel-gfx] [PATCH 5/7] drm/i915: Add extra paranoia to ILK watermark calculations

Our low-level watermark calculation functions don't get called when the CRTC is disabled or the relevant plane is invisible, so they should never see a zero htotal or zero bpp. However add some checks to ensure this is true so that we don't wind up dividing by zero if we make a mistake elsewhere

[Intel-gfx] [PATCH 0/7] Wrap up ILK-style atomic watermarks (v2)

Previous patch series was here: http://lists.freedesktop.org/archives/intel-gfx/2015-November/081270.html The changes since the last version are mainly minor fixes based on review feedback from Ville and Maarten. Matt Roper (7): drm/i915: Disable primary plane if we fail to reconstruct

Re: [Intel-gfx] [PATCH i-g-t 3/5] kms_frontbuffer_tracking: Skip on unreliable CRC.

On Thu, 2015-12-03 at 15:05 -0200, Paulo Zanoni wrote: > 2015-12-03 14:39 GMT-02:00 Rodrigo Vivi : > > Even with all sink crc re-works we still have platforms > > where after 6 vblanks it is unable to calculate the > > sink crc. But if we don't get the sink crc it isn't

[Intel-gfx] [maintainer-tools PATCH 2/2] dim: add a QUICKSTART section to dim.rst

Because just running dim help doesn't give you the greater picture of the workflow. All the text here is based on an email written by Daniel Vetter, so the credits go to him. Any mistakes were introduced by me. Credits-to: Daniel Vetter Signed-off-by: Paulo Zanoni

[Intel-gfx] [maintainer-tools PATCH 1/2] dim: use quotes when testing for empty string

Today I applied/pushed patches for the first time, and noticed that all my commits had exactly this: Link: http://patchwork.freedesktop.org/patch/msgid/ without the actual ID there. I assumed the ID would be set by some commit hook since our hooks seem to be able to talk to patchwork. Looks

Re: [Intel-gfx] Possible i915 regression with 4.4-rc

On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote: > On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote: > > On Thu, 03 Dec 2015 21:33:29 +0100, > > Ville Syrjälä wrote: > > > > > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote: > > > > Hi, > > > > > > > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms!

Hi! > Reported-by: Jens Axboe > Link: https://lkml.org/lkml/2015/11/12/621 > Cc: Jens Axboe > Cc; "Rogozhkin, Dmitry V" > Cc: Daniel Vetter > Cc: Tvrtko Ursulin > Cc: Eero

Re: [Intel-gfx] [PATCH i-g-t 3/5] kms_frontbuffer_tracking: Skip on unreliable CRC.

On Thu, 2015-12-03 at 17:59 -0200, Paulo Zanoni wrote: > 2015-12-03 17:44 GMT-02:00 Vivi, Rodrigo : > > On Thu, 2015-12-03 at 15:05 -0200, Paulo Zanoni wrote: > > > 2015-12-03 14:39 GMT-02:00 Rodrigo Vivi : > > > > Even with all sink crc re-works we

[Intel-gfx] [PATCH v9 3/3] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.

So far, the i915 driver and some other drivers set it to the drm_device, which doesn't allow one to know which DP a given aux channel is related to. Changing this to be the drm_connector provides proper nesting, still allowing one to get the drm_device from it. Some drivers already set it to the

[Intel-gfx] [PATCH v9 0/3] Add drm_dp_aux chardev support.

This series implement support to a drm_dp_aux chardev that allows reading and writing an arbitrary amount of bytes to arbitrary dpcd register addresses using regular read, write and lseek operations. Rafael Antognolli (3): drm/kms_helper: Add a common place to call init and exit functions.

[Intel-gfx] [PATCH v9 2/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

This module is heavily based on i2c-dev. Once loaded, it provides one dev node per DP AUX channel, named drm_dp_auxN, where N is an integer. It's possible to know which connector owns this aux channel by looking at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if the

[Intel-gfx] [PATCH v9 1/3] drm/kms_helper: Add a common place to call init and exit functions.

The module_init and module_exit functions will start here, and call the subsequent init's and exit's. Signed-off-by: Rafael Antognolli --- drivers/gpu/drm/Makefile| 4 ++- drivers/gpu/drm/drm_fb_helper.c | 9 +++

Re: [Intel-gfx] Possible i915 regression with 4.4-rc

On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote: > On Thu, 03 Dec 2015 21:33:29 +0100, > Ville Syrjälä wrote: > > > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote: > > > Hi, > > > > > > I've experienced a few graphics issues recently, and I tend to believe > > > that

Re: [Intel-gfx] [PATCH] drm/i915: Fix RPS pointer passed from wait_ioctl to i915_wait_request

On Wed, Dec 02, 2015 at 09:13:46AM +, Chris Wilson wrote: > In commit 2e1b873072dfe3bbcc158a9c21acde1ab0d36c55 [v4.2] > Author: Chris Wilson > Date: Mon Apr 27 13:41:22 2015 +0100 > > drm/i915: Convert RPS tracking to a intel_rps_client struct > > we

  1   2   >