Quoting Joonas Lahtinen (2019-11-05 09:14:20)
> 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
== Series Details ==
Series: drm/i915: switch intel_ddi_init() to intel types (rev2)
URL : https://patchwork.freedesktop.org/series/69031/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15145
Summary
--
Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
drivers/gpu/drm/drm_file.c| 2 +
drivers/gpu/drm
On Tue, Nov 05, 2019 at 01:05:20PM +, Matthew Auld wrote:
> 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
> > > > w
== Series Details ==
Series: drm/i915/userptr: Try to acquire the page lock around set_page_dirty()
URL : https://patchwork.freedesktop.org/series/69037/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dda6c9506312 drm/i915/userptr: Try to acquire the page lock around
set_page_d
Quoting Niranjan Vishwanathapura (2019-11-06 02:14:45)
> 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 export
On 2019.11.06 15:31:07 +0800, Pan Bian wrote:
> The reference count of obj will be decremented twice if error occurs
> in dma_buf_fd(). Additionally, attempting to read the reference count of
> obj after dropping reference may lead to a use after free bug. Here, we
> drop obj's reference until it i
Quoting Niranjan Vishwanathapura (2019-11-06 02:16:42)
> 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 warnin
== Series Details ==
Series: drm/i915/userptr: Try to acquire the page lock around set_page_dirty()
URL : https://patchwork.freedesktop.org/series/69037/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15146
As we read the ctx->vm unlocked before cloning/exporting, we should
validate our reference is correct before returning it. We already do for
clone_vm() but were not so strict around get_ppgtt().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 80 +++-
== Series Details ==
Series: drm/i915/selftests: Wrap vm_mmap() around GEM objects (rev2)
URL : https://patchwork.freedesktop.org/series/69024/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d9f64b19e4f3 drm/i915/selftests: Wrap vm_mmap() around GEM objects
-:68: CHECK:MACRO_ARG
== 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_full -> Patchwork_15133_full
Summary
-
== Series Details ==
Series: drm/i915/selftests: Wrap vm_mmap() around GEM objects (rev2)
URL : https://patchwork.freedesktop.org/series/69024/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7264 -> Patchwork_15147
Summary
-
Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.
Signed-off-by: Chris Wils
Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/ge
Currently the drm_prime mmap fallback uses a mock struct file to provide
the file pointer into the backend mmap routine. Now that we can create
fully fledged anonymous struct file around the drm device, put it to
use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_prime.c | 26 -
On Wed, Nov 06, 2019 at 10:07:14AM +, Chris Wilson wrote:
> Sometimes we need to create a struct file to wrap a drm_device, as it
> the user were to have opened /dev/dri/card0 but to do so anonymously
> (i.e. for internal use). Provide a utility method to create a struct
> file with the drm_dev
On Wed, Nov 06, 2019 at 10:07:16AM +, Chris Wilson wrote:
> Currently the drm_prime mmap fallback uses a mock struct file to provide
> the file pointer into the backend mmap routine. Now that we can create
> fully fledged anonymous struct file around the drm device, put it to
> use.
>
> Signed
Quoting Chris Wilson (2019-11-05 23:13:36)
> 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:
> >
On Mon, Nov 04, 2019 at 06:38:01PM +0100, Daniel Vetter wrote:
> With nouveau fixed all ttm-using drives have the correct nesting of
> mmap_sem vs dma_resv, and we can just lock the buffer.
>
> Assuming I didn't screw up anything with my audit of course.
>
> v2:
> - Dont forget wu_mutex (Christia
Quoting Daniel Vetter (2019-11-06 10:19:50)
> On Wed, Nov 06, 2019 at 10:07:14AM +, Chris Wilson wrote:
> > Sometimes we need to create a struct file to wrap a drm_device, as it
> > the user were to have opened /dev/dri/card0 but to do so anonymously
> > (i.e. for internal use). Provide a utili
Quoting Chris Wilson (2019-11-06 10:26:48)
> Quoting Daniel Vetter (2019-11-06 10:19:50)
> > On Wed, Nov 06, 2019 at 10:07:14AM +, Chris Wilson wrote:
> > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > > the user were to have opened /dev/dri/card0 but to do so anony
Quoting Daniel Vetter (2019-11-06 10:21:57)
> On Wed, Nov 06, 2019 at 10:07:16AM +, Chris Wilson wrote:
> > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > the file pointer into the backend mmap routine. Now that we can create
> > fully fledged anonymous struct file
== 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_full -> Patchwork_15134_full
Summar
On Wed, 6 Nov 2019 15:05:45 +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
On Wed, 6 Nov 2019 15:05:46 +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
> ---
> MAINTAINERS | 1 +
> drivers/vfio/mdev/mdev_core.c| 21 +
>
On Wed, 6 Nov 2019 15:05:47 +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 bu
Quoting Arkadiusz Hiler (2019-11-06 08:30:37)
> On Tue, Nov 05, 2019 at 01:05:20PM +, Matthew Auld wrote:
> > 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:
> > >
== Series Details ==
Series: drm/i915/gem: Safely acquire the ctx->vm when copying
URL : https://patchwork.freedesktop.org/series/69044/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7266 -> Patchwork_15148
Summary
---
== Series Details ==
Series: series starting with [1/3] drm: Expose a method for creating anonymous
struct file around drm_minor
URL : https://patchwork.freedesktop.org/series/69048/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
115c40d7fea3 drm: Expose a method for creating a
== 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_full -> Patchwork_15136_full
===
Hi,
On Wed, 6 Nov 2019 at 02:47, Dave Airlie wrote:
> Otherwise I think this seems fine, though it does beg the question in
> my mind of what happens if I get 2 8K monitors, and plug the first
> tile of one in, and the second tile of the other in.
Honestly in that case I think 'you get to litera
On 2019-11-05 at 11:47:16 +, Chris Wilson wrote:
> 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
== Series Details ==
Series: series starting with [1/3] drm: Expose a method for creating anonymous
struct file around drm_minor
URL : https://patchwork.freedesktop.org/series/69048/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7266 -> Patchwork_15149
===
Op 05-11-2019 om 18:14 schreef Ville Syrjala:
> 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 cle
Quoting Chris Wilson (2019-11-05 16:53:05)
> 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
On 06/11/2019 11:42, Ramalingam C wrote:
On 2019-11-05 at 11:47:16 +, Chris Wilson wrote:
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:
We should not be unconditionally calling release_fake_lmem_bar.
Signed-off-by: Matthew Auld
Cc: Lucas De Marchi
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_region_lmem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/dr
Quoting Matthew Auld (2019-11-06 12:31:35)
> We should not be unconditionally calling release_fake_lmem_bar.
>
> Signed-off-by: Matthew Auld
> Cc: Lucas De Marchi
> Cc: Chris Wilson
No other side effects in the function, so seeing is believing.
Reviewed-by: Chris Wilson
-Chris
___
Quoting Chris Wilson (2019-11-05 16:59:31)
> 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.
>
> Sign
Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/ge
Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.
Signed-off-by: Chris Wils
Whenever, we unbind (or change fence registers) on an object, we must
revoke any and all mmap_gtt using the previous bindings. Those user PTEs
point at the GGTT which know points into a new object, the wrong object.
Ergo, those PTEs must be cleared so that any user access provokes a new
page fault.
As drm now exports a method to create an anonymous struct file around a
drm_device for internal use, make use of it to avoid our horrible hacks.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 12 ++---
.../i9
On Wed, Nov 6, 2019 at 11:45 AM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-11-06 10:21:57)
> > On Wed, Nov 06, 2019 at 10:07:16AM +, Chris Wilson wrote:
> > > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > > the file pointer into the backend mmap routine.
On Wed, Nov 6, 2019 at 11:43 AM Chris Wilson wrote:
>
> Quoting Chris Wilson (2019-11-06 10:26:48)
> > Quoting Daniel Vetter (2019-11-06 10:19:50)
> > > On Wed, Nov 06, 2019 at 10:07:14AM +, Chris Wilson wrote:
> > > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > >
On 2019/11/6 下午7:00, Cornelia Huck wrote:
On Wed, 6 Nov 2019 15:05:47 +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 driv
Quoting Daniel Vetter (2019-11-06 13:06:26)
> On Wed, Nov 6, 2019 at 11:45 AM Chris Wilson wrote:
> >
> > Quoting Daniel Vetter (2019-11-06 10:21:57)
> > > On Wed, Nov 06, 2019 at 10:07:16AM +, Chris Wilson wrote:
> > > > Currently the drm_prime mmap fallback uses a mock struct file to provide
On Tue, Nov 05, 2019 at 11:17:17PM -0800, Lucas De Marchi wrote:
> 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
lgtm
Reviewed-by:
Mika spotted that only using cancel_delayed_work() could mean that we
attempted to clear the heartbeat.systole while the worker was still
running. Rectify the situation by only touching the systole from outside
the worker if we suceeded in cancelling the worker before it could run.
The worker is ex
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
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.
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 insertions
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
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Wang
---
MAINTAINERS | 1 +
drivers/vfio/mdev/mdev_core.c| 21 +
drivers/vfio/mdev/mdev_private.h | 2 +
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
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
On Wed, Nov 06, 2019 at 12:53:45PM +0100, Maarten Lankhorst wrote:
> Op 05-11-2019 om 18:14 schreef Ville Syrjala:
> > 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
s/not/now/ and pushed to dinq. Th
Hello Chris Wilson,
The patch a4e7ccdac38e: "drm/i915: Move context management under GEM"
from Oct 4, 2019, leads to the following static checker warning:
drivers/gpu/drm/i915/gem/i915_gem_context.c:980 set_ppgtt()
warn: 'ctx->mutex' both locked and unlocked.
drivers/gpu/drm/i915
== Series Details ==
Series: drm/i915/lmem: fixup fake lmem teardown
URL : https://patchwork.freedesktop.org/series/69057/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7267 -> Patchwork_15150
Summary
---
**SUCCESS**
Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.
v2: Restrict usage to sel
Whenever, we unbind (or change fence registers) on an object, we must
revoke any and all mmap_gtt using the previous bindings. Those user PTEs
point at the GGTT which know points into a new object, the wrong object.
Ergo, those PTEs must be cleared so that any user access provokes a new
page fault.
As drm now exports a method to create an anonymous struct file around a
drm_device for internal use, make use of it to avoid our horrible hacks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug| 2 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../drm/i9
On Wed, Nov 06, 2019 at 11:17:29AM +, Chris Wilson wrote:
> Quoting Arkadiusz Hiler (2019-11-06 08:30:37)
> > On Tue, Nov 05, 2019 at 01:05:20PM +, Matthew Auld wrote:
> > > On Thu, 31 Oct 2019 at 20:40, Chris Wilson
> > > wrote:
> > > >
> > > > Quoting Arkadiusz Hiler (2019-10-31 12:40:3
Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/ge
On Wed, 6 Nov 2019 21:35:25 +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
On Wed, Nov 06, 2019 at 01:57:36PM +, Chris Wilson wrote:
> Sometimes we need to create a struct file to wrap a drm_device, as it
> the user were to have opened /dev/dri/card0 but to do so anonymously
> (i.e. for internal use). Provide a utility method to create a struct
> file with the drm_dev
Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/ge
Whenever, we unbind (or change fence registers) on an object, we must
revoke any and all mmap_gtt using the previous bindings. Those user PTEs
point at the GGTT which know points into a new object, the wrong object.
Ergo, those PTEs must be cleared so that any user access provokes a new
page fault.
Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.
v2: Restrict usage to sel
Currently, we only export symbols for drm-selftests which are either
compiled as modules or into the main drm builtin. However, if we want to
export symbols from drm.ko for the drivers' selftests, we require a
means of controlling that export separately. So we add a new Kconfig to
determine whether
Like v2, but with more Kconfig hackery so that i915.ko can request
builtin-drm (and drm-selftests) export the symbols it requires for its
selftests.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/
As drm now exports a method to create an anonymous struct file around a
drm_device for internal use, make use of it to avoid our horrible hacks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug| 2 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../drm/i9
Chris Wilson writes:
> Mika spotted that only using cancel_delayed_work() could mean that we
> attempted to clear the heartbeat.systole while the worker was still
> running. Rectify the situation by only touching the systole from outside
> the worker if we suceeded in cancelling the worker before
When inside the lock, remember to unlock even if you want to leave
early.
Reported-by: Dan Carpenter
Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
1 file changed, 1 inse
Quoting Dan Carpenter (2019-11-06 13:48:14)
> Hello Chris Wilson,
>
> The patch a4e7ccdac38e: "drm/i915: Move context management under GEM"
> from Oct 4, 2019, leads to the following static checker warning:
>
> drivers/gpu/drm/i915/gem/i915_gem_context.c:980 set_ppgtt()
> warn: 'c
== Series Details ==
Series: series starting with [1/4] drm: Expose a method for creating anonymous
struct file around drm_minor
URL : https://patchwork.freedesktop.org/series/69059/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d7aa94bb3f9e drm: Expose a method for creating a
On 06/11/2019 14:41, Chris Wilson wrote:
When inside the lock, remember to unlock even if you want to leave
early.
Reported-by: Dan Carpenter
Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915
For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as our
primary means of
If the caller wants to overwrite the currently tracked fence, with
itself, as far as the tracking is concerned it is a no-op, so simply
allow it.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
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 context. i915_gem_evict_for_node() is
the only use
On Mon, Aug 26, 2019 at 3:27 PM Andrzej Pietrasiewicz
wrote:
>
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Sean Paul
> ---
> drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +++
== Series Details ==
Series: series starting with [1/4] drm: Expose a method for creating anonymous
struct file around drm_minor
URL : https://patchwork.freedesktop.org/series/69059/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7270 -> Patchwork_15151
===
When LMEM is supported, dumb buffer preferred to be created from LMEM.
v2:
Parameters are reshuffled. [Chris]
v3:
s/region_id/mem_type
v4:
use the i915_gem_object_create_region [chris]
Signed-off-by: Ramalingam C
cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 15 ---
Lookup function to retrieve the pointer to a memory region of
a mem_type.
Signed-off-by: Ramalingam C
cc: Matthew Auld
---
drivers/gpu/drm/i915/intel_memory_region.c | 12
drivers/gpu/drm/i915/intel_memory_region.h | 3 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/g
> -Original Message-
> From: Intel-gfx On Behalf Of
> Ramalingam C
> Sent: Wednesday, November 6, 2019 8:08 AM
> To: intel-gfx ; Chris Wilson wilson.co.uk>
> Cc: Auld, Matthew
> Subject: [Intel-gfx] [PATCH v4 1/2] drm/i915: lookup for mem_region of a
> mem_type
>
> Lookup function to
On 2019-11-06 at 21:45:44 +0530, Tang, CQ wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Ramalingam C
> > Sent: Wednesday, November 6, 2019 8:08 AM
> > To: intel-gfx ; Chris Wilson > wilson.co.uk>
> > Cc: Auld, Matthew
> > Subject: [Intel-gfx] [PATCH v4 1/2] drm
== Series Details ==
Series: drm/i915/gt: Only drop heartbeat.systole if the sole owner
URL : https://patchwork.freedesktop.org/series/69060/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7270 -> Patchwork_15152
Summary
---
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/69063/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2e15c56da9d0 mdev: class id support
aa81f6ab1bbe modpost: add support for mdev class id
94e6d607158c md
Using the array is getting clumsy. Make things a bit more dynamic.
In code, start migrating towards calling the new struct child_device
"child" and the VBT-originating struct child_device_config "config".
Remove early returns on not having child devices when the end result
after "iterating" the e
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/69063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7270 -> Patchwork_15153
Summary
---
**SUC
== Series Details ==
Series: series starting with [v2,1/4] drm: Expose a method for creating
anonymous struct file around drm_minor
URL : https://patchwork.freedesktop.org/series/69064/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3a38f9e9be4b drm: Expose a method for creatin
== Series Details ==
Series: series starting with [v2,1/4] drm: Expose a method for creating
anonymous struct file around drm_minor
URL : https://patchwork.freedesktop.org/series/69064/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7270 -> Patchwork_15154
From: Ville Syrjälä
Make sure we have a crtc before probing its primary plane's
max stride. Initially I thought we can't get this far without
crtcs, but looks like we can via the dumb_create ioctl.
Not sure if we shouldn't disable dumb buffer support entirely
when we have no crtcs, but that woul
From: Niranjana Vishwanathapura
We don't need rcu read side critical section to call pid_nr(),
remove it.
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 3 ---
1 file changed, 3 deletions(-)
diff --g
The reference count of obj will be decremented twice if error occurs
in dma_buf_fd(). Additionally, attempting to read the reference count of
obj after dropping reference may lead to a use after free bug. Here, we
drop obj's reference until it is not used.
Signed-off-by: Pan Bian
---
drivers/gpu
Quoting Ville Syrjala (2019-11-06 17:23:49)
> From: Ville Syrjälä
>
> Make sure we have a crtc before probing its primary plane's
> max stride. Initially I thought we can't get this far without
> crtcs, but looks like we can via the dumb_create ioctl.
>
> Not sure if we shouldn't disable dumb bu
From: Don Hiatt
On some platforms (e.g. KBL) that do not support GuC submission, but
the user enabled the GuC communication (e.g for HuC authentication)
calling the GuC EXIT_S_STATE action results in lose of ability to
enter RC6. We can remove the GuC suspend/resume entirely as we do
not need to
From: Don Hiatt
Add intel_guc_submission_is_enabled() function to determine if
GuC submission is active. Based on code by Michal Wajdeczko.
Signed-off-by: Don Hiatt
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 1 +
drivers/
== Series Details ==
Series: series starting with [v3,1/5] drm: Move EXPORT_SYMBOL_FOR_TESTS_ONLY
under a separate Kconfig
URL : https://patchwork.freedesktop.org/series/69068/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7737267b3477 drm: Move EXPORT_SYMBOL_FOR_TESTS_ONLY un
1 - 100 of 155 matches
Mail list logo
