[Intel-gfx] [REGRESSION] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

Hi, my system (always) locks up when booting a next-20170515 kernel. No oops. Sending magic sysrqs over serial doesn't cause any reaction. Last few console messages before death are: [7.089221] Console: switching to colour frame buffer device 128x48 [7.101470] radeon :01:00.0:

[Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

Face the fact, there are Display Port sink and branch devices out there in the wild that don't follow the Display Port specifications, or they have bugs, or just otherwise require special treatment. Start a common quirk database the drivers can query based on the DP device identification. At least

[Intel-gfx] [PATCH 4/4] drm/i915: Detect USB-C specific dongles before reducing M and N

The Analogix 7737 DP to HDMI converter requires reduced M and N values when to operate correctly at HBR2. We tried to reduce the M/N values for all devices in commit 9a86cda07af2 ("drm/i915/dp: reduce link M/N parameters"), but that regressed some other sinks. Detect this IC by its OUI value of

[Intel-gfx] [PATCH 1/4] drm/dp: add helper for reading DP sink/branch device desc from DPCD

Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_dp_helper.c | 35 +++ include/drm/drm_dp_helper.h | 19 +++ 2 files changed, 54 insertions(+) diff --git

[Intel-gfx] [PATCH 2/4] drm/i915: use drm DP helper to read DPCD desc

Switch to using the common DP helpers instead of using our own. v2: also remove leftover struct intel_dp_desc (Daniel) Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 37

[Intel-gfx] [PATCH 0/4] drm/dp: device identification and quirks ~v3

Update on [1]. BR, Jani. [1] cover.1495030890.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1495030890.git.jani.nikula@intel.com Jani Nikula (4): drm/dp: add helper for reading DP sink/branch device desc from DPCD drm/i915: use drm DP helper to read DPCD desc drm/dp:

[Intel-gfx] [PATCH] drm/i915: Fix new -Wint-in-bool-context gcc compiler warning

This commit fixes the following compiler warning: drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’: drivers/gpu/drm/i915/intel_dsi.c:1487:23: warning: ?: using integer constants in boolean context [-Wint-in-bool-context] PORT_A ? PORT_C : PORT_A), Signed-off-by: Hans

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Building on top of the previous patch which exported the concept > of engine classes and instances, we can also use this instead of > the current awkward engine selection uAPI. > > This

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/gvt: reorder the shadow ppgtt update process by adding entry first

On to, 2017-05-18 at 02:23 +, Zhang, Tina wrote: > > > > > -Original Message- > > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > > Behalf Of Joonas Lahtinen > > Sent: Monday, May 15, 2017 6:50 PM > > > > To: Zhang, Tina ; > > > >

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

On ti, 2017-05-16 at 07:53 +, Dong, Chuanxiao wrote: > > > > Thanks Joonas. If to fail with -EIO, how about for the other two checks: " > > if > > (!is_supported_device(dev_priv))" and " if (!i915.enable_execlists)"? > > Currently these two cases are failed with 0 instead of -EIO. Looks like

Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On Wed, 17 May 2017, Clint Taylor wrote: > On 05/17/2017 07:25 AM, Jani Nikula wrote: >> Face the fact, there are Display Port sink and branch devices out there >> in the wild that don't follow the Display Port specifications, or they >> have bugs, or just otherwise

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

Hi Dave, drm/i915 fixes for v4.12-rc2. BR, Jani. The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-05-18-1

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/gvt: Dmabuf support for GVT-g

On Thu, May 18, 2017 at 05:50:04PM +0800, Xiaoguang Chen wrote: > +#define GEN8_DECODE_PTE(pte) \ > + ((dma_addr_t)(u64)pte) >> 12) & 0x7ffULL) << 12)) > + > +static struct sg_table *intel_vgpu_gem_get_pages( > + struct drm_i915_gem_object *obj) > +{ > + struct

Re: [Intel-gfx] Call trace on 4.12.0-rc1

Hi, On 17-05-17 11:36, Ville Syrjälä wrote: On Tue, May 16, 2017 at 10:43:39PM +0200, Hans de Goede wrote: Hi, On 05/16/2017 09:55 PM, FKr wrote: Hi, I'm using 4.12.0-rc1 from https://github.com/jwrdegoede/linux-sunxi and got the following weird trace yesterday. Previously I've been getting

[Intel-gfx] [PATCH 0/2] Remaining patches for WM cleanup series

This series contains remaining two patches from wm cleanup series https://patchwork.freedesktop.org/series/20152/ Initial 10 patches already got merged in tree so sending remaining 2 separately. Kumar, Mahesh (2): drm/i915/skl: New ddb allocation algorithm drm/i915/skl+: consider max

[Intel-gfx] [PATCH 2/2] drm/i915/skl+: consider max supported plane pixel rate while scaling

