[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] dma_resv: prime lockdep annotations

== Series Details == Series: series starting with [1/3] dma_resv: prime lockdep annotations URL : https://patchwork.freedesktop.org/series/68958/ State : success == Summary == CI Bug Log - changes from CI_DRM_7258_full -> Patchwork_15124_full ===

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Switch obj->mm.lock lockdep annotations on its head

Quoting Daniel Vetter (2019-11-04 19:37:18) > The trouble with having a plain nesting flag for locks which do not > naturally nest (unlike block devices and their partitions, which is > the original motivation for nesting levels) is that lockdep will > never spot a true deadlock if you screw up. >

[Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head

The trouble with having a plain nesting flag for locks which do not naturally nest (unlike block devices and their partitions, which is the original motivation for nesting levels) is that lockdep will never spot a true deadlock if you screw up. This patch is an attempt at trying better, by highlig

Re: [Intel-gfx] [PATCH 3/3] drm/i915: use might_lock_nested in get_pages annotation

Quoting Daniel Vetter (2019-11-04 19:37:20) > So strictly speaking the existing annotation is also ok, because we > have a chain of > > obj->mm.lock#I915_MM_GET_PAGES -> fs_reclaim -> obj->mm.lock > > (the shrinker cannot get at an object while we're in get_pages, hence > this is safe). But it's

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/i915: Switch obj->mm.lock lockdep annotations on its head (rev2)

== Series Details == Series: series starting with drm/i915: Switch obj->mm.lock lockdep annotations on its head (rev2) URL : https://patchwork.freedesktop.org/series/68956/ State : warning == Summary == $ dim checkpatch origin/drm-tip c1f4ce7bcff4 drm/i915: Switch obj->mm.lock lockdep annotat

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v5 1/4] lib/i915: Add minimum GTT alignment helper

Quoting Janusz Krzysztofik (2019-11-04 19:13:27) > Some tests assume 4kB offset alignment while using softpin. That > assumption may be wrong on future GEM backends with possibly larger > minimum page sizes. As a result, those tests may either fail on > softpin at offsets which are incorrectly al

Re: [Intel-gfx] [PATCH v2 1/5] drm/dsi: clean up DSI data type definitions

On Mon, 04 Nov 2019, Thierry Reding wrote: > On Mon, Oct 28, 2019 at 05:00:43PM +0200, Jani Nikula wrote: >> Rename picture parameter set (it's a long packet, not a long write) and >> compression mode (it's not a DCS command) enumerations according to the >> DSI specification. Order the types acco

Re: [Intel-gfx] [PATCH v2 3/5] drm/dsi: add missing DSI DCS commands

On Mon, Oct 28, 2019 at 05:00:45PM +0200, Jani Nikula wrote: > Update from the DCS specification. > > Cc: Vandita Kulkarni > Signed-off-by: Jani Nikula > --- > include/video/mipi_display.h | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/include/video/mipi_display.h b/inclu

[Intel-gfx] [PATCH 06/10] drm/i915: Remove i915->kernel_context

Allocate only an internal intel_context for the kernel_context, forgoing a global GEM context for internal use as we only require a separate address space (for our own protection). Now having weaned GT from requiring ce->gem_context, we can stop referencing it entirely. This also means we no longe

[Intel-gfx] [PATCH 09/10] drm/i915/gt: Pull GT initialisation under intel_gt_init()

Begin pulling the GT setup underneath a single GT umbrella; let intel_gt take ownership of its engines! As hinted, the complication is the lifetime of the probed engine versus the active lifetime of the GT backends. We need to detect the engine layout early and keep it until the end so that we can

[Intel-gfx] [PATCH 04/10] drm/i915: Drop GEM context as a direct link from i915_request

Keep the intel_context as being the primary state for i915_request, with the GEM context a backpointer from the low level state for the rarer cases we need client information. Our goal is to remove such references to clients from the backend, and leave the HW submission agnostic to client interface

[Intel-gfx] [PATCH 03/10] drm/i915/selftests: Mock the engine sorting for easy validation

To make exploration of different sorting orders and presentation of the engines via the uabi easier, wrap the basic engine registration into a mock (aka standalone) selftest. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine_user.c | 4 + .../gpu/drm/i91

[Intel-gfx] [PATCH 10/10] drm/i915/gt: Merge engine init/setup loops

