Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.16 next-20180406]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/
On Fri, Apr 06, 2018 at 07:02:02PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote:
> >
> >
> > On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote:
> > > On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:
> > >> HDCP1.4 key can be loaded,
On Sat, Apr 07, 2018 at 11:34:57AM +0200, Hans de Goede wrote:
> Hi,
>
> On 06-04-18 18:06, Ville Syrjälä wrote:
> > On Thu, Apr 05, 2018 at 01:37:31PM +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 04-04-18 22:49, Ville Syrjälä wrote:
> > > > On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 9, 2018 2:04 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
>
> Op 09-04-18 om 05:40 sc
Op 09-04-18 om 05:40 schreef Vidya Srinivas:
> Series contain preparation patches for NV12 support
> Enabling NV12 KMD support will follow the series
>
> Chandra Konduru (3):
> drm/i915: Set scaler mode for NV12
> drm/i915: Update format_is_yuv() to include NV12
> drm/i915: Upscale scaler max
On Fri, Apr 06, 2018 at 09:10:43AM +0300, Tomi Valkeinen wrote:
> On 05/04/18 19:50, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> omap_framebuffer_get_next_connector() uses plane->fb which we want to
> >> deprecate for a
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 9, 2018 2:04 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
>
> Op 09-04-18 om 05:40 sc
Op 09-04-18 om 10:57 schreef Srinivas, Vidya:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Monday, April 9, 2018 2:04 PM
>> To: Srinivas, Vidya ; intel-
>> g...@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Prepa
On 06/04/2018 21:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-05 13:39:19)
From: Tvrtko Ursulin
Keep a count of requests submitted from userspace and not yet runnable due
unresolved dependencies.
v2: Rename and move under the container struct. (Chris Wilson)
v3: Rebase.
Signed-of
On 06/04/2018 21:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-05 13:39:22)
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests currently executing
on the GPU.
This is useful to analyze the overall load of the system.
v2:
* Rebase.
* Drop floating point
Quoting Tvrtko Ursulin (2018-04-09 10:11:53)
>
> On 06/04/2018 21:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-05 13:39:19)
> >> From: Tvrtko Ursulin
> >>
> >> Keep a count of requests submitted from userspace and not yet runnable due
> >> unresolved dependencies.
> >>
> >> v2: Ren
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 9, 2018 2:38 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: Kamath, Sunil
> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
>
> Op
On Fri, 23 Mar 2018, Timo Aaltonen wrote:
> On 30.01.2018 00:12, Rodrigo Vivi wrote:
>> On Mon, Jan 29, 2018 at 05:42:53AM +, Kai Heng Feng wrote:
>>>
On 26 Jan 2018, at 6:25 AM, Rodrigo Vivi wrote:
If the table result is out of bounds on the array map
there is something r
If we try to suspend a wedged device following a GPU reset failure, we
will also fail to turn off the rc6 powerwells (on vlv), leading to a
*ERROR*. This is quite expected in this case, so the best we can do is
shake our heads and reduce the *ERROR* to a debug so CI stops
complaining.
Testcase: ig
Quoting Chris Wilson (2018-04-09 10:49:05)
> If we try to suspend a wedged device following a GPU reset failure, we
> will also fail to turn off the rc6 powerwells (on vlv), leading to a
> *ERROR*. This is quite expected in this case, so the best we can do is
> shake our heads and reduce the *ERROR
On 09/04/2018 10:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-09 10:11:53)
On 06/04/2018 21:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-05 13:39:19)
From: Tvrtko Ursulin
Keep a count of requests submitted from userspace and not yet runnable due
unresolved dependencie
As different backends may have different park/unpark callbacks, we
should only ever switch backends (reset_default_submission on wedge
recovery, or on enabling the guc) while parked.
v2: Remove the assert from the guc code, as we are currently trying to
modify the engine vfuncs pointer on a live s
== Series Details ==
Series: drm/i915: Silence debugging DRM_ERROR for failing to suspend vlv
powerwells
URL : https://patchwork.freedesktop.org/series/41350/
State : success
== Summary ==
Series 41350v1 drm/i915: Silence debugging DRM_ERROR for failing to suspend vlv
powerwells
https://patc
Quoting Tvrtko Ursulin (2018-04-09 11:17:04)
>
> On 09/04/2018 10:25, Chris Wilson wrote:
> > Downside being that we either then use atomic64 throughout or we mix
> > atomic32/atomic64 knowing that we're on x86. (I feel like someone else
> > must have solved this problem in a much neater way, befo
Quoting Chris Wilson (2018-04-09 11:27:17)
> Quoting Tvrtko Ursulin (2018-04-09 11:17:04)
> >
> > On 09/04/2018 10:25, Chris Wilson wrote:
> > > Downside being that we either then use atomic64 throughout or we mix
> > > atomic32/atomic64 knowing that we're on x86. (I feel like someone else
> > > m
On Fri, Apr 06, 2018 at 04:47:08PM +0300, Jani Nikula wrote:
> On Thu, 05 Apr 2018, Abhay Kumar wrote:
> > In glk when device boots with 1366x768 panel, HDA codec doesn't comeup.
> > This result in no audio forever as cdclk is < 96Mhz.
> > This chagne will ensure CD clock to be twice of BCLK.
>
On 4/9/2018 3:48 PM, Chris Wilson wrote:
As different backends may have different park/unpark callbacks, we
should only ever switch backends (reset_default_submission on wedge
recovery, or on enabling the guc) while parked.
v2: Remove the assert from the guc code, as we are currently trying to
On 09/04/2018 11:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-09 11:17:04)
On 09/04/2018 10:25, Chris Wilson wrote:
Downside being that we either then use atomic64 throughout or we mix
atomic32/atomic64 knowing that we're on x86. (I feel like someone else
must have solved this prob
Quoting Sagar Arun Kamble (2018-04-09 11:38:34)
>
>
> On 4/9/2018 3:48 PM, Chris Wilson wrote:
> > As different backends may have different park/unpark callbacks, we
> > should only ever switch backends (reset_default_submission on wedge
> > recovery, or on enabling the guc) while parked.
> >
> >
On Mon, 09 Apr 2018 12:41:22 +0200, Chris Wilson
wrote:
Quoting Sagar Arun Kamble (2018-04-09 11:38:34)
On 4/9/2018 3:48 PM, Chris Wilson wrote:
> As different backends may have different park/unpark callbacks, we
> should only ever switch backends (reset_default_submission on wedge
> reco
Quoting Tvrtko Ursulin (2018-04-09 11:40:08)
>
> On 09/04/2018 11:27, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-09 11:17:04)
> >>
> >> On 09/04/2018 10:25, Chris Wilson wrote:
> >>> Downside being that we either then use atomic64 throughout or we mix
> >>> atomic32/atomic64 knowing t
== Series Details ==
Series: drm/i915: Park before resetting the submission backend (rev2)
URL : https://patchwork.freedesktop.org/series/41202/
State : warning
== Summary ==
Series 41202v2 drm/i915: Park before resetting the submission backend
https://patchwork.freedesktop.org/api/1.0/series/
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more than
important than the current queue, we will rerun the submission tasklet
to evaluate the n
Now with i915_reset_engine() marking the stalled request as guilty,
preemption timeout doesn't lead into a GPU hang death spiral; at the
loss of potentially resetting a context with no harm (in practice that
didn't work out!).
A bit ambivalent on the flip forcing reset, both the stutter and glitch
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Revi
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Reviewed-by: Jeff McGee
---
dr
In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC:
Prepare to allow the GuC submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 5 +++--
1 file changed, 3 insertions(+), 2 de
Ideally, we want to atomically flush and disable the tasklet before
resetting the GPU. At present, we rely on being the only part to touch
our tasklet and serialisation of the reset process to ensure that we can
suspend the tasklet from the mix of reset/wedge pathways. In this patch,
we move the ta
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
v2: Restore checking of use_csb_mmio on every loop, don't forget old
vgpu.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
-
We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting
Install a timer when trying to preempt on behalf of an important
context such that if the active context does not honour the preemption
request within the desired timeout, then we reset the GPU to allow the
important context to run.
v2: Install the timer on scheduling the preempt request; long bef
When circumstances allow, trying resetting the engine directly from the
preemption timeout handler. As this is softirq context, we have to be
careful both not to sleep and not to spin on anything we may be
interrupting (e.g. the submission tasklet).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Prepare to allow the execlists submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletio
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 inserti
One usecase would be to couple in via EGL_NV_context_priority_realtime
in userspace to provide some QoS guarantees in conjunction with setting
the highest priority.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 22 ++
drivers/gpu/drm/i915/i915_gem_context.h
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU, or CPU, hogs. This is at the cost
of resetting whoever was blocking the preemption, likely leading to that
context/process being ba
The choice of preemption timeout is determined by the context from which
we trigger the preemption, as such allow the caller to specify the
desired timeout.
Effectively the other choice would be to use the shortest timeout along
the dependency chain. However, given that we would have already
trigg
The majority of the engine state dumping is too voluminous to be useful
outside of a controlled setup, though a few do accompany severe errors.
Keep the debug dumps next to the errors, but hide the others behind a CI
compile flag. This becomes more useful when adding more dumps to latency
sensitive
== Series Details ==
Series: drm/i915: Silence debugging DRM_ERROR for failing to suspend vlv
powerwells
URL : https://patchwork.freedesktop.org/series/41350/
State : success
== Summary ==
Possible new issues:
Test gem_pwrite:
Subgroup big-gtt-backwards:
skip
Add an additional comparison to check the entire vma created in the mappable
region of the global GTT against the one in the unmappable range.
Further test with an assert_partial as well to ensure the VMA corresponds
to the original object's backing store.
Signed-off-by: Abdiel Janulgue
Cc: Joon
From: Chris Wilson
One important use of partial vma is to provide mappable access to the
object while it is being used elsewhere (pinned entirely into the
unmappable portion of the Global GTT, i.e. for use as a display scanout).
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/
== Series Details ==
Series: series starting with [01/18] drm/i915/execlists: Set queue priority
from secondary port
URL : https://patchwork.freedesktop.org/series/41357/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fe34e7d49f28 drm/i915/execlists: Set queue priority from sec
Quoting Abdiel Janulgue (2018-04-09 12:28:04)
> Add an additional comparison to check the entire vma created in the mappable
> region of the global GTT against the one in the unmappable range.
>
> Further test with an assert_partial as well to ensure the VMA corresponds
> to the original object's
== Series Details ==
Series: series starting with [01/18] drm/i915/execlists: Set queue priority
from secondary port
URL : https://patchwork.freedesktop.org/series/41357/
State : success
== Summary ==
Series 41357v1 series starting with [01/18] drm/i915/execlists: Set queue
priority from sec
On 09/04/2018 11:51, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-09 11:40:08)
On 09/04/2018 11:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-09 11:17:04)
On 09/04/2018 10:25, Chris Wilson wrote:
Downside being that we either then use atomic64 throughout or we mix
atomic32
Op 09-04-18 om 11:41 schreef Srinivas, Vidya:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Monday, April 9, 2018 2:38 PM
>> To: Srinivas, Vidya ; intel-
>> g...@lists.freedesktop.org
>> Cc: Kamath, Sunil
>> Subject: Re: [Intel-gfx]
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Extend partial vma
coverage to check parallel creation
URL : https://patchwork.freedesktop.org/series/41359/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6a326fc76a03 drm/i915/selftests: Extend partia
Quoting Tvrtko Ursulin (2018-04-09 12:43:50)
>
> On 09/04/2018 11:51, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-09 11:40:08)
> >>
> >> On 09/04/2018 11:27, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-04-09 11:17:04)
>
> On 09/04/2018 10:25, Chris Wilson wrote:
>
Quoting Tvrtko Ursulin (2018-04-06 13:35:14)
> From: Tvrtko Ursulin
>
> Include fence context and seqno in low level tracing so it is easier to
> follow flows of individual requests when things go bad.
>
> Also added tracing on the reset side of things.
>
> v2:
> Chris Wilson:
> * Standardize
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Extend partial vma
coverage to check parallel creation
URL : https://patchwork.freedesktop.org/series/41359/
State : success
== Summary ==
Series 41359v1 series starting with [1/2] drm/i915/selftests: Extend partial
From: Chris Wilson
As different backends may have different park/unpark callbacks, we
should only ever switch backends (reset_default_submission on wedge
recovery, or on enabling the guc) while parked.
v2: Remove the assert from the guc code, as we are currently trying to
modify the engine vfunc
Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EIO).
Unfortunately since commit 121981fafe69 ("dr
In function gem_init_hw() we are calling uc_init_hw() but in case
of error later in function, we missed to call matching uc_fini_hw()
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
1 file ch
We should keep i915_gem_init/fini functions together for easier
tracking of their symmetry.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 20
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_ge
We have i915_gem_init_hw function that on failure requires some
cleanup in uC and then in other places we were trying to do
such cleanup directly. Let's fix that by adding i915_gem_fini_hw
for nice symmetry with init_hw and call it on cleanup paths.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun
In commit 9192d4fb811e ("drm/i915/guc: Extract doorbell creation
from client allocation") we introduced asymmetry in doorbell cleanup
to avoid warnings due to failed communication with already reset GuC.
As we improved our reset/unload paths, we can restore symmetry in
doorbell cleanup, as GuC shou
As we always call intel_uc_sanitize after every call to
intel_uc_fini_hw we may drop redundant call and sanitize
uC from the fini_hw function.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 --
drivers/gpu/drm/i915/intel_uc.c | 9
By calling in i915_reset only i915_gem_init_hw without previous
i915_gem_fini_hw we introduced asymmetry. Let's fix that.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu
By calling i915_gem_init_hw in i915_gem_resume and not calling
i915_gem_fini_hw in i915_gem_suspend we introduced asymmetry
in init_hw/fini_hw calls. Let's fix that.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
Signed-off-by: Michal Wajdeczko
Reviewed-by: Sagar Arun Kamble
---
drivers/g
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/
We don't have to check load status values.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_huc.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
[Adding some people to Cc for more ack/nack type feedback.]
Executive question is ack or nack on replacing intel_gpu_top with a new
implementation which uses only perf PMU for counter gathering.
A short history on how this came to be:
There was a recent external patch contribution from Rinat
On GLK sporadic timeouts occur during PHY0 enabling. Based on logs it looks
like they happen sometime after a system suspend/resume cycle, with the
same power well enabling succeeding both before and after the failed
one and no other problems observed. The current timeout in the code is
not actuall
Quoting Michal Wajdeczko (2018-04-09 13:23:26)
> By calling in i915_reset only i915_gem_init_hw without previous
> i915_gem_fini_hw we introduced asymmetry. Let's fix that.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Sagar Arun Kamble
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
> ---
> driver
Our execlists emulation for GuC requires use of the breadcrumb following
every request as a simulcrum for the context-switch interrupt, which we
then use to drive the submission tasklet. Therefore, when we unpark the
engine for use with the GuC, we pin the breadcrumb interrupt to keep it
enabled fo
All the references to get_existing_state can be converted to
get_new_state or get_old_state, which means that i915 is now
get_existing_state free.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 51
1 file changed, 23 insertions(+)
The get_existing macros are deprecated and should be replaced by
get_old/new_state for clarity.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 5 +++--
drivers/gpu/drm/i915/intel_drv.h| 11 ---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
3 files changed,
The workaround was applied only to the primary plane, but is required
on all planes. Iterate over all planes in the crtc atomic check to see
if the workaround is enabled, and only perform the actual toggling in
the pre/post plane update functions.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu
Quoting Michal Wajdeczko (2018-04-09 13:23:28)
> As we always call intel_uc_sanitize after every call to
> intel_uc_fini_hw we may drop redundant call and sanitize
> uC from the fini_hw function.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Sagar Arun Kamble
> Cc: Chris Wilson
Not that it matters
get_existing_crtc_state is currently unused, get rid of it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e545aa673bd9..9969309132d
== Series Details ==
Series: series starting with [v8,01/12] drm/i915: Park before resetting the
submission backend
URL : https://patchwork.freedesktop.org/series/41365/
State : success
== Summary ==
Series 41365v1 series starting with [v8,01/12] drm/i915: Park before resetting
the submissio
On Mon, Apr 09, 2018 at 02:46:53PM +0200, Maarten Lankhorst wrote:
> The get_existing macros are deprecated and should be replaced by
> get_old/new_state for clarity.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 5 +++--
> drivers/gpu/drm/i915/intel_drv.h
On Mon, Apr 09, 2018 at 02:46:54PM +0200, Maarten Lankhorst wrote:
> get_existing_crtc_state is currently unused, get rid of it.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_drv.h | 14 --
> 1 file changed, 14 deletions(-)
>
>
On Mon, Apr 09, 2018 at 02:46:55PM +0200, Maarten Lankhorst wrote:
> All the references to get_existing_state can be converted to
> get_new_state or get_old_state, which means that i915 is now
> get_existing_state free.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_disp
== Series Details ==
Series: series starting with [01/18] drm/i915/execlists: Set queue priority
from secondary port
URL : https://patchwork.freedesktop.org/series/41357/
State : failure
== Summary ==
Possible new issues:
Test gem_ctx_param:
Subgroup invalid-param-get:
On Mon, Apr 09, 2018 at 02:46:56PM +0200, Maarten Lankhorst wrote:
> The workaround was applied only to the primary plane, but is required
> on all planes. Iterate over all planes in the crtc atomic check to see
> if the workaround is enabled, and only perform the actual toggling in
> the pre/post
== Series Details ==
Series: drm/i915/gen9_lp: Increase DDI PHY0 power well enabling timeout
URL : https://patchwork.freedesktop.org/series/41366/
State : success
== Summary ==
Series 41366v1 drm/i915/gen9_lp: Increase DDI PHY0 power well enabling timeout
https://patchwork.freedesktop.org/api/
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Extend partial vma
coverage to check parallel creation
URL : https://patchwork.freedesktop.org/series/41359/
State : failure
== Summary ==
Possible new issues:
Test drv_selftest:
Subgroup mock_vma:
Quoting Sagar Arun Kamble (2018-03-15 09:23:25)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > Valleyview and Cherryview update the GPU frequency via the punit, which
> > is very expensive as we have to ensure the cores do not sleep during the
> > comms.
> But the patch 5 applies this workar
Quoting Sagar Arun Kamble (2018-03-15 12:06:57)
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > struct intel_rps {
> > + struct mutex lock;
> > +
> I think this lock can now become part of struct intel_gt_pm.
Maybe, haven't decided yet. Anything but rps is so infrequent as not to
really matt
On Fri, 06 Apr 2018, Rodrigo Vivi wrote:
> On Fri, Apr 06, 2018 at 10:58:51PM +0530, vathsala nagaraju wrote:
>> From: Vathsala Nagaraju
>>
>> For psr block #9, the vbt description has moved to options [0-3] for
>> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
>> structure
== Series Details ==
Series: drm/i915/guc: Check that the breadcrumb irq is enabled
URL : https://patchwork.freedesktop.org/series/41368/
State : success
== Summary ==
Series 41368v1 drm/i915/guc: Check that the breadcrumb irq is enabled
https://patchwork.freedesktop.org/api/1.0/series/41368/r
On Mon, Apr 09, 2018 at 03:27:16PM +0300, Imre Deak wrote:
> On GLK sporadic timeouts occur during PHY0 enabling. Based on logs it looks
> like they happen sometime after a system suspend/resume cycle, with the
> same power well enabling succeeding both before and after the failed
> one and no othe
On Fri, 06 Apr 2018, José Roberto de Souza wrote:
> A simple page flip can cause the CFB required size to increase and
> if it is bigger than the currently allocated CFB it needs to be
> resized to activate FBC again.
>
> Until now this case was not being handled but CI is starting to
> get some o
Quoting Sagar Arun Kamble (2018-03-16 03:39:56)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > Since intel_sideband_read and intel_sideband_write differ by only a
> > couple of lines (depending on whether we feed the value in or out),
> > merge the two into a single common accessor.
> >
> >
== Series Details ==
Series: series starting with [1/4] drm/i915: Change use get_new_plane_state
instead of existing plane state
URL : https://patchwork.freedesktop.org/series/41370/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
591b58b45998 drm/i915: Change use get_new_plane_
Op 09-04-18 om 15:04 schreef Ville Syrjälä:
> On Mon, Apr 09, 2018 at 02:46:55PM +0200, Maarten Lankhorst wrote:
>> All the references to get_existing_state can be converted to
>> get_new_state or get_old_state, which means that i915 is now
>> get_existing_state free.
>>
>> Signed-off-by: Maarten L
On Sun, 08 Apr 2018, Gaurav K Singh wrote:
> On Geminilake, sometimes audio card is not getting
> detected after reboot. This is a spurious issue happening on
> Geminilake. HW codec and HD audio controller link was going
> out of sync for which there was a fix in i915 driver but
> was not getting
Quoting Sagar Arun Kamble (2018-03-16 04:58:22)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > Currently Ironlake operates under the assumption that rpm awake (and its
> > error checking is disabled). As such, we have missed a few places where we
> > access registers without taking the rpm w
On Mon, 09 Apr 2018 14:42:19 +0200, Chris Wilson
wrote:
Our execlists emulation for GuC requires use of the breadcrumb following
every request as a simulcrum for the context-switch interrupt, which we
then use to drive the submission tasklet. Therefore, when we unpark the
engine for use with
On Mon, 09 Apr 2018 14:47:24 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-04-09 13:23:28)
As we always call intel_uc_sanitize after every call to
intel_uc_fini_hw we may drop redundant call and sanitize
uC from the fini_hw function.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Ar
1 - 100 of 157 matches
Mail list logo
