== 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
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.
== 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: 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
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: 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/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/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
---
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
== 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
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 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
== 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
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
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
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
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, 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
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
== 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
---
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
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
== 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:
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 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 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 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
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
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
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
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
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:
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.
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
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
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 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:
== 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:
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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
68f7d12ba111 drm/i915: Comment userptr recursion on
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: 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
---
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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cffdefd474fc dma-buf: Restore seqlock around dma_resv updates
-:7: ERROR:GIT_COMMIT_ID: Please use
== 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.
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
> +++
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)
> >
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: drm/i915: Remove i915 ggtt WA since GT E0 (rev2)
URL : https://patchwork.freedesktop.org/series/65160/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6701_full -> Patchwork_14009_full
Summary
I was going to ask the status of this and then I looked and realized that I
never provided a commit message blrub. Oops. Here you go:
On Broadwell, the sampler was changed to not require extra padding for
simple (no arrays, mipmapping, or MSAA) 1D, 2D, and buffer surfaces.
Setting the
== Series Details ==
Series: ttm
URL : https://patchwork.freedesktop.org/series/65194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f98f53ff57bd ttm
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:33: WARNING:FILE_PATH_CHANGES: added, moved
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 relax reservation_object_add_shared_fence")
> 5d344f58da76 ("dma-buf:
This reverts
67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
5d344f58da76 ("dma-buf: nuke reservation_object seq number")
The scenario
Quoting Chris Wilson (2019-08-14 19:22:54)
You saw nothing; wrong experimental branch.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
---
drivers/gpu/drm/i915/Makefile | 7 +
drivers/gpu/drm/i915/ttm/Makefile | 5 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.c | 4 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.h | 12 ++
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c | 174 ++
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 16:39:08)
> + }
On Wed, Aug 14, 2019 at 06:20:28PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 18:06:26)
> > On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> [snip]
> > > > > > > if (old)
> > > > > > > -
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 16:39:08)
> > > > > > > > + } while
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 16:39:08)
> > > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > > >
> > > > What if someone is
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 around sync_timeline
> lists.
>
> The bot has tested
Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > >
> > > What if someone is real fast (like really real fast) and recycles the
> >
Quoting Daniel Vetter (2019-08-14 18:06:26)
> On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
[snip]
> > > > > > if (old)
> > > > > > - old->shared_count = 0;
> > > > > > - write_seqcount_end(>seq);
> > > >
On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> Now that dma_fence_signal always takes the spinlock to flush the
> cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> avoid code repetition.
>
> Suggested-by: Christian König
> Signed-off-by: Chris Wilson
>
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 5.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On Fri, Aug 09, 2019 at 05:36:39PM +0200, Heinrich wrote:
> Store the timestamp of the current vblank in the new field 'time' of the
> vblank trace event. If the timestamp is calculated by a driver that
> supports high-precision vblank timing, set the field 'high-prec' to
> 'true'.
>
> User space
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it
Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> >
> > What if someone is real fast (like really real fast) and recycles the
> > exclusive fence so you read the same pointer twice,
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it
On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > 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
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
Quoting Daniel Vetter (2019-08-14 16:39:08)
> 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 a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
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
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex
URL : https://patchwork.freedesktop.org/series/65177/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6707 -> Patchwork_14014
On Wed, Aug 14, 2019 at 3:06 PM Chris Wilson wrote:
>
> 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
> > ---
On 8/13/19 1:18 PM, Michal Wajdeczko wrote:
> On Tue, 13 Aug 2019 18:26:28 +0200, 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
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex
URL : https://patchwork.freedesktop.org/series/65177/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ea422f4a5a9e drm/i915: Comment userptr recursion on struct_mutex
== 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
>-Original Message-
>From: james qian wang (Arm Technology China) [mailto:james.qian.w...@arm.com]
>Sent: Tuesday, August 13, 2019 3:12 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst,
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0
URL : https://patchwork.freedesktop.org/series/65160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6700_full -> Patchwork_14006_full
Summary
---
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.
>>
>
>
+ 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
== 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
---
== 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: 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
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
> +++
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
== 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
== 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: 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
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
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.
>
>
1 - 100 of 132 matches
Mail list logo