Now that we don't need to create GEM contexts in the middle of engine construction, we can pull the engine init/setup loops together. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 118 +++--- drivers/gpu/drm/i915/gt/intel_gt.c| 5 - dri

[Intel-gfx] [PATCH 01/10] drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request

As we start peeking into requests for longer and longer, e.g. incorporating use of spinlocks when only protected by an rcu_read_lock(), we need to be careful in how we reset the request when recycling and need to preserve any barriers that may still be in use as the request is reset for reuse. Sig

[Intel-gfx] [PATCH 05/10] drm/i915: Push the use-semaphore marker onto the intel_context

Instead of rummaging through the intel_context to peek at the GEM context in the middle of request submission to decide whether to use semaphores, store that information on the intel_context itself. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 52 +-

[Intel-gfx] [PATCH 07/10] drm/i915: Move i915_gem_init_contexts() earlier

As the GEM global context setup is now independent of the GT state (although GT does currently still depending upon the global i915->kernel_context), we can move its init earlier, leaving the gt init ready to extracted. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_context.c

[Intel-gfx] [PATCH 08/10] drm/i915/gt: Defer engine registration until fully initialised

Only add the engine to the available set of uabi engines once it has been fully initialised and we know we want it in the public set. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Michał Wajdeczko Cc: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++- 1 file changed, 2 ins

[Intel-gfx] [PATCH 02/10] drm/i915/selftests: Perform some basic cycle counting of MI ops

Some basic information that is useful to know, such as how many cycles is a MI_NOOP. Signed-off-by: Chris Wilson Cc: Anna Karas Cc: Tvrtko Ursulin --- .../i915/gem/selftests/i915_gem_object_blt.c | 15 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 339 +- drivers/gpu/drm

[Intel-gfx] [PATCH V8 0/6] mdev based hardware virtio offloading support

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and re

[Intel-gfx] [PATCH V8 1/6] mdev: class id support

Mdev bus only supports vfio driver right now, so it doesn't implement match method. But in the future, we may add drivers other than vfio, the first driver could be virtio-mdev. This means we need to add device class id support in bus match method to pair the mdev device and mdev driver correctly.

[Intel-gfx] [PATCH V8 2/6] modpost: add support for mdev class id

Add support to parse mdev class id table. Reviewed-by: Parav Pandit Signed-off-by: Jason Wang --- drivers/vfio/mdev/vfio_mdev.c | 2 ++ scripts/mod/devicetable-offsets.c | 3 +++ scripts/mod/file2alias.c | 11 +++ 3 files changed, 16 insertions(+) diff --git a/drivers/vf

[Intel-gfx] [PATCH V8 3/6] mdev: introduce device specific ops

Currently, except for the create and remove, the rest of mdev_parent_ops is designed for vfio-mdev driver only and may not help for kernel mdev driver. With the help of class id, this patch introduces device specific callbacks inside mdev_device structure. This allows different set of callback to b

[Intel-gfx] [PATCH V8 4/6] mdev: introduce virtio device and its device ops

This patch implements basic support for mdev driver that supports virtio transport for kernel virtio driver. Signed-off-by: Jason Wang --- drivers/vfio/mdev/mdev_core.c| 21 + drivers/vfio/mdev/mdev_private.h | 2 + include/linux/mdev.h | 6 ++ include/linux/mdev_virtio_

[Intel-gfx] [PATCH V8 5/6] virtio: introduce a mdev based transport

This patch introduces a new mdev transport for virtio. This is used to use kernel virtio driver to drive the mediated device that is capable of populating virtqueue directly. A new virtio-mdev driver will be registered to the mdev bus, when a new virtio-mdev device is probed, it will register the

Re: [Intel-gfx] [PATCH v2 4/5] drm/dsi: rename MIPI_DCS_SET_PARTIAL_AREA to MIPI_DCS_SET_PARTIAL_ROWS

On Mon, Oct 28, 2019 at 05:00:46PM +0200, Jani Nikula wrote: > The DCS command has been named SET_PARTIAL_ROWS in the DCS spec since > v1.02, for more than a decade. Rename the enumeration to match the spec. > > v2: add comment about the rename (David Lechner) > > Cc: David Lechner > Cc: Vandita

