[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/69035/ State : success == Summary == CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15144 Summary ---

[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/69035/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1d9bb32715e2 mdev: class id support 8dbc3a9ca293 modpost: add support for mdev class id 9af49130974f

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == CI Bug Log - changes from CI_DRM_7262_full -> Patchwork_15132_full

[Intel-gfx] [PATCH] drm/i915/userptr: Try to acquire the page lock around set_page_dirty()

set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules,

Re: [Intel-gfx] [PATCH 1/5] drm/i915/userptr: Beware recursive lock_page()

Quoting Chris Wilson (2019-07-16 13:49:27) > Following a try_to_unmap() we may want to remove the userptr and so call > put_pages(). However, try_to_unmap() acquires the page lock and so we > must avoid recursively locking the pages ourselves -- which means that > we cannot safely acquire the lock

[Intel-gfx] [PATCH] drm/i915: switch intel_ddi_init() to intel types

Prefer using intel_encoder and pass the base where needed rather than keeping both encoder and intel_encoder variables around. v2: actually add all changes to the patch Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_ddi.c | 56 1 file changed, 28

[Intel-gfx] [PATCH V9 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

[Intel-gfx] [PATCH V9 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

[Intel-gfx] [PATCH V9 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 --- MAINTAINERS | 1 + drivers/vfio/mdev/mdev_core.c| 21 + drivers/vfio/mdev/mdev_private.h | 2 + include/linux/mdev.h

[Intel-gfx] [PATCH V9 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

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

Add support to parse mdev class id table. Reviewed-by: Parav Pandit Reviewed-by: Cornelia Huck 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

[Intel-gfx] [PATCH V9 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] ✗ Fi.CI.BAT: failure for drm/i915: switch intel_ddi_init() to intel types

== Series Details == Series: drm/i915: switch intel_ddi_init() to intel types URL : https://patchwork.freedesktop.org/series/69031/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15143 Summary ---

[Intel-gfx] [PATCH V9 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

[Intel-gfx] [PATCH] drm/i915: switch intel_ddi_init() to intel types

Prefer using intel_encoder and pass the base where needed rather than keeping both encoder and intel_encoder variables around. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_ddi.c | 56 1 file changed, 27 insertions(+), 29 deletions(-) diff --git

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == CI Bug Log - changes from CI_DRM_7262_full -> Patchwork_15131_full

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == CI Bug Log - changes from CI_DRM_7262_full -> Patchwork_15130_full Summary

Re: [Intel-gfx] i915 HDCP 2.2 TX encryption on Teledyne test instrument

Moving to #intel-gfx Hi, Glad that I could help you! On 2019-11-05 at 21:56:28 +, Voldman, Mikhail wrote: > Hello Ramalingam, > > Thank you for quick response. > Your information is very helpful. > But can you elaborate: > > In your product, If you want to enable the HDCP always based

[Intel-gfx] [drm-tip:drm-tip 1865/1875] stacktrace.c:undefined reference to `save_stack_trace'

Hi Chenwandun, It's probably a bug fix that unveils the link errors. tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: f5cfd96ad87b58bf3b5dfa5365f8beb8bac15a38 commit: 68acde7629d75d460760a3124c52f358eecc6d26 [1865/1875] drm/dp_mst: fix gcc compile error config:

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

On 2019/11/6 上午1:58, Alex Williamson wrote: On Tue, 5 Nov 2019 17:32:34 +0800 Jason Wang wrote: 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

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

On 2019/11/6 上午1:47, Alex Williamson wrote: +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev" +#define VIRTIO_MDEV_F_VERSION_1 0x1 This entire concept of VIRTIO_MDEV_F_VERSION_1 is gone now, right? Let's remove it here and below. Thanks, Alex Yes, will fix. Thanks

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

On 2019/11/6 上午2:28, Cornelia Huck wrote: On Tue, 5 Nov 2019 10:44:18 -0700 Alex Williamson wrote: 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

[Intel-gfx] ✓ Fi.CI.IGT: 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_full -> Patchwork_15129_full

Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present

On Tue, 5 Nov 2019 at 07:00, Manasi Navare wrote: > > On Mon, Nov 04, 2019 at 07:48:26PM +1000, David Airlie wrote: > > On Mon, Nov 4, 2019 at 7:18 PM Daniel Vetter wrote: > > > > > > On Thu, Oct 31, 2019 at 02:48:39PM -0700, Manasi Navare wrote: > > > > In case of tiled displays, if we hotplug

Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present

On Fri, 1 Nov 2019 at 07:46, Manasi Navare wrote: > > In case of tiled displays, if we hotplug just one connector, > fbcon currently just selects the preferred mode and if it is > tiled mode then that becomes a problem if rest of the tiles are > not present. > So in the fbdev driver on hotplug

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use rcu_dereference for rcu protected pointer

On Wed, Nov 06, 2019 at 12:36:47AM +, Chris Wilson wrote: Quoting Niranjana Vishwanathapura (2019-11-06 00:02:05) 'ctx\->vm' is rcu protected, so use rcu_dereference inside read side critical section. It fixes a sparse warning. Cc: Chris P Wilson Signed-off-by: Niranjana Vishwanathapura

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/psr: Add bits per pixel limitation

== Series Details == Series: series starting with [1/5] drm/i915/psr: Add bits per pixel limitation URL : https://patchwork.freedesktop.org/series/69025/ State : success == Summary == CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15142

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Check for ips_mchdev being NULL

On Wed, Nov 06, 2019 at 12:37:14AM +, Chris Wilson wrote: Quoting Niranjana Vishwanathapura (2019-11-06 00:02:04) Guard against uninitalized (NULL) ips_mchdev before dereferencing. Because? I am seeing some exported functions like i915_read_mch_val() that try to dereference ips_mchdev

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wrap vm_mmap() around GEM objects

== Series Details == Series: drm/i915/selftests: Wrap vm_mmap() around GEM objects URL : https://patchwork.freedesktop.org/series/69024/ State : success == Summary == CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15141 Summary ---

[Intel-gfx] [PATCH 2/5] drm/i915/psr: Refactor psr short pulse handler

eDP spec states that when sink enconters a problem that prevents it to keep PSR running it should set PSR status to internal error and set the reason why it happen to PSR_ERROR_STATUS but it is not how it was implemented. But also I don't want to change this behavior, who knows if there is a panel

[Intel-gfx] [PATCH 4/5] drm/i915/psr: Check if sink PSR capability changed

eDP specification states that sink can have its PSR capability changed, I have never found any panel doing that but lets add that for completeness. For now it is not reading back the PSR capabilities and if possible re-enabling PSR, this will be added if a panel is found using this feature. Cc:

[Intel-gfx] [PATCH 5/5] drm/i915/vbt: Parse power conservation features block

Since VBT 228 is from this block that PSR and other power saving features configuration should be read from. Cc: Gwan-gyeong Mun Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_bios.c | 19 +++- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29

[Intel-gfx] [PATCH 1/5] drm/i915/psr: Add bits per pixel limitation

PSR2 HW only support a limited number of bits per pixel, if mode has more than supported PSR2 should not be enabled. BSpec: 50422 BSpec: 7713 Cc: Gwan-gyeong Mun Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 11 ++- 1 file changed, 10

[Intel-gfx] [PATCH 3/5] drm/i915/psr: Enable ALPM lock timeout error interruption

When this error happens sink link is not stable after the required FW_EXIT_LATENCY period so it will miss the selective update. As the other PSR errors, for now we are not trying to recover from it. Cc: Gwan-gyeong Mun Signed-off-by: José Roberto de Souza ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Wrap vm_mmap() around GEM objects

== Series Details == Series: drm/i915/selftests: Wrap vm_mmap() around GEM objects URL : https://patchwork.freedesktop.org/series/69024/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7da6b96fcdd4 drm/i915/selftests: Wrap vm_mmap() around GEM objects -:109:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Add second TGL PCH ID

== Series Details == Series: drm/i915/tgl: Add second TGL PCH ID URL : https://patchwork.freedesktop.org/series/69023/ State : success == Summary == CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15140 Summary --- **SUCCESS**

[Intel-gfx] [PATCH] drm/i915/selftests: Wrap vm_mmap() around GEM objects

Provide a utility function to create a vma corresponding to an mmap() of our device. Signed-off-by: Chris Wilson Cc: Abdiel Janulgue --- drivers/gpu/drm/drm_file.c| 2 + drivers/gpu/drm/i915/Makefile | 2 + .../drm/i915/gem/selftests/i915_gem_mman.c|

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add second TGL PCH ID

On Tue, 2019-11-05 at 16:55 -0800, James Ausmus wrote: > Another TGP ID has shown up, so let's add it to avoid South Display > breakage on systems that have this ID. > Reviewed-by: José Roberto de Souza > Cc: Lucas De Marchi > Cc: José Roberto de Souza > Signed-off-by: James Ausmus > --- >

[Intel-gfx] [PATCH] drm/i915/tgl: Add second TGL PCH ID

Another TGP ID has shown up, so let's add it to avoid South Display breakage on systems that have this ID. Cc: Lucas De Marchi Cc: José Roberto de Souza Signed-off-by: James Ausmus --- drivers/gpu/drm/i915/intel_pch.c | 1 + drivers/gpu/drm/i915/intel_pch.h | 1 + 2 files changed, 2

[Intel-gfx] ✓ Fi.CI.IGT: 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_full -> Patchwork_15128_full

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove unwanted rcu_read_lock/unlock

Quoting Niranjana Vishwanathapura (2019-11-06 00:02:03) > We don't need rcu read side critical section to call pid_nr(), > remove it. > > Cc: Chris P Wilson > Signed-off-by: Niranjana Vishwanathapura > --- > drivers/gpu/drm/i915/i915_gpu_error.c | 3 --- > 1 file changed, 3 deletions(-) > >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Check for ips_mchdev being NULL

Quoting Niranjana Vishwanathapura (2019-11-06 00:02:04) > Guard against uninitalized (NULL) ips_mchdev before > dereferencing. Because? -Chris - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office:

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use rcu_dereference for rcu protected pointer

Quoting Niranjana Vishwanathapura (2019-11-06 00:02:05) > 'ctx\->vm' is rcu protected, so use rcu_dereference inside > read side critical section. It fixes a sparse warning. > > Cc: Chris P Wilson > Signed-off-by: Niranjana Vishwanathapura > --- > drivers/gpu/drm/i915/gem/i915_gem_context.c |

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Properly capture & release GuC interrupts on Gen11+

== Series Details == Series: drm/i915/guc: Properly capture & release GuC interrupts on Gen11+ URL : https://patchwork.freedesktop.org/series/69019/ State : success == Summary == CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15139

Re: [Intel-gfx] [RFC 1/6] drm/dp: get/set phy compliance pattern.

On Thu, Oct 03, 2019 at 08:36:48PM +0530, Animesh Manna wrote: > During phy complaince auto test mode source need to read > requested test pattern from sink through DPCD. After processing > the request source need to set the pattern. So set/get method > added in drm layer as it is DP protocol. >

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Don't select BROKEN (rev2)

== Series Details == Series: drm/i915: Don't select BROKEN (rev2) URL : https://patchwork.freedesktop.org/series/69013/ State : failure == Summary == Applying: drm/i915: Don't select BROKEN error: patch failed: init/Kconfig:75 error: init/Kconfig: patch does not apply error: Did you hand edit

[Intel-gfx] [PATCH v2] drm/i915/guc: Properly capture & release GuC interrupts on Gen11+

With the new interrupt re-partitioning in Gen11, GuC controls by itself the interrupts it receives, so steering bits and registers have been defeatured. Being this the case, when the GuC is in control of submissions we won't know what to do with the ctx switch interrupt in the driver, so disable

Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN

Quoting Daniel Vetter (2019-11-05 20:58:25) > On Tue, Nov 5, 2019 at 9:38 PM Chris Wilson wrote: > > > > Quoting Daniel Vetter (2019-11-05 19:38:29) > > > It's broken. > > > > > > Reported-by: Stephen Rothwell > > > References: > > >

Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN

Quoting Daniel Vetter (2019-11-05 20:58:25) > On Tue, Nov 5, 2019 at 9:38 PM Chris Wilson wrote: > > > > Quoting Daniel Vetter (2019-11-05 19:38:29) > > > It's broken. > > > > > > Reported-by: Stephen Rothwell > > > References: > > >

Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN

On Tue, Nov 5, 2019 at 9:38 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2019-11-05 19:38:29) > > It's broken. > > > > Reported-by: Stephen Rothwell > > References: > > https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html > > Signed-off-by: Daniel Vetter > > --- > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't select BROKEN

== Series Details == Series: drm/i915: Don't select BROKEN URL : https://patchwork.freedesktop.org/series/69013/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15137 Summary --- **SUCCESS** No

Re: [Intel-gfx] [PATCH] drm/i915: Preload LUTs if the hw isn't currently using them

Hi, On 30-10-2019 20:08, Ville Syrjala wrote: From: Ville Syrjälä The LUTs are single buffered so in order to program them without tearing we'd have to do it during vblank (actually to be 100% effective it has to happen between start of vblank and frame start). We have no proper mechanism for

Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN

On Tue, Nov 5, 2019 at 9:34 PM Chris Wilson wrote: > Quoting Daniel Vetter (2019-11-05 19:38:29) > > It's broken. > > So is the code that depends on it. Which is the entire point. > > Don't select it then. See the mail from Stephen, it breaks autobuilders. So we need to do this explicitly, i.e.

Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN

Quoting Daniel Vetter (2019-11-05 19:38:29) > It's broken. > > Reported-by: Stephen Rothwell > References: > https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html > Signed-off-by: Daniel Vetter > --- > Note: Probably best to apply this directly onto drm-next to avoid >

Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN

Quoting Daniel Vetter (2019-11-05 19:38:29) > It's broken. So is the code that depends on it. Which is the entire point. Don't select it then. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Don't select BROKEN

== Series Details == Series: drm/i915: Don't select BROKEN URL : https://patchwork.freedesktop.org/series/69013/ State : warning == Summary == $ dim checkpatch origin/drm-tip 49373d3c2935 drm/i915: Don't select BROKEN -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description

[Intel-gfx] ✓ Fi.CI.IGT: 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_full -> Patchwork_15127_full Summary

[Intel-gfx] [PATCH] drm/i915: Don't select BROKEN

It's broken. Reported-by: Stephen Rothwell References: https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html Signed-off-by: Daniel Vetter --- Note: Probably best to apply this directly onto drm-next to avoid having drm-next dropped from linux-next until the next pull

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == CI Bug Log - changes from CI_DRM_7260_full -> Patchwork_15125_full

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

On Tue, Nov 5, 2019 at 7:38 PM Tang, CQ wrote: > > > > > -Original Message- > > From: Daniel Vetter > > Sent: Tuesday, November 5, 2019 2:02 AM > > To: Intel Graphics Development > > Cc: Daniel Vetter ; Auld, Matthew > > ; Chris Wilson ; Tang, > > CQ ; Ursulin, Tvrtko ; Joonas > >

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

> -Original Message- > From: Daniel Vetter > Sent: Tuesday, November 5, 2019 2:02 AM > To: Intel Graphics Development > Cc: Daniel Vetter ; Auld, Matthew > ; Chris Wilson ; Tang, > CQ ; Ursulin, Tvrtko ; Joonas > Lahtinen ; Vetter, Daniel > > Subject: [PATCH] drm/i915: Switch

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

On Tue, 5 Nov 2019 17:32:40 +0800 Jason Wang wrote: > 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

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

On Tue, 5 Nov 2019 17:32:39 +0800 Jason Wang wrote: > 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

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

On Tue, 5 Nov 2019 10:44:18 -0700 Alex Williamson wrote: > 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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Frob the correct crtc state in intel_crtc_disable_noatomic()

== Series Details == Series: series starting with [1/2] drm/i915: Frob the correct crtc state in intel_crtc_disable_noatomic() URL : https://patchwork.freedesktop.org/series/69009/ State : success == Summary == CI Bug Log - changes from CI_DRM_7262 -> Patchwork_15136

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

On Tue, 5 Nov 2019 17:32:34 +0800 Jason Wang wrote: > 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

[Intel-gfx] [PATCH v2 2/3] drm/i915: Lookup and attach ACPI device node for connectors

Lookup and attach ACPI nodes for intel connectors. The lookup is done in compliance with ACPI Spec 6.3 https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf (Ref: Pages 1119 - 1123). This can be useful for any connector specific platform properties. (This will be used for

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

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 --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 28 -

[Intel-gfx] [PATCH v2 1/3] drm/i915: Move the code to populate ACPI device ID into intel_acpi

Move the code that populates the ACPI device ID for devices, into more appripriate intel_acpi.c. This is done in preparation for more users of this code (in next patch). Signed-off-by: Rajat Jain Change-Id: Ifb3bd458734985c2a78ba682e6f0a2e63e0626ca --- v2: v1 doesn't exist. Found existing code

[Intel-gfx] [PATCH v2 3/3] drm/i915: Add support for integrated privacy screens

Certain laptops now come with panels that have integrated privacy screens on them. This patch adds support for such panels by adding a privacy-screen property to the intel_connector for the panel, that the userspace can then use to control and check the status. Identifying the presence of privacy

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 +

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

[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**

[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.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] ✗ 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] [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

[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

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 +

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

[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 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

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

[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

[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

[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-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

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

[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

[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

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,

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:

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:

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: >

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.

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

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.

[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.

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.,

[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:

  1   2   >