Hi,
On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
Hi,
Thank you for your review and sorry for the slow reply.
No problem for me, I didn't hold my breath :-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b
On 01/07/2020 00:27, Dave Airlie wrote:
On Sat, 27 Jun 2020 at 03:17, Daniele Ceraolo Spurio
wrote:
On 6/26/20 12:14 AM, Lucas De Marchi wrote:
Cc Matt and Daniele
On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie wrote:
I can't figure this out easily so I'd thought I'd just ask, but does
DG1
On 06/07/2020 23:43, Chris Wilson wrote:
Looking through the attributes for DMA mappings, it appears that by
default dma_map_sg will try and create a kernel accessible map of the
page. We never access this, as we either have a struct page already or
an iomap, so we can request that the dma mapper
On Mon, 6 Jul 2020 at 18:01, Chris Wilson wrote:
>
> On eviction, we acquire the vm->mutex and then wait on the vma->active.
> Thereore when binding and pinning the vma, we must follow the same
> sequence, lock/pin the vma then mark it active. Otherwise, we mark the
> vma as active, then wait for
Op 03-07-2020 om 15:48 schreef Tvrtko Ursulin:
>
> On 03/07/2020 13:22, Maarten Lankhorst wrote:
>> Some i915 selftests still use i915_vma_lock() as inner lock, and
>> intel_context_create_request() intel_timeline->mutex as outer lock.
>> Fortunately for selftests this is not an issue, they should
Since schedule-in/out is now entirely serialised by the tasklet bitlock,
we do not need to worry about concurrent in/out operations and so reduce
the atomic operations to plain instructions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915
Since we started doing direct submission to reduce the initial
submission stall, we split the submit tasklet into two: one part that
was wholly undercontrol of the tasklet, and the rest called from mixed
contexts. For the latter, we required additional extra spinlocks and
atomic handling to ensure
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it bac
As context-in/out is now always serialised, we do not have to worry
about concurrent enabling/disable of the busy-stats and can reduce the
atomic_t active to a plain unsigned int, and the seqlock to a seqcount.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8 ++-
Lift the busy-stats context-in/out implementation out of intel_lrc, so
that we can reuse it for other scheduler implementations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 49
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the con
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 44 +
1 file changed, 19 inser
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any. Ho
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtua
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue u
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --gi
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
By keeping the unwind order intact on the local engine, we can preserve
data depend
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fas
On 07/07/2020 11:19, Maarten Lankhorst wrote:
Op 03-07-2020 om 15:48 schreef Tvrtko Ursulin:
On 03/07/2020 13:22, Maarten Lankhorst wrote:
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selft
Op 07-07-2020 om 12:56 schreef Tvrtko Ursulin:
>
> On 07/07/2020 11:19, Maarten Lankhorst wrote:
>> Op 03-07-2020 om 15:48 schreef Tvrtko Ursulin:
>>>
>>> On 03/07/2020 13:22, Maarten Lankhorst wrote:
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_re
== Series Details ==
Series: series starting with [01/12] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/79183/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fbb4ac3d3d2f drm/i915/gt: Decouple completed requests on unwind
5a59
== Series Details ==
Series: series starting with [01/12] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/79183/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be check
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/dp: Helper for checking
DDI_BUF_CTL Idle status
URL : https://patchwork.freedesktop.org/series/79018/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8688_full -> Patchwork_18062_full
==
== Series Details ==
Series: series starting with [01/12] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/79183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8709 -> Patchwork_18093
===
On Mon, Jul 06, 2020 at 08:53:06PM +, Souza, Jose wrote:
> On Fri, 2020-07-03 at 14:38 +0300, Ville Syrjälä wrote:
> > On Thu, Jul 02, 2020 at 11:24:04PM +, Souza, Jose wrote:
> > > On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Consult
On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
> Hi,
>
> Thank you for your review and sorry for the slow reply.
No problem for me, I didn't hold my breath :-)
> > > diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> > > index 43b1fc634af1..80d0f9c64f9d 100644
> > >
Hello Hans,
On Mon, Jul 06, 2020 at 11:05:20PM +0200, Hans de Goede wrote:
> Before I post a new version of this patch-set, you have only responded
> to some of the PWM patches in this set. Do you have any remarks on the
> other PWM patches ?
I stopped looking at them as I hoped someone would app
Hello,
On Sat, Jun 20, 2020 at 02:17:52PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
> this
Hello Hans,
On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote:
> Now that the PWM drivers which we use have been converted to the atomic
> PWM API, we can move the i915 panel code over to using the atomic PWM API.
Note that there is no hard dependency, the atomic API should work just
Fix typo: "TRIGER" --> "TRIGGER"
The two misplelled macros:
1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK
2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK
are not used in any other sources of the kernel,
so this change can be consider only a local change
for the i915_reg.h file.
Signed-off-by: F
== Series Details ==
Series: drm/i915: Fix spelling mistake in i915_reg.h (rev2)
URL : https://patchwork.freedesktop.org/series/79156/
State : failure
== Summary ==
Applying: drm/i915: Fix spelling mistake in i915_reg.h
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i91
Hi
On 19.06.2020 12:36, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called w
== Series Details ==
Series: series starting with [01/12] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/79183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8709_full -> Patchwork_18093_full
=
If we assign obj->filp, we believe that the create vgem bo is native and
allow direct operations like mmap() assuming it behaves as backed by a
shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store misleading.
Note, that regular mmap acc
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/dr
We removed retiring requests from the shrinker in order to decouple the
mutexes from reclaim in preparation for unravelling the struct_mutex.
The impact of not retiring is that we are much less agressive in making
global objects available for shrinking, as such objects remain pinned
until they are
== Series Details ==
Series: series starting with [1/2] drm/vgem: Do not allocate backing shmemfs
file for an import dmabuf object
URL : https://patchwork.freedesktop.org/series/79203/
State : failure
== Summary ==
Applying: drm/vgem: Do not allocate backing shmemfs file for an import dmabuf
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9357a85637f9 drm/i915/gem: Unpin idle contexts from kswapd reclaim
-:25: WARNING:COMMIT_LOG_LON
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18096
Summary
---
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions th
Quoting lepton (2020-07-07 18:05:21)
> On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
> >
> > If we assign obj->filp, we believe that the create vgem bo is native and
> > allow direct operations like mmap() assuming it behaves as backed by a
> > shmemfs inode. When imported from a dmabuf, the
Hi,
On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
Hi,
Thank you for your review and sorry for the slow reply.
No problem for me, I didn't hold my breath :-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
>
> If we assign obj->filp, we believe that the create vgem bo is native and
> allow direct operations like mmap() assuming it behaves as backed by a
> shmemfs inode. When imported from a dmabuf, the obj->pages are
> not always meaningful and the
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f694486df0d8 drm/i915/display: Fix initial fb to use resource_size_t
-:17: ERROR:GIT_COMMIT_I
On 07/07/2020 18:15, Chris Wilson wrote:
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits withi
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18097
Summary
--
Quoting Tvrtko Ursulin (2020-07-07 18:48:23)
>
> On 07/07/2020 18:15, Chris Wilson wrote:
> > We lookup up the physical address of the inherited framebuffer, and
> > presume that is an offset into the stolen memory region. As we are
> > dealing with physical resources and their addresses, we need
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions th
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
40ee693823d1 drm/i915/display: Fix initial fb to use resource_size_t
-:17: ERROR:GIT_C
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote:
>
> Quoting lepton (2020-07-07 18:05:21)
> > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson
> > wrote:
> > >
> > > If we assign obj->filp, we believe that the create vgem bo is native and
> > > allow direct operations like mmap() assuming it behav
Quoting lepton (2020-07-07 19:17:51)
> On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote:
> >
> > Quoting lepton (2020-07-07 18:05:21)
> > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson
> > > wrote:
> > > >
> > > > If we assign obj->filp, we believe that the create vgem bo is native and
> > > >
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18098
Summary
Hi Uwe,
On 7/7/20 9:50 AM, Uwe Kleine-König wrote:
Hello Hans,
On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote:
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
Note that there is
Hi,
On 7/7/20 9:09 PM, Uwe Kleine-König wrote:
Hello Hans,
On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote:
On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
But if we do then I think closest to the truth would be:
stat
Last user removed, remove the convenience function.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
2 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/d
Some objects we map once during their construction, and then never
access their mappings again, even if they are kept around for the
duration of the driver. Keeping those pages mapped, often vmapped, is
therefore wasteful and we should release the maps as soon as we no
longer need them.
Signed-off
As we have a pin_map interface, that knows how to flush the data to the
device, use it. The only downside is that we keep the kmap around, as
once acquired we keep the mapping cached until the object's backing
store is released.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowe
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't going to complain if the read-side
isn't neste
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mm
Hi all,
Bunch of changes that might matter:
- Clarification that dma_fences are for drivers/gpu, requested by Jason
Gunthorpe.
- New patch to list all the past discussions around
indefinite/future/whatever fences, and why this (sadly) still just plain
doesn't work. Came up again when discu
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vge
Ends right after hw_done(), totally standard case.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
b/drivers/gpu/drm/tidss/tidss_kms.c
index b6e61d6cf
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no exper
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines
Again needs to be put right after the call to
drm_atomic_helper_commit_hw_done(), since that's the last thing which
can hold up a subsequent atomic commit.
No surprises here.
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
---
drivers/gpu/drm/arm/mal
I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris
Nothing special, just put the end right after hw_done(). Note that in
one path there's a wait for the flip/update to complete. But as far as
I understand from comments and code that's only relevant for modesets,
and skipped if there wasn't a modeset done on a given crtc.
For a bit more clarity pul
Like the helpers, nothing special. Well except not, because we the
critical section extends until after hw_done(), since that's the last
thing which could hold up a subsequent atomic commit. That means the
wait_for_flip_done is included, but that's not a problem, we're
allowed to call dma_fence_wai
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
i
Not going to bother with a complete&pretty commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:
kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
drm_sched
Again ends just after drm_atomic_helper_commit_hw_done(), but with the
twist that we need to make sure we're only annotate the custom
version. And not the other clause which just calls
drm_atomic_helper_commit_tail_rpm(), which is already annotated.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Gives us proper nonblocking support for free, and a pile of other
things. The tilcdc code is simply old enough that it was never
converted over, but was stuck forever with the copypasta from when it
was initially merged.
The riskiest thing with this conversion is maybe that there's an issue
with t
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this
This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.
A nice side effect of this is
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] ---
drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup
apparrently), so it's the entire function. And a nice comment
explaining why thw wait_for_flip_done is ahead, unlike the usual
sequence.
Aside, I think since the atomic helpers do track plane disabling now
separately this might
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: l
Ends right after drm_atomic_helper_commit_hw_done(), absolutely
nothing fancy going on here.
Signed-off-by: Daniel Vetter
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: linux-renesas-...@vger.kernel.org
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be h
On Tue, 2020-06-30 at 15:19 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/display: Implement new combo phy initialization step (rev3)
> URL : https://patchwork.freedesktop.org/series/78796/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8677_full
Hi Daniel.
On Tue, Jul 07, 2020 at 10:12:13PM +0200, Daniel Vetter wrote:
> One of these drivers that predates the nonblocking support in helpers,
> and hand-rolled its own thing. Entirely not anything specific here, we
> can just delete it all and replace it with the helper version.
>
> Could al
Two new PCI ids added to ehl.
v2: added two additional PCI ids
BSpec: 29153
Cc: Matt Roper
Cc: Anusha Srivatsa
Signed-off-by: José Roberto de Souza
---
include/drm/i915_pciids.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Replace opencoded
i915_gem_object_pin_map()
URL : https://patchwork.freedesktop.org/series/79211/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3286cb8bd6d2 drm/i915/gt: Replace opencoded i915_gem_object_pin_
Hello Hans,
On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote:
> On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
> > On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
> > > But if we do then I think closest to the truth would be:
> > >
> > > state->period = UINT_MAX;
> > >
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Replace opencoded
i915_gem_object_pin_map()
URL : https://patchwork.freedesktop.org/series/79211/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18099
===
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Michał Winiarski
Cc
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in case
of GuC fetch error,
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18096_full
Summar
== Series Details ==
Series: drm/i915/ehl: Add new PCI ids (rev2)
URL : https://patchwork.freedesktop.org/series/78910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18100
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18097_full
Summ
On Tue, Jul 07, 2020 at 01:45:30PM -0700, José Roberto de Souza wrote:
> Two new PCI ids added to ehl.
>
> v2: added two additional PCI ids
>
> BSpec: 29153
> Cc: Matt Roper
> Cc: Anusha Srivatsa
> Signed-off-by: José Roberto de Souza
Reviewed-by: Matt Roper
> ---
> include/drm/i915_pciids
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ef2cbad3c3f dma-fence: basic lockdep annotations
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/amd/amdgpu/
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18098_full
===
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18101
Summary
---
**SUCCESS**
1 - 100 of 127 matches
Mail list logo