[Intel-gfx] [PATCH V8 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework

This sample driver creates mdev device that simulate virtio net device over virtio mdev transport. The device is implemented through vringh and workqueue. A device specific dma ops is to make sure HVA is used directly as the IOVA. This should be sufficient for kernel virtio driver to work. Only 'v

Re: [Intel-gfx] [PATCH v2 5/5] drm/dsi: add helpers for DSI compression mode and PPS packets

On Mon, Oct 28, 2019 at 05:00:47PM +0200, Jani Nikula wrote: > Add helper functions for sending the DSI compression mode and picture > parameter set data type packets. For the time being, limit the support > to using VESA DSC 1.1 and the default PPS. This may need updating if the > need arises for

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915: Switch obj->mm.lock lockdep annotations on its head (rev2)

== Series Details == Series: series starting with drm/i915: Switch obj->mm.lock lockdep annotations on its head (rev2) URL : https://patchwork.freedesktop.org/series/68956/ State : success == Summary == CI Bug Log - changes from CI_DRM_7260 -> Patchwork_15125 =

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request

== Series Details == Series: series starting with [01/10] drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request URL : https://patchwork.freedesktop.org/series/68975/ State : warning == Summary == $ dim checkpatch origin/drm-tip 53c420dd53fa drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_reques

Re: [Intel-gfx] [PATCH 1/5] dma-buf: add dynamic DMA-buf handling v14

On Tue, Oct 29, 2019 at 11:40:45AM +0100, Christian König wrote: > On the exporter side we add optional explicit pinning callbacks. Which are > called when the importer doesn't implement dynamic handling, move notification > or need the DMA-buf locked in place for its use case. > > On the importer

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request

== Series Details == Series: series starting with [01/10] drm/i915: Use a ctor for TYPESAFE_BY_RCU i915_request URL : https://patchwork.freedesktop.org/series/68975/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7260 -> Patchwork_15126

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mdev based hardware virtio offloading support

== Series Details == Series: mdev based hardware virtio offloading support URL : https://patchwork.freedesktop.org/series/68977/ State : warning == Summary == $ dim checkpatch origin/drm-tip 13ef49f3db39 mdev: class id support f1c9c66837b2 modpost: add support for mdev class id 4fa47f7bf9b5 md

Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head

On Tue, 5 Nov 2019 at 09:01, Daniel Vetter wrote: > > The trouble with having a plain nesting flag for locks which do not > naturally nest (unlike block devices and their partitions, which is > the original motivation for nesting levels) is that lockdep will > never spot a true deadlock if you scr

Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify

On Tue, Oct 29, 2019 at 11:40:49AM +0100, Christian König wrote: > Implement the importer side of unpinned DMA-buf handling. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 28 - > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +

Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head

On Tue, Nov 05, 2019 at 10:49:41AM +, Matthew Auld wrote: > On Tue, 5 Nov 2019 at 09:01, Daniel Vetter wrote: > > > > The trouble with having a plain nesting flag for locks which do not > > naturally nest (unlike block devices and their partitions, which is > > the original motivation for nest

Re: [Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote: > We can't copy_*_user while holding reservations, that will (soon even > for nouveau) lead to deadlocks. And it breaks the cross-driver > contract around dma_resv. > > Fix this by adding a slowpath for when we need relocations, and by

Re: [Intel-gfx] [PATCH] drm/i915: Document locking guidelines

Dave, ping for Acked-by here so we can merge? You already gave an early ack in IRC while travelling. Regards, Joonas Quoting Joonas Lahtinen (2019-08-30 13:50:53) > To ensure cross-driver locking compatibility, document the expected > guidelines for implementing the GEM locking in i915. Note that

[Intel-gfx] ✓ Fi.CI.BAT: success for mdev based hardware virtio offloading support

== Series Details == Series: mdev based hardware virtio offloading support URL : https://patchwork.freedesktop.org/series/68977/ State : success == Summary == CI Bug Log - changes from CI_DRM_7260 -> Patchwork_15127 Summary --- **SUC

[Intel-gfx] [PATCH i-g-t] igt: Another combinatorial exercise for blits

The aim of this test is to combine gem_linear_blits, gem_tiled_blits etc into one test runner that covers investigation into HW alignment issues as well as driver boundaries (relocs, access, thrashing). See also gem_concurrent_blits which looks for coherency issues between parallel execution. Sig

[Intel-gfx] [PATCH] drm/i915/selftests/blt: try to be more resilient against the GGTT

For a tiny shared address space, where parts of it might already be reserved, we should expect to hit the occasional -ENOSPC. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112176 Signed-off-by: Matthew Auld Cc: Chris Wilson --- .../i915/gem/selftests/i915_gem_object_blt.c | 103 ++

Re: [Intel-gfx] [PATCH] drm/i915/selftests/blt: try to be more resilient against the GGTT

Quoting Matthew Auld (2019-11-05 11:21:15) > For a tiny shared address space, where parts of it might already be > reserved, we should expect to hit the occasional -ENOSPC. Yeah, it's a bug though. It's on my todo list to demonstrate the bug 100% with just a bunch of parallel requests. A simple wa

Re: [Intel-gfx] [PATCH] drm/i915: Drop inspection of execbuf flags during evict

Quoting Chris Wilson (2019-10-31 13:12:55) > With the goal of removing the serialisation from around execbuf, we will > no longer have the privilege of there being a single execbuf in flight > at any time and so will only be able to inspect the user's flags within > the carefully controlled execbuf

[Intel-gfx] [PATCH v3] drm/i915: Create dumb buffer from LMEM

When LMEM is supported, dumb buffer preferred to be created from LMEM. v2: Parameters are reshuffled. [Chris] v3: s/region_id/mem_type Signed-off-by: Ramalingam C cc: Matthew Auld --- drivers/gpu/drm/i915/i915_gem.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-)

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Reset CSB pointers by mmio as well

== Series Details == Series: drm/i915/execlists: Reset CSB pointers by mmio as well URL : https://patchwork.freedesktop.org/series/68945/ State : success == Summary == CI Bug Log - changes from CI_DRM_7252_full -> Patchwork_15121_full Summa

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915/dsc: make parameter arrays const

== Series Details == Series: series starting with [v2,1/4] drm/i915/dsc: make parameter arrays const URL : https://patchwork.freedesktop.org/series/68947/ State : success == Summary == CI Bug Log - changes from CI_DRM_7252_full -> Patchwork_15122_full ==

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting

Chris Wilson writes: > As the scratch buf is shared between the two requests on both engines, > we need to wait for both to finish using the buffer before we reset it. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Tvrtko Ursulin > --- > tests/i915/gem_exec_balancer.c | 2 +- > 1 f

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Display WA2006604312 is needed from ICL onwards

== Series Details == Series: drm/i915: Display WA2006604312 is needed from ICL onwards URL : https://patchwork.freedesktop.org/series/68932/ State : success == Summary == CI Bug Log - changes from CI_DRM_7252_full -> Patchwork_15120_full Su

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting

Quoting Mika Kuoppala (2019-11-05 11:34:23) > Chris Wilson writes: > > > As the scratch buf is shared between the two requests on both engines, > > we need to wait for both to finish using the buffer before we reset it. > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > Cc: Tvrtko Ur

Re: [Intel-gfx] [PATCH v3] drm/i915: Create dumb buffer from LMEM

Quoting Ramalingam C (2019-11-05 11:30:29) > When LMEM is supported, dumb buffer preferred to be created from LMEM. > > v2: > Parameters are reshuffled. [Chris] > v3: > s/region_id/mem_type > > Signed-off-by: Ramalingam C > cc: Matthew Auld > --- > drivers/gpu/drm/i915/i915_gem.c | 17

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting

Chris Wilson writes: > Quoting Mika Kuoppala (2019-11-05 11:34:23) >> Chris Wilson writes: >> >> > As the scratch buf is shared between the two requests on both engines, >> > we need to wait for both to finish using the buffer before we reset it. >> > >> > Signed-off-by: Chris Wilson >> > Cc:

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting

Quoting Mika Kuoppala (2019-11-05 11:46:53) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2019-11-05 11:34:23) > >> Chris Wilson writes: > >> > >> > As the scratch buf is shared between the two requests on both engines, > >> > we need to wait for both to finish using the buffer before we

Re: [Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl

Op 05-11-2019 om 12:04 schreef Daniel Vetter: > On Mon, Nov 04, 2019 at 06:38:00PM +0100, Daniel Vetter wrote: >> We can't copy_*_user while holding reservations, that will (soon even >> for nouveau) lead to deadlocks. And it breaks the cross-driver >> contract around dma_resv. >> >> Fix this by ad

Re: [Intel-gfx] [RFC 1/2] drm/i915: add display uncore helpers

Quoting Jani Nikula (2019-10-29 12:51:55) > Add convenience helpers for the most common uncore operations with > struct drm_i915_private * as context rather than struct intel_uncore *. > > The goal is to replace all instances of I915_READ(), > I915_POSTING_READ(), and I915_WRITE() in display/ with

Re: [Intel-gfx] [PATCH] drm/i915/lmem: add the fake lmem region

On Thu, 31 Oct 2019 at 20:40, Chris Wilson wrote: > > Quoting Arkadiusz Hiler (2019-10-31 12:40:35) > > On Wed, Oct 30, 2019 at 10:22:37PM +, Matthew Auld wrote: > > > On Tue, 29 Oct 2019 at 16:51, Matthew Auld wrote: > > > > > > > > Intended for upstream testing so that we can still exercise

[Intel-gfx] [PATCH] drm/i915/selftests: Exercise parallel blit operations on a single ctx

Make sure that our code is robust enough to handle multiple threads trying to clear objects for a single client context. This brings the joy of a shared GGTT to all! References: https://bugs.freedesktop.org/show_bug.cgi?id=112176 Signed-off-by: Chris Wilson Cc: Matthew Auld --- .../i915/gem/sel

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/dsc: make parameter arrays const

On Mon, 04 Nov 2019, Manasi Navare wrote: > On Mon, Nov 04, 2019 at 04:14:36PM +0200, Jani Nikula wrote: >> No need for them to be mutable. >> >> Cc: Manasi Navare >> Signed-off-by: Jani Nikula > > Agree that these params are constants > > Reviewed-by: Manasi Navare Thanks for the review, pus

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915/dsc: make parameter arrays const (rev2)

== Series Details == Series: series starting with [v2,1/4] drm/i915/dsc: make parameter arrays const (rev2) URL : https://patchwork.freedesktop.org/series/68947/ State : success == Summary == CI Bug Log - changes from CI_DRM_7261 -> Patchwork_15128

Re: [Intel-gfx] [RFC 1/2] drm/i915: add display uncore helpers

On Tue, 05 Nov 2019, Joonas Lahtinen wrote: > Quoting Jani Nikula (2019-10-29 12:51:55) >> Add convenience helpers for the most common uncore operations with >> struct drm_i915_private * as context rather than struct intel_uncore *. >> >> The goal is to replace all instances of I915_READ(), >> I9

[Intel-gfx] [PATCH] drm/i915/bios: use a flag for vbt hdmi level shift presence

The pre-initialized magic value is a bit silly, switch to a flag instead. While at it, clean up the validity checks. No functional changes apart from the added checks. Cc: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_bios.c | 10 +- drivers/gpu/drm/i91

Re: [Intel-gfx] RFC: Unpinned DMA-buf handling

On Tue, Oct 29, 2019 at 11:40:44AM +0100, Christian König wrote: > The basic idea stayed the same since the last version of those patches. > The exporter can provide explicit pin/unpin functions and the importer a > move_notify callback. This allows us to avoid pinning buffers while > importers hav

Re: [Intel-gfx] [PATCH] drm/i915/bios: use a flag for vbt hdmi level shift presence

On Tue, Nov 05, 2019 at 03:39:00PM +0200, Jani Nikula wrote: > The pre-initialized magic value is a bit silly, switch to a flag > instead. While at it, clean up the validity checks. No functional > changes apart from the added checks. > > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > --- > d

Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify

On Tue, Nov 5, 2019 at 2:39 PM Christian König wrote: > > Am 05.11.19 um 11:52 schrieb Daniel Vetter: > > On Tue, Oct 29, 2019 at 11:40:49AM +0100, Christian König wrote: > >> Implement the importer side of unpinned DMA-buf handling. > >> > >> Signed-off-by: Christian König > >> --- > >> driver

Re: [Intel-gfx] [PATCH] drm/i915/bios: use a flag for vbt hdmi level shift presence

On Tue, 05 Nov 2019, Ville Syrjälä wrote: > On Tue, Nov 05, 2019 at 03:39:00PM +0200, Jani Nikula wrote: >> The pre-initialized magic value is a bit silly, switch to a flag >> instead. While at it, clean up the validity checks. No functional >> changes apart from the added checks. >> >> Cc: Ville

Re: [Intel-gfx] [PATCH v2 3/5] drm/dsi: add missing DSI DCS commands

On Tue, 05 Nov 2019, Thierry Reding wrote: > On Mon, Oct 28, 2019 at 05:00:45PM +0200, Jani Nikula wrote: >> Update from the DCS specification. >> >> Cc: Vandita Kulkarni >> Signed-off-by: Jani Nikula >> --- >> include/video/mipi_display.h | 10 ++ >> 1 file changed, 10 insertions(+) >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests/blt: try to be more resilient against the GGTT

== Series Details == Series: drm/i915/selftests/blt: try to be more resilient against the GGTT URL : https://patchwork.freedesktop.org/series/68987/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15129 Summ

Re: [Intel-gfx] [RESEND PATCH 1/3] drm/i915/dmabuf: Implement pwrite() callback

On Thu, Oct 31, 2019 at 09:29:56AM +0100, Janusz Krzysztofik wrote: > We need dmabuf specific pwrite() callback utilizing dma-buf API, > otherwise GEM_PWRITE IOCTL will no longer work with dma-buf backed > (i.e., PRIME imported) objects on hardware with no mappable aperture. > > Signed-off-by: Jan

[Intel-gfx] [PATCH v5] drm/i915: FB backing gem obj should reside in LMEM

If Local memory is supported by hardware, we want framebuffer backing gem objects from local memory. if the backing obj is not from LMEM, pin_to_display is failed. v2: memory regions are correctly assigned to obj->memory_regions [tvrtko] migration failure is reported as debug log [Tvrtko] v3:

[Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Skip if we have no aperture and no mmap_gtt

If the device does not expose an aperture for indirect access with detiling functionality, the kernel rejects an attempt to create such a mapping with -ENODEV. If the ioctl is not supported, we can skip all of our mmap_gtt specific tests. Signed-off-by: Chris Wilson Cc: Abdiel Janulgue Cc: Matth

[Intel-gfx] [PATCH] drm/i915/gem: Early rejection of no-aperture map_ggtt

If the device does not have an aperture through which we can indirectly access and detile the buffers, simply reject the ioctl. Later we can extend the ioctl to support different modes, but as an extension the user must opt in and explicitly control the mmap type (viz MMAP_OFFSET_IOCTL). Signed-of

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Create dumb buffer from LMEM (rev3)

== Series Details == Series: drm/i915: Create dumb buffer from LMEM (rev3) URL : https://patchwork.freedesktop.org/series/66950/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15130 Summary --- **SUC

[Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Skip if we have no aperture and no mmap_gtt

If the device does not expose an aperture for indirect access with detiling functionality, the kernel rejects an attempt to create such a mapping with -ENODEV. If the ioctl is not supported, we can skip all of our mmap_gtt specific tests. Signed-off-by: Chris Wilson Cc: Abdiel Janulgue Cc: Matth

Re: [Intel-gfx] [RESEND PATCH 1/3] drm/i915/dmabuf: Implement pwrite() callback

Hi Daniel, On Tuesday, November 5, 2019 3:27:55 PM CET Daniel Vetter wrote: > On Thu, Oct 31, 2019 at 09:29:56AM +0100, Janusz Krzysztofik wrote: > > We need dmabuf specific pwrite() callback utilizing dma-buf API, > > otherwise GEM_PWRITE IOCTL will no longer work with dma-buf backed > > (i.e., P

[Intel-gfx] ✗ GitLab.Pipeline: warning for i915/gem_mmap_gtt: Skip if we have no aperture and no mmap_gtt

== Series Details == Series: i915/gem_mmap_gtt: Skip if we have no aperture and no mmap_gtt URL : https://patchwork.freedesktop.org/series/69000/ State : warning == Summary == Did not get list of undocumented tests for this run, something is wrong! Other than that, pipeline status: FAILED. s

Re: [Intel-gfx] [PATCH] drm/i915/gem: Early rejection of no-aperture map_ggtt

On 05/11/2019 16.53, Chris Wilson wrote: > If the device does not have an aperture through which we can indirectly > access and detile the buffers, simply reject the ioctl. Later we can > extend the ioctl to support different modes, but as an extension the > user must opt in and explicitly contro

Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify

Am 05.11.19 um 14:50 schrieb Daniel Vetter: > On Tue, Nov 5, 2019 at 2:39 PM Christian König > wrote: >> Am 05.11.19 um 11:52 schrieb Daniel Vetter: >>> On Tue, Oct 29, 2019 at 11:40:49AM +0100, Christian König wrote: Implement the importer side of unpinned DMA-buf handling. Signed-

Re: [Intel-gfx] [PATCH] drm/i915/bios: use a flag for vbt hdmi level shift presence

On Tue, Nov 05, 2019 at 03:59:57PM +0200, Jani Nikula wrote: > On Tue, 05 Nov 2019, Ville Syrjälä wrote: > > On Tue, Nov 05, 2019 at 03:39:00PM +0200, Jani Nikula wrote: > >> The pre-initialized magic value is a bit silly, switch to a flag > >> instead. While at it, clean up the validity checks. N

Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify

On Tue, Nov 5, 2019 at 4:20 PM Koenig, Christian wrote: > > Am 05.11.19 um 14:50 schrieb Daniel Vetter: > > On Tue, Nov 5, 2019 at 2:39 PM Christian König > > wrote: > >> Am 05.11.19 um 11:52 schrieb Daniel Vetter: > >>> On Tue, Oct 29, 2019 at 11:40:49AM +0100, Christian König wrote: > Impl

Re: [Intel-gfx] [PATCH 08/10] drm/i915/gt: Defer engine registration until fully initialised

Hi Chris, On Tue, Nov 05, 2019 at 09:21:13AM +, Chris Wilson wrote: > Only add the engine to the available set of uabi engines once it has > been fully initialised and we know we want it in the public set. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > Cc: Michał Wajdeczko > Cc: An

Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head

Just some nits/typos that made this a little difficult for me to read. I am still trying to understand what is going on, so unfortunately I have no comments on the patch. >-Original Message- >From: Intel-gfx On Behalf Of >Daniel Vetter >Sent: Tuesday, November 5, 2019 4:02 AM >To: Intel

Re: [Intel-gfx] [PATCH] drm/i915/bios: use a flag for vbt hdmi level shift presence

On Tue, Nov 05, 2019 at 05:21:06PM +0200, Ville Syrjälä wrote: > On Tue, Nov 05, 2019 at 03:59:57PM +0200, Jani Nikula wrote: > > On Tue, 05 Nov 2019, Ville Syrjälä wrote: > > > On Tue, Nov 05, 2019 at 03:39:00PM +0200, Jani Nikula wrote: > > >> The pre-initialized magic value is a bit silly, swit

[Intel-gfx] [PATCH i-g-t v5] tests/gem_exec_reloc: Don't filter out invalid addresses

Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable addresses for !ppgtt") introduced filtering of shared GTT addresses possibly in use. Unfortunately, that filtering doesn't distinguish between addresses actually in use and otherwise invalid softpin offsets. If for example incorrect

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Exercise parallel blit operations on a single ctx

== Series Details == Series: drm/i915/selftests: Exercise parallel blit operations on a single ctx URL : https://patchwork.freedesktop.org/series/68995/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15131

Re: [Intel-gfx] [PATCH i-g-t v5 2/4] tests/gem_exec_reloc: Don't filter out invalid addresses

Hi, On Monday, November 4, 2019 9:46:28 PM CET Vanshidhar Konda wrote: > On Mon, Nov 04, 2019 at 06:13:28PM +0100, Janusz Krzysztofik wrote: > >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable > >addresses for !ppgtt") introduced filtering of addresses possibly > >occupied by other

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: use a flag for vbt hdmi level shift presence

== Series Details == Series: drm/i915/bios: use a flag for vbt hdmi level shift presence URL : https://patchwork.freedesktop.org/series/68998/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15132 Summary --

[Intel-gfx] [PATCH v10 0/2] Refactor Gen11+ SAGV support

For Gen11+ platforms BSpec suggests disabling specific QGV points separately, depending on bandwidth limitations and current display configuration. Thus it required adding a new PCode request for disabling QGV points and some refactoring of already existing SAGV code. Also had to refactor intel_can

[Intel-gfx] [PATCH v10 2/2] drm/i915: Restrict qgv points which don't have enough bandwidth.

According to BSpec 53998, we should try to restrict qgv points, which can't provide enough bandwidth for desired display configuration. Currently we are just comparing against all of those and take minimum(worst case). v2: Fixed wrong PCode reply mask, removed hardcoded values. v3: Forbid si

[Intel-gfx] [PATCH v10 1/2] drm/i915: Refactor intel_can_enable_sagv

Currently intel_can_enable_sagv function contains a mix of workarounds for different platforms some of them are not valid for gens >= 11 already, so lets split it into separate functions. v2: - Rework watermark calculation algorithm to attempt to calculate Level 0 watermark with ad

Re: [Intel-gfx] [PATCH V8 1/6] mdev: class id support

On Tue, 5 Nov 2019 17:32:35 +0800 Jason Wang wrote: > Mdev bus only supports vfio driver right now, so it doesn't implement > match method. But in the future, we may add drivers other than vfio, > the first driver could be virtio-mdev. This means we need to add > device class id support in bus m

Re: [Intel-gfx] [PATCH V8 2/6] modpost: add support for mdev class id

On Tue, 5 Nov 2019 17:32:36 +0800 Jason Wang wrote: > Add support to parse mdev class id table. > > Reviewed-by: Parav Pandit > Signed-off-by: Jason Wang > --- > drivers/vfio/mdev/vfio_mdev.c | 2 ++ > scripts/mod/devicetable-offsets.c | 3 +++ > scripts/mod/file2alias.c | 11

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: FB backing gem obj should reside in LMEM

== Series Details == Series: drm/i915: FB backing gem obj should reside in LMEM URL : https://patchwork.freedesktop.org/series/68999/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15133 Summary ---

Re: [Intel-gfx] [PATCH V8 3/6] mdev: introduce device specific ops

On Tue, 5 Nov 2019 17:32:37 +0800 Jason Wang wrote: > Currently, except for the create and remove, the rest of > mdev_parent_ops is designed for vfio-mdev driver only and may not help > for kernel mdev driver. With the help of class id, this patch > introduces device specific callbacks inside md

Re: [Intel-gfx] [PATCH V8 4/6] mdev: introduce virtio device and its device ops

On Tue, 5 Nov 2019 17:32:38 +0800 Jason Wang wrote: > This patch implements basic support for mdev driver that supports > virtio transport for kernel virtio driver. > > Signed-off-by: Jason Wang > --- > drivers/vfio/mdev/mdev_core.c| 21 + > drivers/vfio/mdev/mdev_private.h | 2 + >

[Intel-gfx] [PATCH 2/2] drm/i915: Switch intel_crtc_disable_noatomic() to intel_ types

From: Ville Syrjälä It's hard to see what is going on when the function mixes drm_ and intel_ types. Switch to intel_ types. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 65 ++-- 1 file changed, 33 insertions(+), 32 deletions(-) diff --git a/

[Intel-gfx] [PATCH 1/2] drm/i915: Frob the correct crtc state in intel_crtc_disable_noatomic()

From: Ville Syrjälä The uapi vs. hw state split introduced a bug in intel_crtc_disable_noatomic() where it's not frobbing an already freed temp crtc state instead of adjusting the crtc state we are really left with. Fix that by making a cleaner separation beteen the two. This causes explosions o

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Refactor Gen11+ SAGV support (rev8)

== Series Details == Series: Refactor Gen11+ SAGV support (rev8) URL : https://patchwork.freedesktop.org/series/68028/ State : warning == Summary == $ dim checkpatch origin/drm-tip 962b1132a55c drm/i915: Refactor intel_can_enable_sagv -:191: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor Gen11+ SAGV support (rev8)

== Series Details == Series: Refactor Gen11+ SAGV support (rev8) URL : https://patchwork.freedesktop.org/series/68028/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 ___ Intel-gfx mailing list Intel-gfx@lists.freede

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Early rejection of no-aperture map_ggtt

== Series Details == Series: drm/i915/gem: Early rejection of no-aperture map_ggtt URL : https://patchwork.freedesktop.org/series/69001/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15134 Summary ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for Refactor Gen11+ SAGV support (rev8)

== Series Details == Series: Refactor Gen11+ SAGV support (rev8) URL : https://patchwork.freedesktop.org/series/68028/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15135 Summary --- **FAILURE**

Re: [Intel-gfx] [PATCH V8 3/6] mdev: introduce device specific ops

On Tue, 5 Nov 2019 17:50:25 +0100 Cornelia Huck wrote: > On Tue, 5 Nov 2019 17:32:37 +0800 > Jason Wang wrote: > > > Currently, except for the create and remove, the rest of > > mdev_parent_ops is designed for vfio-mdev driver only and may not help > > for kernel mdev driver. With the help of

Re: [Intel-gfx] [PATCH V8 4/6] mdev: introduce virtio device and its device ops

On Tue, 5 Nov 2019 17:32:38 +0800 Jason Wang wrote: > This patch implements basic support for mdev driver that supports > virtio transport for kernel virtio driver. > > Signed-off-by: Jason Wang > --- > drivers/vfio/mdev/mdev_core.c| 21 + > drivers/vfio/mdev/mdev_private.h | 2 + >

  1   2   >