Re: [Intel-gfx] [PATCH 3/8] drm/i915: Cope with request list state change during error state capture

On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote: > Since we're not synchronizing the ring request list during error state capture > the request list state might change between the time the corresponding error > request list was allocated and dimensioned to the time when the ring request

Re: [Intel-gfx] [PATCH] drm/i915: Partial revert of atomic watermark series

On Thu, Oct 08, 2015 at 03:28:25PM -0700, Matt Roper wrote: > It's been reported that the atomic watermark series triggers some > regressions on SKL, which we haven't been able to track down yet. Let's > temporarily revert these patches while we track down the root cause. > > This commit

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Unify execlist and legacy request life-cycles

On Fri, Oct 09, 2015 at 09:58:51AM +0200, Daniel Vetter wrote: > > > +static bool i915_gem_request_retireable(struct drm_i915_gem_request *req) > > > +{ > > > + return (i915_gem_request_completed(req, true) && > > > + (!req->elsp_submitted || req->ctx_complete)); > > > > I disagree with

Re: [Intel-gfx] [PATCH 4/8] drm/i915: NULL checking when capturing buffer objects during error state capture

On Fri, Oct 09, 2015 at 10:32:11AM +0200, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote: > > In the past vmas have sometimes turned out to be NULL when capturing buffer > > objects during error state capture. To avoid NULL pointer exceptions throw a > > WARNING

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote: > On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote: > > On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: > > The concern is that this isn't how SIG_SEGV works, it's a signal the > > thread who made the

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Unify execlist and legacy request life-cycles

On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote: > My idea was to create a new request for 3. which gets signalled by the > scheduler in intel_lrc_irq_handler. My idea was that we'd only create > these when a ctx switch might occur to avoid overhead, but I guess if we > just outright

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level

On 08/10/15 10:46, Chris Wilson wrote: On Thu, Oct 08, 2015 at 10:32:39AM +0100, Tvrtko Ursulin wrote: On 07/10/15 17:19, Chris Wilson wrote: On Wed, Oct 07, 2015 at 04:57:25PM +0100, Tvrtko Ursulin wrote: Hi, On 06/10/15 11:39, Chris Wilson wrote: Since the remove of the pin-ioctl, we

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Migrate to safe iterators in error state capture

On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote: > Using safe list iterators alleviates the problem of unsynchronized driver list > manipulations while error state capture is in the process of traversing lists. > > Signed-off-by: Tomas Elf > --- >

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: > The concern is that this isn't how SIG_SEGV works, it's a signal the > thread who made the invalid access gets directly. You never get a SIG_SEGV > for bad access

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote: > On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote: > > > > Hm if this still works the same way as on older platforms then pagefaults > > just read all 0 and writes go nowhere from the gpu. That generally also > > explains

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On Fri, Oct 09, 2015 at 10:55:26AM +0200, Daniel Vetter wrote: > On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote: > > On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote: > > > On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: > > > The concern is that this

Re: [Intel-gfx] [PATCH 4/8] drm/i915: NULL checking when capturing buffer objects during error state capture

On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote: > In the past vmas have sometimes turned out to be NULL when capturing buffer > objects during error state capture. To avoid NULL pointer exceptions throw a > WARNING and exit early and be prepared for the error state not being fully >

Re: [Intel-gfx] [PATCH 8/8] drm/i915: NULL check of unpin_work

On Fri, Oct 09, 2015 at 08:46:31AM +0100, Chris Wilson wrote: > On Thu, Oct 08, 2015 at 07:31:40PM +0100, Tomas Elf wrote: > > Avoid NULL pointer exceptions in the display driver for certain critical > > cases > > when unpin_work has turned out to be NULL. > > Nope, the machine reached a point

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

On Fri, Oct 09, 2015 at 10:38:18AM +0200, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote: > > Grab execlist lock when cleaning up execlist queues after GPU reset to avoid > > concurrency problems between the context event interrupt handler and the > > reset > >

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On 09/10/15 09:55, Daniel Vetter wrote: On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote: On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote: On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: The concern is that this isn't how SIG_SEGV works, it's a signal

Re: [Intel-gfx] [PATCH 5/8] drm/i915: vma NULL pointer check

On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote: > Sometimes the iterated vma objects are NULL apparently. Be aware of this while > iterating and do early exit instead of causing a NULL pointer exception. > > Signed-off-by: Tomas Elf > --- >

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote: > Grab execlist lock when cleaning up execlist queues after GPU reset to avoid > concurrency problems between the context event interrupt handler and the reset > path immediately following a GPU reset. > > Signed-off-by: Tomas Elf

Re: [Intel-gfx] [PATCH] igt/kms_addfb_basic: New subtest to check for fb modifier and tiling mode mismatch

On 08/10/15 09:55, Tvrtko Ursulin wrote: On 07/10/15 22:07, Vivek Kasireddy wrote: Hi Tvrtko, On Wed, 7 Oct 2015 15:07:30 +0100 Tvrtko Ursulin wrote: Hi, On 07/10/15 03:35, Vivek Kasireddy wrote: This new subtest will validate a Y-tiled object's tiling

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote: > On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote: > > On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote: > > > > > > Hm if this still works the same way as on older platforms then pagefaults > > > just read all 0 and

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote: > From: Chris Wilson > > A long time ago (before 3.14) we relied on a permanent pinning of the > ifbdev to lock the fb in place inside the GGTT. However, the > introduction of stealing the BIOS framebuffer and

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Unify execlist and legacy request life-cycles

On Fri, Oct 09, 2015 at 09:36:58AM +0100, Chris Wilson wrote: > On Fri, Oct 09, 2015 at 09:58:51AM +0200, Daniel Vetter wrote: > > > > +static bool i915_gem_request_retireable(struct drm_i915_gem_request > > > > *req) > > > > +{ > > > > + return (i915_gem_request_completed(req, true) && > >

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Mark getparam ioctl as DRM_UNLOCKED

On Tue, Sep 08, 2015 at 01:56:25PM +0200, Daniel Vetter wrote: > With kms all the data getparam looks at is actually invariant, and > certainly not protected by the global kms mutex. With ums all the > setup code is already racy as hell, so this won't make things any > worse. Correct. > I've

Re: [Intel-gfx] [PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction

Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: [snip] > diff --git a/drivers/gpu/drm/i915/intel_color_manager.c > b/drivers/gpu/drm/i915/intel_color_manager.c > index d5315b2..74f8fc3 100644 > --- a/drivers/gpu/drm/i915/intel_color_manager.c > +++

Re: [Intel-gfx] [PATCH 17/22] drm/i915: Attach color properties to CRTC

On 9 October 2015 at 20:29, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH 22/22] drm/i915: BDW: Pipe level CSC correction

Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: > 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

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

Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: > 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

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

Hi Rafael, [auto build test WARNING on drm/drm-next -- if it's inappropriate base, please ignore] config: mn10300-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod

Re: [Intel-gfx] [PATCH] igt/kms_addfb_basic: New subtest to check for fb modifier and tiling mode mismatch

Hi Tvrtko, On Fri, 9 Oct 2015 09:34:25 +0100 Tvrtko Ursulin wrote: > > > On 08/10/15 09:55, Tvrtko Ursulin wrote: > > On 07/10/15 22:07, Vivek Kasireddy wrote: > >> > >> Hi Tvrtko, > >> > >> On Wed, 7 Oct 2015 15:07:30 +0100 > >> Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 16/22] drm/i915: Commit color correction to CRTC

Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH 15/22] drm/i915: CHV: Pipe level CSC correction

On 9 October 2015 at 20:29, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH] drm/i915: Partial revert of atomic watermark series

Em Qui, 2015-10-08 às 15:28 -0700, Matt Roper escreveu: > It's been reported that the atomic watermark series triggers some > regressions on SKL, which we haven't been able to track down yet. > Let's > temporarily revert these patches while we track down the root cause. > > This commit squashes

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

Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: > 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

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

Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: > 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,

Re: [Intel-gfx] [PATCH 14/22] drm/i915: CHV: Pipe level degamma correction

Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: > 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

Re: [Intel-gfx] [PATCH 8/8] drm/i915: NULL check of unpin_work

On Thu, Oct 08, 2015 at 07:31:40PM +0100, Tomas Elf wrote: > Avoid NULL pointer exceptions in the display driver for certain critical cases > when unpin_work has turned out to be NULL. Nope, the machine reached a point where it cannot possibly reach, we want the OOPS. -Chris -- Chris Wilson,

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote: > Grab execlist lock when cleaning up execlist queues after GPU reset to avoid > concurrency problems between the context event interrupt handler and the reset > path immediately following a GPU reset. Hmm, my tree just does: static void

Re: [Intel-gfx] [PATCH v4] drm/i915: Determine the stolen memory base address on gen2

On Thu, Oct 08, 2015 at 12:08:20PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > There isn't an explicit stolen memory base register on gen2. > Some old comment in the i915 code suggests we should get it via > max_low_pfn_mapped, but that's

[Intel-gfx] As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

Hi, This started somewhere between Kernel 4.2 and 4.3-rc1, but I only noticed it a day ago. The first S3 suspend after a fresh boot works fine. Thereafter, suspends simply resume again immediately. I get the following errors on my console: [ 152.697247] i915 :00:02.0: GEM idle failed,

Re: [Intel-gfx] As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

Another regression for Jairo to track. -Daniel On Thu, Oct 08, 2015 at 11:43:39PM -0700, Doug Smythies wrote: > > Hi, > > This started somewhere between Kernel 4.2 and 4.3-rc1, > but I only noticed it a day ago. > > The first S3 suspend after a fresh boot works fine. > Thereafter, suspends

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On Thu, 2015-10-08 at 16:57 +0100, Chris Wilson wrote: > Correct me if I am wrong, but it looks like i915_svm implements the > lowlevel interface with the hardware, so by convention is intel_svm.c I think the plan is to drop the driver-mode interface altogether and use the OS-mode version that I

Re: [Intel-gfx] [PATCH 3/7] drm/i915: don't allocate fbcon from stolen memory if it's too big

On Thu, Oct 08, 2015 at 01:19:27PM -0700, Jesse Barnes wrote: > On 09/23/2015 08:52 AM, Paulo Zanoni wrote: > > Technology has evolved and now we have eDP panels with 3200x1800 > > resolution. In the meantime, the BIOS guys didn't change the default > > 32mb for stolen memory. On top of that, we

Re: [Intel-gfx] [PATCH 5/8] drm/i915: vma NULL pointer check

On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote: > Sometimes the iterated vma objects are NULL apparently. Be aware of this while > iterating and do early exit instead of causing a NULL pointer exception. Wrong. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Cope with request list state change during error state capture

On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote: > Since we're not synchronizing the ring request list during error state capture > the request list state might change between the time the corresponding error > request list was allocated and dimensioned to the time when the ring request

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Migrate to safe iterators in error state capture

On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote: > Using safe list iterators alleviates the problem of unsynchronized driver list > manipulations while error state capture is in the process of traversing lists. Wrong, this does not make anything safe. -Chris -- Chris Wilson, Intel

Re: [Intel-gfx] [PATCH 4/8] drm/i915: NULL checking when capturing buffer objects during error state capture

On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote: > In the past vmas have sometimes turned out to be NULL when capturing buffer > objects during error state capture. To avoid NULL pointer exceptions throw a > WARNING and exit early and be prepared for the error state not being fully >

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add support for stealing purgable stolen pages

On Thu, Oct 08, 2015 at 04:08:52PM +0100, Chris Wilson wrote: > On Thu, Oct 08, 2015 at 03:31:08PM +0100, Tvrtko Ursulin wrote: > > > > On 08/10/15 12:09, Chris Wilson wrote: > > >On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote: > > >>>-struct drm_i915_gem_object * > >

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote: > > On 28/09/15 15:14, Daniel Vetter wrote: > >On Mon, Sep 28, 2015 at 02:52:30PM +0100, Chris Wilson wrote: > >>On Mon, Sep 28, 2015 at 03:42:22PM +0200, Daniel Vetter wrote: > >>>On Wed, Sep 23, 2015 at 09:07:24PM +0100, Chris

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Unify execlist and legacy request life-cycles

On Thu, Oct 08, 2015 at 01:32:07PM +0100, Chris Wilson wrote: > On Tue, Oct 06, 2015 at 03:52:01PM +0100, Nick Hoath wrote: > > There is a desire to simplify the i915 driver by reducing the number of > > different code paths introduced by the LRC / execlists support. As the > > execlists request

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote: > > Hm if this still works the same way as on older platforms then pagefaults > just read all 0 and writes go nowhere from the gpu. That generally also > explains ever-increasing numbers of the CS execution pointer since it's > busy churning

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On Thu, Oct 08, 2015 at 11:46:08PM +0100, David Woodhouse wrote: > On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote: > > > > Could someone clarify what this means from the TDR point of view, > > please? When you say "context blew up" I'm guessing that you mean that > > come context caused the

Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix FBC buffer size checks

On Thu, Oct 01, 2015 at 07:57:12PM -0300, Paulo Zanoni wrote: > According to my experiments (and later confirmation from the hardware > developers), the maximum sizes mentioned in the specification delimit > how far in the buffer the hardware tracking can go. And the hardware > calculates the size

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Use safe list iterators

On Thu, Oct 08, 2015 at 07:31:38PM +0100, Tomas Elf wrote: > Error state capture is dependent on i915_gem_active_request() and > i915_gem_obj_is_pinned(). Since there is no synchronization between error > state > capture and the driver state we at least need to use safe list iterators in > these

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On Fri, Oct 09, 2015 at 09:28:37AM +0200, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 11:46:08PM +0100, David Woodhouse wrote: > > On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote: > > > > > > Could someone clarify what this means from the TDR point of view, > > > please? When you say

Re: [Intel-gfx] [PATCH] drm/i915: Remove wrong warning from i915_gem_context_clean

On Thu, Oct 08, 2015 at 04:12:31PM +0100, Michel Thierry wrote: > On 10/8/2015 3:37 PM, Tvrtko Ursulin wrote: > >From: Tvrtko Ursulin > > > >commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae > >Author: Tvrtko Ursulin > >Date: Mon Oct 5 13:26:36

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add support for stealing purgable stolen pages

On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote: > > Hi, > > On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote: > >From: Chris Wilson > > > >If we run out of stolen memory when trying to allocate an object, see if > >we can reap enough purgeable objects to free up enough

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

Hi Shashank, [auto build test WARNING on next-20151009 -- if it's inappropriate base, please ignore] reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'wedged' drivers/gpu/dr

Re: [Intel-gfx] [PATCH v4 1/2] drm/dp: Store the drm_connector device pointer on the helper.

On Tue, Sep 29, 2015 at 06:25:44PM +0200, Daniel Vetter wrote: > On Tue, Sep 29, 2015 at 05:27:33PM +0200, Lukas Wunner wrote: > > Hi Daniel, > > > > On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote: > > > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote: > > > > On Mon,

Re: [Intel-gfx] [PATCH 09/22] drm/i915: Create color management files

Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: [snip] > + > +/* Color management bit utilities */ > +#define GET_BIT_MASK(n) ((1 << n) - 1) > + > +/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */ > +#define GET_BITS(x, start, nbits)

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

Hi Shashank, [auto build test WARNING on next-20151009 -- if it's inappropriate base, please ignore] reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2582: warning: No description found for parameter 'wedged' drivers/gpu/dr

[Intel-gfx] [PATCH v5 0/2] 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. v2: - lseek is used to select the register to read/write - read/write are used instead of ioctl

[Intel-gfx] [PATCH v5 2/2] 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 v5 1/2] 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 00/20] tree-wide convert to memremap()

The memremap() api [1] was merged in 4.3 [2] with an initial implementation for x86 and a conversion of the pmem driver. Complete the conversion for the rest of the kernel. Feel free to either ack or directly apply a conversion-patch as I will defer the final removal patches until all the

Re: [Intel-gfx] [PATCH 10/22] drm/i915: Register color correction capabilities

Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: > From DRM color management: > > DRM color manager supports these color properties: > 1. "ctm": Color transformation matrix property, where a >color transformation matrix

[Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap

i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly map it with memremap rather than the implied cache setting of acpi_os_ioremap(). Cc: Daniel Vetter Cc: Jani Nikula Cc: intel-gfx@lists.freedesktop.org Cc: David Airlie

[Intel-gfx] [PATCH] drm/i915: revert a few more watermark commits

This is a squash of the following commits: Revert "drm/i915: Drop intel_update_sprite_watermarks" This reverts commit 47c99438b52d12df50e182583634a4cfede3c920. Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check" This reverts commit

Re: [Intel-gfx] [PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction

Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: > 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

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

Thanks for the review comments, Emil. Regards Shashank On 10/10/2015 3:53 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: This patch adds new variables in CRTC state, to hold respective color correction blobs. These blobs

Re: [Intel-gfx] [PATCH 10/22] drm/i915: Register color correction capabilities

Regards Shashank On 10/10/2015 3:51 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: From DRM color management: DRM color manager supports these color properties: 1. "ctm": Color transformation

Re: [Intel-gfx] [PATCH 14/22] drm/i915: CHV: Pipe level degamma correction

Regards Shashank On 10/10/2015 4:41 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: CHV/BSW supports Degamma color correction, which linearizes all the non-linear color values. This will be applied before Color

Re: [Intel-gfx] [PATCH 15/22] drm/i915: CHV: Pipe level CSC correction

Regards Shashank On 10/10/2015 5:13 AM, Emil Velikov wrote: On 9 October 2015 at 20:29, Shashank Sharma wrote: 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

Re: [Intel-gfx] [PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction

Regards Shashank On 10/10/2015 5:09 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: [snip] diff --git a/drivers/gpu/drm/i915/intel_color_manager.c b/drivers/gpu/drm/i915/intel_color_manager.c index d5315b2..74f8fc3 100644

Re: [Intel-gfx] [PATCH 16/22] drm/i915: Commit color correction to CRTC

Regards Shashank On 10/10/2015 4:54 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: The color correction blob values are loaded during set_property calls. This patch adds a function to find the blob and apply the correction

Re: [Intel-gfx] [PATCH 17/22] drm/i915: Attach color properties to CRTC

Regards Shashank On 10/10/2015 5:15 AM, Emil Velikov wrote: On 9 October 2015 at 20:29, Shashank Sharma wrote: Function intel_attach_color_properties_to_crtc attaches a color property to its CRTC object. This patch calls this function from crtc initialization

Re: [Intel-gfx] [PATCH 22/22] drm/i915: BDW: Pipe level CSC correction

Regards Shashank On 10/10/2015 5:24 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix that needs to be programmed into respective CSC registers. This patch

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

Regards Shashank On 10/10/2015 3:55 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: 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

Re: [Intel-gfx] [PATCH 09/22] drm/i915: Create color management files

Regards Shashank On 10/10/2015 4:17 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:28, Shashank Sharma wrote: [snip] + +/* Color management bit utilities */ +#define GET_BIT_MASK(n) ((1 << n) - 1) + +/* Read bits of a word from bit no. 'start'(lsb)

Re: [Intel-gfx] [PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction

Regards Shashank On 10/10/2015 4:37 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: CHV/BSW platform supports two different pipe level gamma correction modes, which are: 1. Legacy 8-bit mode 2. 10-bit CGM (Color Gamut

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

Regards Shashank On 10/10/2015 5:19 AM, Emil Velikov wrote: Hi Shashank, On 9 October 2015 at 20:29, Shashank Sharma wrote: BDW/SKL/BXT supports Degamma color correction feature, which linearizes the non-linearity due to gamma encoded color values. This will be

Re: [Intel-gfx] [PATCH 7/9] drm/i915: add fences to the request struct

On 10/09/2015 06:29 AM, David Woodhouse wrote: > On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote: >> >> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request { >> /** Execlists no. of times this request has been sent to the ELSP */ >> int elsp_submitted; >> >> + /* core

[Intel-gfx] [PATCH i-g-t 5/7] lib: Die if framebuffer GTT mapping fails

From: Ville Syrjälä Cairo helpfully allocates a new buffer for us when cairo_image_surface_create_for_data() is called with a NULL ptr. That means if gem_mmap__gtt() fails, we get a totally silent failure and nothing ever drawn into the framebuffer. Very confusing.

[Intel-gfx] [PATCH i-g-t 1/7] s/gem_mmap/gem_mmap__gtt/

From: Ville Syrjälä Get rid of the gem_mmap() alias of gem_mmap__gtt(). I don't see any point in having it. Signed-off-by: Ville Syrjälä --- demos/intel_sprite_on.c| 4 ++-- lib/igt_fb.c | 2 +-

[Intel-gfx] [PATCH i-g-t 2/7] lib: Document that gem_mmap__{cpu, gtt, wc} return NULL on failure

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- lib/ioctl_wrappers.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c index 80e1ec6..eb745bc 100644 ---

[Intel-gfx] [PATCH i-g-t 6/7] Make gem_mmap__{cpu, gtt, wc}() assert on failure

From: Ville Syrjälä Rename the current gem_mmap__{cpu,gtt,wc}() functions into __gem_mmap__{cpu,gtt,wc}(), and add back wrappers with the original name that assert that the pointer is valid. Most callers will expect a valid pointer and shouldn't have to bother with

Re: [Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

On 10/09/2015 02:07 AM, David Woodhouse wrote: > On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote: >> On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote: >>> On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote: Hm if this still works the same way as on older

[Intel-gfx] [PATCH i-g-t 7/7] Replace __gem_mmap__{cpu, gtt, wc}() + igt_assert() with gem_mmap__{cpu, gtt, wc}()

From: Ville Syrjälä gem_mmap__{cpu,gtt,wc}() already has the assert built in, so replace __gem_mmap__{cpu,gtt,wc}() + igt_assert() with it. Mostly done with coccinelle, with some manual help: @@ identifier I; expression E1, E2, E3, E4, E5, E6; @@ ( - I =

[Intel-gfx] [PATCH i-g-t 4/7] Sprinkle igt_assert(ptr) after gem_mmap__{cpu, gtt, wc}

From: Ville Syrjälä Do the following ptr = gem_mmap__{cpu,gtt,wc}() +igt_assert(ptr); whenever the code doesn't handle the NULL ptr in any kind of specific way. Makes it easier to move the assert into gem_mmap__{cpu,gtt,wc}() itself. Mostly done with

[Intel-gfx] [PATCH i-g-t 3/7] Remove gem_mmap__{cpu, gtt, wc} return value MAP_FAILED asserts

From: Ville Syrjälä gem_mmap__{cpu,gtt,wc} never return MAP_FAILED, it gets converted to NULL internally. So don't go asserting that the returned value is not MAP_FAILED. Done with coccinelle: @@ type T; identifier I; @@ ( I = gem_mmap__gtt(...); | I =

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Migrate to safe iterators in error state capture

On 09/10/2015 08:49, Chris Wilson wrote: On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote: Using safe list iterators alleviates the problem of unsynchronized driver list manipulations while error state capture is in the process of traversing lists. Wrong, this does not make anything

Re: [Intel-gfx] [PATCH 8/8] drm/i915: NULL check of unpin_work

On 09/10/2015 09:39, Daniel Vetter wrote: On Fri, Oct 09, 2015 at 08:46:31AM +0100, Chris Wilson wrote: On Thu, Oct 08, 2015 at 07:31:40PM +0100, Tomas Elf wrote: Avoid NULL pointer exceptions in the display driver for certain critical cases when unpin_work has turned out to be NULL. Nope,

Re: [Intel-gfx] [PATCH] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

On Fri, 09 Oct 2015, Chris Wilson wrote: > On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote: >> From: Chris Wilson >> >> A long time ago (before 3.14) we relied on a permanent pinning of the >> ifbdev to lock the fb in place inside

Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level

On 09/10/15 12:51, Chris Wilson wrote: If the impossible happens and we fail to rebind a VMA in the middle of rebinding all VMA for an object we currently bail out and leave the object in an inconsistent state. Attempt to unwind the incomplete update by reverting all updated VMA back to the

Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level

On 09/10/15 13:19, Chris Wilson wrote: On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote: On 09/10/15 12:51, Chris Wilson wrote: If the impossible happens and we fail to rebind a VMA in the middle of rebinding all VMA for an object we currently bail out and leave the object in

Re: [Intel-gfx] [PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings

On Thu, 08 Oct 2015, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote: >> On Thu, 2015-10-08 at 11:43 +0300, ville.syrj...@linux.intel.com wrote: >> > From: Ville Syrjälä >> > >> > EDID detailed timings have a

Re: [Intel-gfx] [PATCH 5/8] drm/i915: vma NULL pointer check

On 09/10/2015 08:48, Chris Wilson wrote: On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote: Sometimes the iterated vma objects are NULL apparently. Be aware of this while iterating and do early exit instead of causing a NULL pointer exception. Wrong. -Chris So the NULL pointer

Re: [Intel-gfx] [PATCH 4/8] drm/i915: NULL checking when capturing buffer objects during error state capture

On 09/10/2015 08:49, Chris Wilson wrote: On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote: In the past vmas have sometimes turned out to be NULL when capturing buffer objects during error state capture. To avoid NULL pointer exceptions throw a WARNING and exit early and be prepared for

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Cope with request list state change during error state capture

On 09/10/2015 09:28, Daniel Vetter wrote: On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote: Since we're not synchronizing the ring request list during error state capture the request list state might change between the time the corresponding error request list was allocated and

Re: [Intel-gfx] [PATCH 4/8] drm/i915: NULL checking when capturing buffer objects during error state capture

On 09/10/2015 09:32, Daniel Vetter wrote: On Thu, Oct 08, 2015 at 07:31:36PM +0100, Tomas Elf wrote: In the past vmas have sometimes turned out to be NULL when capturing buffer objects during error state capture. To avoid NULL pointer exceptions throw a WARNING and exit early and be prepared

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Use safe list iterators

On 09/10/2015 11:38, Chris Wilson wrote: On Fri, Oct 09, 2015 at 11:27:48AM +0100, Tomas Elf wrote: On 09/10/2015 08:41, Chris Wilson wrote: On Thu, Oct 08, 2015 at 07:31:38PM +0100, Tomas Elf wrote: Error state capture is dependent on i915_gem_active_request() and i915_gem_obj_is_pinned().

Re: [Intel-gfx] [PATCH] drm/i915: Unwind partial VMA rebinding after failure in set-cache-level

On Fri, Oct 09, 2015 at 01:11:47PM +0100, Tvrtko Ursulin wrote: > > On 09/10/15 12:51, Chris Wilson wrote: > >If the impossible happens and we fail to rebind a VMA in the middle of > >rebinding all VMA for an object we currently bail out and leave the > >object in an inconsistent state. Attempt

  1   2   >