From: "Kumar, Mahesh" A display resolution is only supported if it meets all the restrictions below for Maximum Pipe Pixel Rate. The display resolution must fit within the maximum pixel rate output from the pipe. Make sure that the display pipe is able to feed pixels at

[Intel-gfx] [PATCH 1/2] drm/i915/skl: New ddb allocation algorithm

From: "Kumar, Mahesh" This patch implements new DDB allocation algorithm as per HW team recommendation. 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

Re: [Intel-gfx] [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic API, but realizing that userspace is likely to take >

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915: Add format modifiers for Intel

On 18 May 2017 at 02:14, Ben Widawsky wrote: > On 17-05-17 01:20:50, Emil Velikov wrote: >> >> Hi Ben, >> >> A couple of small questions/suggestions that I hope you find useful. >> Please don't block any of this work based on my comments. >> >> On 16 May 2017 at 22:31, Ben

[Intel-gfx] [PATCH v2 4/5] drm/i915/gvt: Dmabuf support for GVT-g

dmabuf for GVT-g can be exported to users who can use the dmabuf to show the desktop of vm which use intel vgpu. Currently we provide query and create new dmabuf operations. Users of dmabuf can cache some created dmabufs and related information such as the framebuffer's address, size, tiling

[Intel-gfx] [PATCH v2 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf

User space will try to create a management fd for the dma-buf operation. Using this management fd user can query the plane information and create a dma-buf fd if necessary. GVT-g will handle the life cycle of the management fd and will align the life cycle of the fd with the vfio device. User

[Intel-gfx] [PATCH v2 3/5] drm/i915/gvt: Frame buffer decoder support for GVT-g

decode frambuffer attributes of primary, cursor and sprite plane Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/gvt/Makefile | 3 +- drivers/gpu/drm/i915/gvt/display.c| 2 +- drivers/gpu/drm/i915/gvt/display.h| 2 +

[Intel-gfx] [PATCH v2 1/5] drm/i915/gvt: Extend the GVT-g architecture to support vfio device region

Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/gvt/kvmgt.c | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 1ae0b40..3c6a02b 100644 ---

[Intel-gfx] [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g

OpRegion is needed to support display related operation for intel vgpu. A vfio device region is added to intel vgpu to deliver the host OpRegion information to user space so user space can construct the OpRegion for vgpu. Signed-off-by: Bing Niu Signed-off-by: Xiaoguang Chen

[Intel-gfx] [PATCH v2 0/5] drm/i915/gvt: Dma-buf support for GVT-g

v2->v1: 1) create a management fd for dma-buf operations. 2) alloc gem object's backing storage in gem obj's get_pages() callback. This patch set adds the dma-buf support for intel GVT-g. dma-buf is a uniform mechanism to share DMA buffers across different devices and sub-systems. dma-buf for

Re: [Intel-gfx] [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote: > +/* > + * DRM_MODE_REFLECT_ > + * > + * Signals that the contents of a drm plane has been reflected in > + * the axis. Still vague. Also you didn't respond to my comment about the use of past tense. > + * > + * This define is

Re: [Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

On 18 May 2017 at 01:46, Ben Widawsky wrote: >>> + blob_size += modifiers_size; >>> + >>> + blob = drm_property_create_blob(dev, blob_size, NULL); >>> + if (IS_ERR(blob)) >>> + return -1; >>> + >> >> Maybe propagate the exact error... Hmm we

[Intel-gfx] [PATCH 16/24] drm/i915: Async GPU relocation processing

If the user requires patching of their batch or auxiliary buffers, we currently make the alterations on the cpu. If they are active on the GPU at the time, we wait under the struct_mutex for them to finish executing before we rewrite the contents. This happens if shared relocation trees are used

[Intel-gfx] [PATCH 21/24] drm/i915: Allow contexts to be unreferenced locklessly

If we move the actual cleanup of the context to a worker, we can allow the final free to be called from any context and avoid undue latency in the caller. v2: Negotiate handling the delayed contexts free by flushing the workqueue before calling i915_gem_context_fini() and performing the final

[Intel-gfx] [PATCH 23/24] drm/i915: Keep a recent cache of freed contexts objects for reuse

Keep the recently freed context objects for reuse. This allows us to use the current GGTT bindings and dma bound pages, avoiding any clflushes as required. We mark the objects as purgeable under memory pressure, and reap the list of freed objects as soon as the device is idle. Signed-off-by:

[Intel-gfx] [PATCH 07/24] drm/i915: Split vma exec_link/evict_link

Currently the vma has one link member that is used for both holding its place in the execbuf reservation list, and in any eviction list. This dual property is quite tricky and error prone. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala

[Intel-gfx] [PATCH 24/24] RFC drm/i915: Expose a PMU interface for perf queries

The first goal is to be able to measure GPU (and invidual ring) busyness without having to poll registers from userspace. (Which not only incurs holding the forcewake lock indefinitely, perturbing the system, but also runs the risk of hanging the machine.) As an alternative we can use the perf

[Intel-gfx] [PATCH 19/24] drm/i915/scheduler: Support user-defined priorities

Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work. The user can adjust the context's priority

[Intel-gfx] [PATCH 20/24] drm/i915: Group all the global context information together

Create a substruct to hold all the global context state under drm_i915_private. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 4 +-- drivers/gpu/drm/i915/i915_drv.c | 9 +++--- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 22/24] drm/i915: Enable rcu-only context lookups

Whilst the contents of the context is still protected by the big struct_mutex, this is not much of an improvement. It is just one tiny step towards reducing our BKL. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h| 16 +--

[Intel-gfx] [PATCH 09/24] drm/i915: Pass vma to relocate entry

We can simplify our tracking of pending writes in an execbuf to the single bit in the vma->exec_entry->flags, but that requires the relocation function knowing the object's vma. Pass it along. Note we have only been using a single bit to track flushing since commit

[Intel-gfx] [PATCH 05/24] drm/i915: Amalgamate execbuffer parameter structures

Combine the two slightly overlapping parameter structures we pass around the execbuffer routines into one. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 550

[Intel-gfx] [PATCH 04/24] drm/i915: Reinstate reservation_object zapping for batch_pool objects

I removed the zapping of the reservation_object->fence array of shared fences prematurely. We don't yet have the code to zap that array when retiring the object, and so currently it remains possible to continually grow the shared array trapping requests when reusing the batch_pool object across

[Intel-gfx] [PATCH 01/24] drm/i915/selftests: Pretend to be a gfx pci device

Set the class on our mock pci device to GFX. This should be useful for utilities like intel-iommu that special case gfx devices. References: https://bugs.freedesktop.org/show_bug.cgi?id=101080 Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 08/24] drm/i915: Store a direct lookup from object handle to vma

The advent of full-ppgtt lead to an extra indirection between the object and its binding. That extra indirection has a noticeable impact on how fast we can convert from the user handles to our internal vma for execbuffer. In order to bypass the extra indirection, we use a resizable hashtable to

[Intel-gfx] [PATCH 13/24] drm/i915: First try the previous execbuffer location

When choosing a slot for an execbuffer, we ideally want to use the same address as last time (so that we don't have to rebind it) and the same address as expected by the user (so that we don't have to fixup any relocations pointing to it). If we first try to bind the incoming execbuffer->offset

[Intel-gfx] [PATCH 10/24] drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations

If we write a relocation into the buffer, we require our own implicit synchronisation added after the start of the execbuf, outside of the user's control. As we may end up clflushing, or doing the patch itself on the GPU, asynchronously we need to look at the implicit serialisation on obj->resv

[Intel-gfx] [PATCH 11/24] drm/i915: Eliminate lots of iterations over the execobjects array

The major scaling bottleneck in execbuffer is the processing of the execobjects. Creating an auxiliary list is inefficient when compared to using the execobject array we already have allocated. Reservation is then split into phases. As we lookup up the VMA, we try and bind it back into active

[Intel-gfx] [PATCH 06/24] drm/i915: Use vma->exec_entry as our double-entry placeholder

This has the benefit of not requiring us to manipulate the vma->exec_link list when tearing down the execbuffer, and is a marginally cheaper test to detect the user error. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH 18/24] drm/i915: Convert execbuf to use struct-of-array packing for critical fields

When userspace is doing most of the work, avoiding relocs (using NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we still spend a lot of time processing the arrays in execbuf, even though we now should have nothing to do most of the time. One issue that becomes readily apparent

[Intel-gfx] [PATCH 15/24] drm/i915: Allow execbuffer to use the first object as the batch

Currently, the last object in the execlist is the always the batch. However, when building the batch buffer we often know the batch object first and if we can use the first slot in the execlist we can emit relocation instructions relative to it immediately and avoid a separate pass to adjust the

[Intel-gfx] [PATCH 14/24] drm/i915: Wait upon userptr get-user-pages within execbuffer

This simply hides the EAGAIN caused by userptr when userspace causes resource contention. However, it is quite beneficial with highly contended userptr users as we avoid repeating the setup costs and kernel-user context switches. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH 17/24] drm/i915: Stash a pointer to the obj's resv in the vma

During execbuf, a mandatory step is that we add this request (this fence) to each object's reservation_object. Inside execbuf, we track the vma, and to add the fence to the reservation_object then means having to first chase the obj, incurring another cache miss. We can reduce the number of cache

[Intel-gfx] [PATCH 02/24] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Currently, we only mark the CPU cache as dirty if we skip a clflush. This leads to some confusion where we have to ask if the object is in the write domain or missed a clflush. If we always mark the cache as dirty, this becomes a much simply question to answer. The goal remains to do as few

[Intel-gfx] [PATCH 12/24] drm/i915: Store a persistent reference for an object in the execbuffer cache

If we take a reference to the object/vma when it is first used in an execbuf, we can keep that reference until the object's file-local handle is closed. Thereby saving a frequent ref/unref pair. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c

[Intel-gfx] [PATCH 03/24] drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty

For ease of use (i.e. avoiding a few checks and function calls), store the object's cache coherency next to the cache is dirty bit. Signed-off-by: Chris Wilson Cc: Dongwon Kim Cc: Matt Roper ---

Re: [Intel-gfx] [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

Hi Rob, On 18 May 2017 at 02:39, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic API, but realizing that userspace is

Re: [Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

On Wed, May 17, 2017 at 05:46:18PM -0700, Ben Widawsky wrote: > On 17-05-17 01:06:16, Emil Velikov wrote: > >Hi Ben, > > > >On 16 May 2017 at 22:31, Ben Widawsky wrote: > >> Updated blob layout (Rob, Daniel, Kristian, xerpi) > >> > >> v2: > >> * Removed __packed, and alignment

[Intel-gfx] [BACKPORT v4.12-rc1] drm/i915: Do not sync RCU during shrinking

Due to the complex dependencies between workqueues and RCU, which are not easily detected by lockdep, do not synchronize RCU during shrinking. On low-on-memory systems (mem=1G for example), the RCU sync leads to all system workqueus freezing and unrelated lockdep splats are displayed according to

Re: [Intel-gfx] [PATCH v3 1/3] drm: Plumb modifiers through plane init

On Wed, May 17, 2017 at 05:26:14PM -0700, Ben Widawsky wrote: > On 17-05-17 11:17:57, Liviu Dudau wrote: > > On Tue, May 16, 2017 at 02:31:24PM -0700, Ben Widawsky wrote: > > > This is the plumbing for supporting fb modifiers on planes. Modifiers > > > have already been introduced to some extent,

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

On pe, 2017-05-12 at 03:20 +, Li, Weinan Z wrote: > > Thanks Joonas' guidance. > I add 4 labels in intel_vgt_balloon for cleaning up ballooned space, the > reserved size > will increase when one balloon space reserve success, and will clean up if > anyone reserve > fail step by step. Yes,

Re: [Intel-gfx] [PATCH i-g-t v2 00/13] Fix IGTs for Android

Patches 1-4 and 6-13 are Reviewed-by: Petri Latvala Nitpicks on the commit message on patch 6 (replied to it). -- Petri Latvala On Tue, May 16, 2017 at 03:24:49PM +0200, Arkadiusz Hiler wrote: > IGTs are broken for Android since the introduction of dependency on

Re: [Intel-gfx] [PATCH i-g-t 06/13] tools/Android.mk: Add guc_logger and l3_parity skip list

On Tue, May 16, 2017 at 03:24:55PM +0200, Arkadiusz Hiler wrote: > Those tools does not build on Android due to "Linux-only" dependencies. s/does/do/ "to" missing in title. -- Petri Latvala > > Let's blacklist them for now. > > Signed-off-by: Arkadiusz Hiler

[Intel-gfx] [PATCH 11/12] drm/i915/skl: New ddb allocation algorithm

From: "Kumar, Mahesh" This patch implements new DDB allocation algorithm as per HW team recommendation. 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

Re: [Intel-gfx] [PATCH] drm/i915: Cancel reset-engine if we couldn't find an active request

On Wed, May 17, 2017 at 06:11:06PM -0700, Michel Thierry wrote: > On 17/05/17 13:52, Chris Wilson wrote: > >On Wed, May 17, 2017 at 01:41:34PM -0700, Michel Thierry wrote: > >>@@ -2827,21 +2829,35 @@ int i915_gem_reset_prepare_engine(struct > >>intel_engine_cs *engine) > >> > >>if

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Detect USB-C specific dongles before reducing M and N

On Wed, May 17, 2017 at 05:25:16PM +0300, Jani Nikula wrote: > The Analogix 7737 DP to HDMI converter requires reduced M and N values > when to operate correctly at HBR2. Detect this IC by its OUI value of > 0x0022B9 via the DPCD quirk list. Commit message is a bit confusing since this sounds

Re: [Intel-gfx] [PATCH 2/4] drm/i915: use drm DP helper to read DPCD desc

On Wed, May 17, 2017 at 05:25:14PM +0300, Jani Nikula wrote: > Switch to using the common DP helpers instead of using our own. > > Signed-off-by: Jani Nikula Forgot to remove struct intel_dp_desc, otherwise lgtm. Reviewed-by: Daniel Vetter > ---

<    1   2