== Series Details ==
Series: series starting with [1/3] drm/i915: Use render class for MI_SET_CONTEXT
URL : https://patchwork.freedesktop.org/series/65143/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6697_full -> Patchwork_14000_full
Hello Christian,
On Sun, 11 Aug 2019 at 14:48, Chris Wilson wrote:
> Quoting Christian König (2019-08-11 09:56:01)
> > Be more consistent with the naming of the other DMA-buf objects.
>
> From the tip of my fingers, \o/
>
> > Signed-off-by: Christian König
>
Thanks for doing this!
Acked-by:
== Series Details ==
Series: drm/i915: Disregard drm_mode_config.fb_base (rev2)
URL : https://patchwork.freedesktop.org/series/65144/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6697_full -> Patchwork_14001_full
Summary
Quoting Daniele Ceraolo Spurio (2019-08-14 01:21:45)
> The engine->guc_id is GuC FW defined and it is not guaranteed to be
> below I915_NUM_ENGINES, so we shouldn't use it with the i915-defined
> client->submissions, as we might overflow.
> Instead of fixing it, just get rid of
Quoting Chris Wilson (2019-08-14 09:00:18)
> Quoting Daniele Ceraolo Spurio (2019-08-14 01:21:45)
> > The engine->guc_id is GuC FW defined and it is not guaranteed to be
> > below I915_NUM_ENGINES, so we shouldn't use it with the i915-defined
> > client->submissions, as we might overflow.
> >
Quoting Dong Yang (2019-08-14 03:44:48)
> From: "Yang, Dong"
>
> Broxton steppings starting from GT E0 have fixed the bug, remove
> WA since stepping GT E0.
In i915 patches, we keep a changelog of what was changed compared to the
previous iteration (see git log drivers/gpu/drm/i915 for example)
== Series Details ==
Series: drm/ttm: make ttm bo a gem bo subclass (rev3)
URL : https://patchwork.freedesktop.org/series/64701/
State : failure
== Summary ==
Applying: drm/ttm: add gem base object
Using index info to reconstruct a base tree...
M include/drm/ttm/ttm_bo_api.h
Falling
Quoting Srivatsa, Anusha (2019-08-14 00:41:15)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Tuesday, August 13, 2019 11:21 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Daniel Vetter
> > ; Maarten Lankhorst
> > ; Srivatsa, Anusha
> >
> > Subject:
== Series Details ==
Series: series starting with [v3] drm/i915: Push the wakeref->count deferral to
the backend (rev3)
URL : https://patchwork.freedesktop.org/series/65129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6697_full -> Patchwork_14002_full
From: "Yang, Dong"
Broxton steppings starting from GT E0 have fixed the bug, remove
WA since stepping GT E0.
v2: add comment in code, by:
Joonas Lahtinen
Signed-off-by: Yang, Dong
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Am 14.08.19 um 04:54 schrieb Stephen Rothwell:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
>drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>drivers/gpu/drm/i915/i915_vma.c
>drivers/gpu/drm/i915/i915_gem_batch_pool.c
>
Quoting Yang, Dong (2019-08-14 03:43:44)
> comments updated, please review again.
You seem to have missed the comments to the code itself.
Regards, Joonas
>
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, August 13, 2019 8:47 PM
>
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev2)
URL : https://patchwork.freedesktop.org/series/65160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6701 -> Patchwork_14009
Summary
---
Quoting dong.y...@intel.com (2019-08-14 10:54:05)
> From: "Yang, Dong"
>
> Broxton steppings starting from GT E0 have fixed the bug, remove
> WA since stepping GT E0.
>
> v2: add comment in code, by:
> Joonas Lahtinen
I didn't suggest any comments, I suggested to change the code.
>
>
Hi,
Sorry for the delay, I was on vacation. The machine fi-skl-6770hq was
not marked as having an LSPCON. This is now done, and this means that
this issue should be covered by ab existing bug.
I queued another run, and we'll see if it gives us a green (new tests
don't need to pass on all
== Series Details ==
Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out
of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65169/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c067af237d77 drm/i915/execlists: Lift process_csb()
== Series Details ==
Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out
of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65169/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Lift
Quoting dong.y...@intel.com (2019-08-14 08:54:05)
> From: "Yang, Dong"
>
> Broxton steppings starting from GT E0 have fixed the bug, remove
> WA since stepping GT E0.
If you have a supply of these, could you arrange for one to be put into
CI. We have no coverage of bxt-iommu to assess your
Quoting Chris Wilson (2019-08-13 23:09:05)
> We use the request pointer inside the i915_active_node as the indicator
> of the barrier's status; we mark it as used during
> i915_request_add_active_barriers(), and search for an available barrier
> in reuse_idle_barrier(). That check must be
Convert the list manipulation of active to use spinlocks so that we can
perform the updates from underneath a quick interrupt callback.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c| 10 --
As every i915_active_request should be serialised by a dedicated lock,
i915_active consists of a tree of locks; one for each node. Markup up
the i915_active_request with what lock is supposed to be guarding it so
that we can verify that the serialised updated are indeed serialised.
Signed-off-by:
We use timeline->mutex to protect modifications to
context->active_count, and the associated enable/disable callbacks.
Due to complications with engine-pm barrier there is a path where we used
a "superlock" to provide serialised protect and so could not
unconditionally assert with lockdep that it
On Sat, Aug 10, 2019 at 12:02:19AM +0530, Anshuman Gupta wrote:
> We need to have a S/W flag based upon which driver can switch to DC3CO.
> If it is only edp display connected and it has psr2 capability,
> then set a prefer_dc3co flag to true, which will be used to
> switch to dc3co as well as to
Check that we can run a second request even if an equal priority spinner
is hogging the engine.
Extend the testing with some undying timeslice behaviour that requires
hangcheck to intervene.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
This should enable us to reload driver with
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
Signed-off-by: Michał Winiarski
Signed-off-by: Michal Wajdeczko
== Series Details ==
Series: drm/i915: Include engine->mmio_base in the debug duump
URL : https://patchwork.freedesktop.org/series/65157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6699_full -> Patchwork_14004_full
== Series Details ==
Series: drm/ttm: make ttm bo a gem bo subclass (rev4)
URL : https://patchwork.freedesktop.org/series/64701/
State : failure
== Summary ==
Applying: drm/ttm: add gem base object
Using index info to reconstruct a base tree...
M include/drm/ttm/ttm_bo_api.h
Falling
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Many places in the kernel have a flow where userspace will create some
object and that object will need to connect to the subsystem's
mmu_notifier subscription for the duration of its lifetime.
In this case the subsystem is
== Series Details ==
Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out
of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6706_full -> Patchwork_14011_full
== Series Details ==
Series: hmm & mmu_notifier debug/lockdep annotations
URL : https://patchwork.freedesktop.org/series/65204/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14018
Summary
---
The current SKUs added for Tiger Lake don't have DDIC hooked up, even though it
is supported by the SoC. The current state for these SKUs is problematic
since while enabling the combo phy, PORT_COMP_DW* return 0x,
which is invalid per register definition.
During initialization we check
On 8/14/19 3:14 PM, Andrew Morton wrote:
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This series introduces a new registration flow for mmu_notifiers based on
the idea that the user would like to get a single refcounted piece of
memory for a mm, keyed to its use.
For instance many users of mmu_notifiers use an
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This is a significant simplification, it eliminates all the remaining
'hmm' stuff in mm_struct, eliminates krefing along the critical notifier
paths, and takes away all the ugly locking and abuse of page_table_lock.
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
mmu_notifier_unregister_no_release() and mmu_notifier_call_srcu() no
longer have any users, they have all been converted to use
mmu_notifier_put().
So delete this difficult to use interface.
Signed-off-by: Jason Gunthorpe
On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This
== Series Details ==
Series: drm/i915/tgl: Enabling DSC on Pipe A for TGL
URL : https://patchwork.freedesktop.org/series/65216/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
92b16928782e drm/i915/tgl: Enabling DSC on Pipe A for TGL
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible
On 8/14/19 1:49 PM, Michal Wajdeczko wrote:
On Wed, 14 Aug 2019 22:10:51 +0200, Daniele Ceraolo Spurio
wrote:
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915
From: "Yang, Dong"
Broxton steppings starting from GT E0 have fixed the bug, remove
WA since stepping GT E0.
v2: use BXT_REVID_D_LAST replace BXT_REVID_D0, by:
Joonas Lahtinen
Signed-off-by: Yang, Dong
---
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
1 file changed, 3 insertions(+), 1
On Wed, 14 Aug 2019 22:10:51 +0200, Daniele Ceraolo Spurio
wrote:
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
Establish a userptr and inherit it to many children with fresh mm. Into
each child mm, mmap_gtt the userptr handle so that they are many
different vma in the i_mapping tree pointing back to the userptr. Then
proceed to munmap that and force us to revoke all the mmaps.
Daniel discovered that from
== Series Details ==
Series: drm/i915/tgl: Enabling DSC on Pipe A for TGL
URL : https://patchwork.freedesktop.org/series/65216/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14019
Summary
---
On Wed, 2019-08-14 at 10:02 +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-08-13 18:55:46)
> > Quoting Stuart Summers (2019-08-13 18:41:20)
> > > Use render class instead of RCS0 when printing CCID.
> > >
> > > Signed-off-by: Stuart Summers
> >
> > One day, one day, this will be using
Establish a userptr and inherit it to many children with fresh mm. Into
each child mm, mmap_gtt the userptr handle so that they are many
different vma in the i_mapping tree pointing back to the userptr. Then
proceed to munmap that and force us to revoke all the mmaps.
Daniel discovered that from
On Wed, Aug 14, 2019 at 07:24:15PM +0200, Daniel Vetter wrote:
Hi Sasha,
On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: d3862e44daa7 dma-buf/sw-sync: Fix locking
== Series Details ==
Series: series starting with [1/2] drm/i915/wopcm: Try to use already locked
WOPCM layout
URL : https://patchwork.freedesktop.org/series/65175/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6706_full -> Patchwork_14012_full
== Series Details ==
Series: drm/i915/tgl: disable DDIC
URL : https://patchwork.freedesktop.org/series/65217/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
335a81e24ca8 drm/i915/tgl: disable DDIC
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer
Since __i915_request_queue() may be called from hardirq (timer) context,
we cannot use local_bh_disable/enable at the lower level. As we do want
to kick the tasklet to speed up initial submission or preemption for
normal client submission, lift it to the normal process context
callpath.
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 13
Pass the connector info to the CEC adapter. This makes it possible
to associate the CEC adapter with the corresponding drm connector.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
On Wed, Aug 14, 2019 at 03:58:34PM +, Jason Gunthorpe wrote:
> On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> > Looks good,
> >
> > Reviewed-by: Christoph Hellwig
>
> Dimitri, are you OK with this patch?
>
I think this looks OK.
Reviewed-by: Dimitri Sivanich
This series updates DRM drivers to use new CEC notifier API.
Changes since v6:
Made CEC notifiers' registration and de-registration symmetric
in tda998x and dw-hdmi drivers. Also, accidentally dropped one
patch in v6 (change to drm_dp_cec), brought it back now.
Changes
On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> Looks good,
>
> Reviewed-by: Christoph Hellwig
Dimitri, are you OK with this patch?
Thanks,
Jason
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This simplifies the code to not have so many one line functions and extra
logic. __mmu_notifier_register() simply becomes the entry point to
register the notifier, and the other one calls it under lock.
Also add a lockdep_assert
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary")
made an attempt at doing this, but had to be reverted as calling
the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see
commit 35cfa2b0b491
== Series Details ==
Series: hmm & mmu_notifier debug/lockdep annotations
URL : https://patchwork.freedesktop.org/series/65204/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5a4f96d9f7a6 mm: Check if mmu notifier callbacks are allowed to fail
-:64: WARNING:NO_AUTHOR_SIGN_OFF:
Removing restriction on Pipe A as TigerLake onwards, all the pipes support DSC.
Cc: Manasi Navare
Signed-off-by: Madhumitha Tolakanahalli Pradeep
---
drivers/gpu/drm/i915/display/intel_dp.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git
== Series Details ==
Series: drm/i915/tgl: disable DDIC
URL : https://patchwork.freedesktop.org/series/65217/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14020
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev3)
URL : https://patchwork.freedesktop.org/series/65160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6710 -> Patchwork_14021
Summary
---
== Series Details ==
Series: drm/i915: Move tasklet kicking to __i915_request_queue caller
URL : https://patchwork.freedesktop.org/series/65221/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14022
Summary
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex (rev3)
URL : https://patchwork.freedesktop.org/series/65177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14017
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
Signed-off-by:
On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-08-14 19:24:01)
> > This reverts
> > 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> > dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> > 0e1d8083bddb ("dma-buf: further
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse
Similar to the warning in the mmu notifer, warning if an hmm mirror
callback gets it's blocking vs. nonblocking handling wrong, or if it
fails with anything else than -EAGAIN.
Cc: Jason Gunthorpe
Cc: Ralph Campbell
Cc: John Hubbard
Cc: Dan Williams
Cc: Dan Carpenter
Cc: Matthew Wilcox
Cc:
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them.
Hi all (but I guess mostly Jason),
Finally gotten around to rebasing the previous version, fixing the rebase
fail in there, update the commit message a bit and give this a spin with
some tests. Nicely caught a lockdep splat that we're now discussing in
i915, and seems to not have misfired
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job
== Series Details ==
Series: drm/i915: Serialise read/write of the barrier's engine
URL : https://patchwork.freedesktop.org/series/65152/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6698_full -> Patchwork_14003_full
Move the active tracking for the frontbuffer operations out of the
i915_gem_object and into its own first class (refcounted) object. In the
process of detangling, we switch from low level request tracking to the
easier i915_active -- with the plan that this avoids any potential
atomic callbacks as
On Wed, Aug 14, 2019 at 07:58:27AM +0200, Gerd Hoffmann wrote:
> > Hi Gerd,
> >
> > I've been seeing a regression on Nouveau with recent linux-next releases
> > and git bisect points at this commit as the first bad one. If I revert
> > it (there's a tiny conflict with a patch that was merged
Lift moving the timeline to/from the active_list on enter/exit in order
to shorten the active tracking span in comparison to the existing
pin/unpin.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 1 -
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
If we only call process_csb() from the tasklet, though we lose the
ability to bypass ksoftirqd interrupt processing on direct submission
paths, we can push it out of the irq-off spinlock.
The penalty is that we then allow schedule_out to be called concurrently
with schedule_in requiring us to
Hi,
> > Changing the order doesn't look hard. Patch attached (untested, have no
> > test hardware). But maybe I missed some detail ...
>
> I came up with something very similar by splitting up nouveau_bo_new()
> into allocation and initialization steps, so that when necessary the GEM
>
Quoting Chris Wilson (2019-08-13 18:55:46)
> Quoting Stuart Summers (2019-08-13 18:41:20)
> > Use render class instead of RCS0 when printing CCID.
> >
> > Signed-off-by: Stuart Summers
>
> One day, one day, this will be using some lists of registers.
>
> Reviewed-by: Chris Wilson
Pushed this
Forgo the struct_mutex requirement for request retirement as we have
been transitioning over to only using the timeline->mutex for
controlling the lifetime of a request on that timeline.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 183 ++
In preparation for removing struct_mutex from around context retirement,
we need to make timeline pinning safe. Since multiple engines/contexts
can share a single timeline, it needs to be protected by a mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 27
== Series Details ==
Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out
of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6706 -> Patchwork_14011
+ Abdiel/intel-gfx
Quoting Joonas Lahtinen (2019-08-14 15:46:01)
> Quoting Chris Wilson (2019-08-14 13:31:10)
> > Quoting Lukasz Kalamarz (2019-08-14 11:21:38)
> > > +/**
> > > + * gem_get_page_size:
> > > + * @fd: open i915 drm file descriptor
> > > + * @mem_region_type: used memory_region
Discussed this a bit with Chris, I think a comment here is warranted
that this will be bad once we have more than one i915 instance. And
lockdep won't catch it.
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 6 ++
1 file
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
Quoting Daniel Vetter (2019-08-14 13:49:33)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index d474c6ac4100..1ea3c3c96a5a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++
== Series Details ==
Series: series starting with [1/2] drm/i915/wopcm: Try to use already locked
WOPCM layout
URL : https://patchwork.freedesktop.org/series/65175/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6706 -> Patchwork_14012
== Series Details ==
Series: drm/i915/guc: Remove client->submissions
URL : https://patchwork.freedesktop.org/series/65159/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6700_full -> Patchwork_14005_full
Summary
---
Sorry I burried myself in some other stuff ...
On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > Quoting Christian König (2019-08-07 14:53:12)
> > > The only remaining use for this is to protect against setting a new
> > > exclusive
Quoting Koenig, Christian (2019-08-14 18:58:32)
> Am 14.08.19 um 19:48 schrieb Chris Wilson:
> > Quoting Chris Wilson (2019-08-14 18:38:20)
> >> Quoting Chris Wilson (2019-08-14 18:22:53)
> >>> Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> >
Quoting Daniel Vetter (2019-08-14 19:49:41)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index d474c6ac4100..1ea3c3c96a5a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++
== Series Details ==
Series: ttm
URL : https://patchwork.freedesktop.org/series/65194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14015
Summary
---
**SUCCESS**
No regressions found.
== Series Details ==
Series: dma-buf: Restore seqlock around dma_resv updates
URL : https://patchwork.freedesktop.org/series/65196/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cffdefd474fc dma-buf: Restore seqlock around dma_resv updates
-:7: ERROR:GIT_COMMIT_ID: Please use
On Wed, Aug 14, 2019 at 02:49:32PM +0200, Daniel Vetter wrote:
> Discussed this a bit with Chris, I think a comment here is warranted
> that this will be bad once we have more than one i915 instance. And
> lockdep won't catch it.
>
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniel
== Series Details ==
Series: dma-buf: Restore seqlock around dma_resv updates
URL : https://patchwork.freedesktop.org/series/65196/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14016
Summary
---
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
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex (rev3)
URL : https://patchwork.freedesktop.org/series/65177/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
68f7d12ba111 drm/i915: Comment userptr recursion on
On 8/13/19 1:16 PM, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/19 9:26 AM, Fernando Pacheco wrote:
>> We should not be skipping uc_fini_hw on finding GuC
>> is no longer running. There is plenty of hw and internal
>> state that can be cleaned up without having to communicate
>> with GuC.
>>
>
>
== Series Details ==
Series: HDCP2.2 Phase II (rev15)
URL : https://patchwork.freedesktop.org/series/57232/
State : failure
== Summary ==
Applying: drm: Add Content protection type property
Using index info to reconstruct a base tree...
M drivers/gpu/drm/drm_atomic_uapi.c
M
1 - 100 of 132 matches
Mail list logo
