On Sun, 23 Feb 2020, Chris Wilson wrote:
> Restore the previous WARN_ON(cond) so that we don't complain about poor
> old Cherryview.
>
> Fixes: eb020ca3d43f ("drm/i915/display/dp: Make WARN* drm specific where
> drm_device ptr is available")
> Signed-off-by: Chris Wilson
> Cc: Pankaj Bharadiya
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73745/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7979_full -> Patchwork_16654_full
Summary
---
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73743/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7979_full -> Patchwork_16653_full
Summary
---
== Series Details ==
Series: series starting with [1/6] dma-buf: Proxy fence, an unsignaled fence
placeholder
URL : https://patchwork.freedesktop.org/series/73824/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7991 -> Patchwork_16679
== Series Details ==
Series: series starting with [1/6] dma-buf: Proxy fence, an unsignaled fence
placeholder
URL : https://patchwork.freedesktop.org/series/73824/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: dma-buf: Proxy fence, an unsignaled
== Series Details ==
Series: series starting with [1/6] dma-buf: Proxy fence, an unsignaled fence
placeholder
URL : https://patchwork.freedesktop.org/series/73824/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
09c82611f40a dma-buf: Proxy fence, an unsignaled fence placeholder
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real
To correctly implement PIPE_FLUSH_DEFERRED iris needs to combine
I915_EXEC_FENCE_SUBMIT with a syncobj so that it can use semaphores
without running afoul of priority-inversion and use efficient scheduling
with timeslicing.
-Chris
___
Intel-gfx mailing
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index
== Series Details ==
Series: drm/i915/lspcon: Make sure link rate did not exceed downstream and
lspcon limitation (rev2)
URL : https://patchwork.freedesktop.org/series/73012/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7978_full -> Patchwork_16652_full
On 21/02/2020 23:03, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup
On 21/02/2020 23:02, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> Signed-off-by: Daniel Vetter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tidss/tidss_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
== Series Details ==
Series: drm/i915/display: Fix inverted WARN_ON
URL : https://patchwork.freedesktop.org/series/73823/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7991 -> Patchwork_16678
Summary
---
**SUCCESS**
Restore the previous WARN_ON(cond) so that we don't complain about poor
old Cherryview.
Fixes: eb020ca3d43f ("drm/i915/display/dp: Make WARN* drm specific where
drm_device ptr is available")
Signed-off-by: Chris Wilson
Cc: Pankaj Bharadiya
Cc: Jani Nikula
---
On 2/23/20 4:45 PM, Christian König wrote:
Am 21.02.20 um 18:12 schrieb Daniel Vetter:
[SNIP]
Yeah the Great Plan (tm) is to fully rely on ww_mutex slowly
degenerating
into essentially a global lock. But only when there's actual contention
and thrashing.
Yes exactly. A really big problem in
On Thu, 20 Feb 2020, Pankaj Bharadiya
wrote:
> drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available
> drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available
Thanks for the patches, pushed everything except these, which are for
Zhenyu & Zhi.
BR,
Jani.
--
Jani
On Fri, 21 Feb 2020, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 04:05:17PM -0800, Kees Cook wrote:
>> Variables declared in a switch statement before any case statements
>> cannot be automatically initialized with compiler instrumentation (as
>> they are not part of any execution flow). With
On Wed, 19 Feb 2020, Matt Roper wrote:
> On Wed, Feb 19, 2020 at 05:45:42PM +0200, Jani Nikula wrote:
>> Ensure const data goes to rodata.
>>
>> Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
>> Cc: Matt Roper
>> Cc: Stanislav Lisovskiy
>> Cc: Ville Syrjälä
>>
On Wed, 19 Feb 2020, Jani Nikula wrote:
> Pair the irq install and uninstall in the same layer. There are no
> functional changes in the happy day scenario. The cleanup paths are
> currently a mess though.
>
> Note that modeset probe pre-irq + post-irq install are matched by
> modeset driver
Den 21.02.2020 22.02, skrev Daniel Vetter:
> drm_mode_config_cleanup is idempotent, so no harm in calling this
> twice. This allows us to gradually switch drivers over by removing
> explicit drm_mode_config_cleanup calls.
>
> With this step it's not also possible that (at least for simple
>
== Series Details ==
Series: drm/i915: Distribute switch variables for initialization (rev2)
URL : https://patchwork.freedesktop.org/series/73690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7977_full -> Patchwork_16651_full
== Series Details ==
Series: drm/i915/tgl: Allow DC5/DC6 entry while PG2 is active
URL : https://patchwork.freedesktop.org/series/73739/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7977_full -> Patchwork_16650_full
26 matches
Mail list logo
