== Series Details ==
Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3)
URL : https://patchwork.freedesktop.org/series/71760/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16045_full
Yet again unrelated gem failure, do we have a bug about this?
That CDCLK change is crucial to get in and has nothing to do with
gem tests, i.e can't anyhow affect the outcome.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
_
On 13/01/2020 10:32, Lisovskiy, Stanislav wrote:
> Yet again unrelated gem failure, do we have a bug about this?
>
https://bugs.freedesktop.org/show_bug.cgi?id=112271
> That CDCLK change is crucial to get in and has nothing to do with
> gem tests, i.e can't anyhow affect the outcome.
Btw, TGL
Hi,
> -Original Message-
> From: Peres, Martin
> Sent: maanantai 13. tammikuuta 2020 10.55
> To: Lisovskiy, Stanislav ; intel-
> g...@lists.freedesktop.org; Vudum, Lakshminarayana
> ; Saarinen, Jani
> Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Bump up CDCLK to eliminate
> underruns
Thanks for fast response :)
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Peres, Martin
Sent: Monday, January 13, 2020 10:54:47 AM
To: Lisovskiy, Stanislav; intel-gfx@lists.freedesktop.org;
== Series Details ==
Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3)
URL : https://patchwork.freedesktop.org/series/71760/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16045_full
On Fri, 10 Jan 2020, José Roberto de Souza wrote:
> Renaming to match the BSpec and struct name.
>
> BSpec: 20150
> Cc: Jani Nikula
> Signed-off-by: José Roberto de Souza
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
> drivers/gpu/drm/i915/display/int
Currently, we skip error capture upon forced preemption. We apply forced
preemption when there is a higher priority request that should be
running but is being blocked, and we skip inline error capture so that
the preemption request is not further delayed by a user controlled
capture -- extending t
Since commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a
plain list"), we used the default embedded priotree slot for the virtual
engine request queue, which means we can also use the same solitary slot
with the scheduler. However, the priolist is expected to be guarded by
the engine->
Currently, we reset the timer after a pre-eemption event. This has the
side-effect that the timeslice runs into the second context after the
first is completed. To be more fair, we want to reset the clock after
promotion as well.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/dr
In order to support out-of-line error capture, we need to remove the
active request from HW and put it to one side while a worker compresses
and stores all the details associated with that request. (As that
compression may take an arbitrary user-controlled amount of time, we
want to let the engine
As a final paranoid step (we _should_ have reset the GPU on suspending
the device prior to unload), reset the GPU once more before removing the
powercontext and other related power saving paraphernalia.
A clue that this may not be the case is
<7> [313.203721] __intel_gt_set_wedged rcs'0
<7> [313.
Quoting Wambui Karuga (2020-01-13 11:10:25)
> fn(...) {
> ...
> struct intel_engine_cs *E = ...;
> +struct drm_i915_private *dev_priv = E->i915;
No new dev_priv.
There should be no reason for drm_dbg here, as the rest of the debug is
behind ENGINE_TRACE and so the vestigial debug should be moved
== Series Details ==
Series: Use new logging macros in drm/i915
URL : https://patchwork.freedesktop.org/series/71824/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16040_full
Summary
---
**SUCC
On Fri, 10 Jan 2020, Vivek Kasireddy wrote:
> Parsing the i2c element is mainly done to transfer the payload from the
> MIPI sequence block to the relevant slave device. In some cases, the
> commands that are part of the payload can be used to turn on the backlight.
>
> This patch is actually a re
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Start chopping up the GPU error
capture
URL : https://patchwork.freedesktop.org/series/71838/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16044_full
=
As a final paranoid step (we _should_ have reset the GPU on suspending
the device prior to unload), reset the GPU once more before removing the
powercontext and other related power saving paraphernalia.
A clue that this may not be the case is
<7> [313.203721] __intel_gt_set_wedged rcs'0
<7> [313.
We only want to try and reset a wedged device on resume, not before
suspend, so lift the recovery out of the commont gt_sanitize().
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 23 ---
1 file changed, 12 insertions
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Always reset the timeslice
after a context switch
URL : https://patchwork.freedesktop.org/series/71951/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
83ec2e3b2a82 drm/i915/gt: Always reset the timeslice after
== Series Details ==
Series: drm/i915/gtt: add missing include file asm/smp.h (rev2)
URL : https://patchwork.freedesktop.org/series/71825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16041_full
Summ
== Series Details ==
Series: drm/i915: add Wa_14010594013: icl,ehl
URL : https://patchwork.freedesktop.org/series/71858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16047_full
Summary
---
**S
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fabbc8e407e7 drm/i915/gt: Sanitize and reset GPU before removing powercontext
-:31:
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.
Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we
Add new struct drm_device based WARN* macros. These are modeled after
the core kernel device based WARN* macros. These would be preferred
over the regular WARN* macros, where possible.
These macros include device information in the backtrace, so we know
what device the warnings originate from.
Kn
On Fri, 10 Jan 2020, Stanislav Lisovskiy wrote:
> There seems to be some undocumented bandwidth
> bottleneck/dependency which scales with CDCLK,
> causing FIFO underruns when CDCLK is too low,
> even when it's correct from BSpec point of view.
>
> Currently for TGL platforms we calculate
> min_cdc
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatica
We will need struct drm_device pointer to pass it to drm_WARN* calls.
Add helper functions to exract drm_device pointer from various structs.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display_types.h | 14 ++
drivers/gpu/drm/i915/gvt/gvt.h
Drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where first function argument is a
struct pointer and has drm_i915_private struct pointer mem
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where any one of intel_pm, intel_encoder,
i915_perf_stream or intel_crtc_state struct poi
On Mon, 13 Jan 2020, Chris Wilson wrote:
> Quoting Wambui Karuga (2020-01-13 11:10:25)
>> fn(...) {
>> ...
>> struct intel_engine_cs *E = ...;
>> +struct drm_i915_private *dev_priv = E->i915;
>
> No new dev_priv.
Wambui, we're gradually converting all dev_priv variable and parameter
names to i915
On Mon, 13 Jan 2020, Pankaj Bharadiya
wrote:
> We will need struct drm_device pointer to pass it to drm_WARN* calls.
>
> Add helper functions to exract drm_device pointer from various structs.
Please don't do this.
We use the helpers we currently have when they involve something more
complex th
On Mon, 13 Jan 2020, Pankaj Bharadiya
wrote:
> Add new struct drm_device based WARN* macros. These are modeled after
> the core kernel device based WARN* macros. These would be preferred
> over the regular WARN* macros, where possible.
>
> These macros include device information in the backtrace,
On Mon, 13 Jan 2020, Pankaj Bharadiya
wrote:
> Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> include device information in the backtrace, so we know what device
> the warnings originate from.
>
> Similar to this, add new struct drm_device based drm_WARN* macros. These
>
On Fri, Jan 10, 2020 at 06:40:38PM +, Souza, Jose wrote:
> On Wed, 2020-01-08 at 18:20 +0200, Ville Syrjälä wrote:
> > On Wed, Jan 08, 2020 at 04:09:31PM +, Souza, Jose wrote:
> > > On Wed, 2020-01-08 at 16:45 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > When mo
== Series Details ==
Series: drm: Clean up VBLANK callbacks in struct drm_driver
URL : https://patchwork.freedesktop.org/series/71873/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7715_full -> Patchwork_16048_full
Summary
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Always reset the timeslice
after a context switch
URL : https://patchwork.freedesktop.org/series/71951/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK inclu
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Always reset the timeslice
after a context switch
URL : https://patchwork.freedesktop.org/series/71951/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7729 -> Patchwork_16068
=
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Ker
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext
URL : https://patchwork.freedesktop.org/series/71952/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7729 -> Patchwork_16069
Summa
On Fri, Jan 10, 2020 at 06:54:13PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-01-10 18:32:23)
> > From: Ville Syrjälä
> >
> > intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
> > it is present. We copy that from the master plane to the slave plane,
> > but we fai
Quoting Ville Syrjälä (2020-01-13 13:15:16)
> On Fri, Jan 10, 2020 at 06:54:13PM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2020-01-10 18:32:23)
> > > From: Ville Syrjälä
> > >
> > > intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
> > > it is present. We copy that
As a final paranoid step (we _should_ have reset the GPU on suspending
the device prior to unload), reset the GPU once more before removing the
powercontext and other related power saving paraphernalia.
A clue that this may not be the case is
<7> [313.203721] __intel_gt_set_wedged rcs'0
<7> [313.
As a final paranoid step (we _should_ have reset the GPU on suspending
the device prior to unload), reset the GPU once more before removing the
powercontext and other related power saving paraphernalia.
A clue that this may not be the case is
<7> [313.203721] __intel_gt_set_wedged rcs'0
<7> [313.
On Wed, 2019-12-04 at 20:05 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have uses for intel_attached_dp() outside of intel_dp.c. Move
> it to a header.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 5 +
On Mon, 13 Jan 2020, Chen Zhou wrote:
> If CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=m, compilation complains
> with undefined references:
>
> drivers/gpu/drm/i915/display/intel_panel.o: In function
> `intel_backlight_device_register':
> intel_panel.c:(.text+0x4dd9): undefined reference to
Currently, we only retire the oldest request on the timeline before
allocating the next, but only if there is a spare request. However,
since we rearranged the locking, e.g. commit df9f85d8582e ("drm/i915:
Serialise i915_active_fence_set() with itself"), we no longer benefit
from keeping the activ
Quoting Chris Wilson (2020-01-13 14:04:07)
> Currently, we only retire the oldest request on the timeline before
> allocating the next, but only if there is a spare request. However,
> since we rearranged the locking, e.g. commit df9f85d8582e ("drm/i915:
> Serialise i915_active_fence_set() with it
Currently, we only retire the oldest request on the timeline before
allocating the next, but only if there is a spare request. However,
since we rearranged the locking, e.g. commit df9f85d8582e ("drm/i915:
Serialise i915_active_fence_set() with itself"), we no longer benefit
from keeping the activ
On Mon, Jan 13, 2020 at 01:29:56PM +, Chris Wilson wrote:
> As a final paranoid step (we _should_ have reset the GPU on suspending
> the device prior to unload), reset the GPU once more before removing the
> powercontext and other related power saving paraphernalia.
>
> A clue that this may no
Quoting Chris Wilson (2020-01-13 14:07:15)
> @@ -1344,28 +1330,6 @@ void i915_request_add(struct i915_request *rq)
> __i915_request_queue(rq, &attr);
> local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
>
> - /*
> -* In typical scenarios, we do not
Hi Chris,
On Mon, Jan 13, 2020 at 11:29:17AM +, Chris Wilson wrote:
> We only want to try and reset a wedged device on resume, not before
> suspend, so lift the recovery out of the commont gt_sanitize().
Currently, we only retire the oldest request on the timeline before
allocating the next, but only if there is a spare request. However,
since we rearranged the locking, e.g. commit df9f85d8582e ("drm/i915:
Serialise i915_active_fence_set() with itself"), we no longer benefit
from keeping the activ
Quoting Ville Syrjälä (2020-01-13 14:09:23)
> On Mon, Jan 13, 2020 at 01:29:56PM +, Chris Wilson wrote:
> > As a final paranoid step (we _should_ have reset the GPU on suspending
> > the device prior to unload), reset the GPU once more before removing the
> > powercontext and other related powe
As a final paranoid step (we _should_ have reset the GPU on suspending
the device prior to unload), reset the GPU once more before removing the
powercontext and other related power saving paraphernalia.
A clue that this may not be the case is
<7> [313.203721] __intel_gt_set_wedged rcs'0
<7> [313.
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Sanitize and reset GPU before
removing powercontext
URL : https://patchwork.freedesktop.org/series/71953/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d07e3e5a44ae drm/i915/gt: Sanitize and reset GPU before
On 10.1.2020 20.32, Ville Syrjala wrote:
From: Ville Syrjälä
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
it is present. We copy that from the master plane to the slave plane,
but we fail to copy the corresponding ggtt view. Thus when it comes time
to pin the slave plane
On Mon, Dec 23, 2019 at 05:45:21PM +0200, Stanislav Lisovskiy wrote:
> Start manipulating DBuf slices as a mask,
> but not as a total number, as current approach
> doesn't give us full control on all combinations
> of slices, which we might need(like enabling S2
> only can't enabled by setting enab
== Series Details ==
Series: : drm: Introduce struct drm_device based WARN* and use them in i915
URL : https://patchwork.freedesktop.org/series/71954/
State : failure
== Summary ==
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, r
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Sanitize and reset GPU before
removing powercontext
URL : https://patchwork.freedesktop.org/series/71953/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK inc
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Sanitize and reset GPU before
removing powercontext
URL : https://patchwork.freedesktop.org/series/71953/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7733 -> Patchwork_16070
===
== Series Details ==
Series: drm/i915: Preemptive timeline retirement (rev3)
URL : https://patchwork.freedesktop.org/series/71958/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
052f69323628 drm/i915: More proactive timeline retirement before new requests
-:19: WARNING:COMMIT_LO
On Mon, Dec 23, 2019 at 05:45:20PM +0200, Stanislav Lisovskiy wrote:
> Current DBuf slices update wasn't done in proper
> place, especially its "post" part, which should
> disable those only once vblank had passed and
> all other changes are committed.
>
> v2: Fix to use dev_priv and intel_atomic_
== Series Details ==
Series: drm/i915: Preemptive timeline retirement (rev3)
URL : https://patchwork.freedesktop.org/series/71958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7733 -> Patchwork_16072
Summary
---
**S
== Series Details ==
Series: drm/i915: Preemptive timeline retirement (rev3)
URL : https://patchwork.freedesktop.org/series/71958/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/x86/boo
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev4)
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
aa9a347e9533 drm/i915/gt: Sanitize and reset GPU before removing powercontext
Take and hold a reference to each of the vma (and their objects) as we
process them with the cmdparser. This stops them being freed during the
work if the GEM execbuf is interrupted and the request we expected to
keep the objects alive is incomplete.
Fixes: 686c7c35abc2 ("drm/i915/gem: Asynchronou
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev4)
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compil
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev4)
URL : https://patchwork.freedesktop.org/series/71952/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7733 -> Patchwork_16073
As a final paranoid step (we _should_ have reset the GPU on suspending
the device prior to unload), reset the GPU once more before removing the
powercontext and other related power saving paraphernalia.
A clue that this may not be the case is
<7> [313.203721] __intel_gt_set_wedged rcs'0
<7> [313.
== Series Details ==
Series: drm/i915/gem: Take local vma references for the parser
URL : https://patchwork.freedesktop.org/series/71968/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7733 -> Patchwork_16074
Summary
---
== Series Details ==
Series: drm/i915/gem: Take local vma references for the parser
URL : https://patchwork.freedesktop.org/series/71968/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev5)
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d73a5619f429 drm/i915/gt: Sanitize and reset GPU before removing powercontext
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev5)
URL : https://patchwork.freedesktop.org/series/71952/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7733 -> Patchwork_16075
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev5)
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compil
On Mon, Dec 16, 2019 at 07:46:43PM -0800, Juston Li wrote:
> From: Daniel Stone
>
> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
> over addfb.
>
> Changes since v2:
> - add privilege checks from getfb1 since handles should only be
>returned to master/root
>
> Ch
As a final paranoid step (we _should_ have reset the GPU on suspending
the device prior to unload), reset the GPU once more before removing the
powercontext and other related power saving paraphernalia.
A clue that this may not be the case is
<7> [313.203721] __intel_gt_set_wedged rcs'0
<7> [313.
On Mon, Dec 16, 2019 at 07:48:40PM -0800, Juston Li wrote:
> From: Daniel Stone
>
> Mirroring addfb2, add tests for the new ioctl which will return us
> information about framebuffers containing multiple buffers, as well as
> modifiers.
>
> Changes since v3:
> - Add subtests to ensure handles ar
On 13/01/2020 10:44, Chris Wilson wrote:
Currently, we reset the timer after a pre-eemption event. This has the
side-effect that the timeslice runs into the second context after the
first is completed. To be more fair, we want to reset the clock after
promotion as well.
You mean after complet
This patch extracts the struct drm_i915_private device from struct
intel_engine_cs and converts the printk based logging macros to the
struct drm_based logging macros using the extracted struct.
This transformation was achieved using the following coccinelle script:
@rule1@
identifier fn, T, E;
@@
> On Jan 10, 2020, at 3:47 PM, Masami Hiramatsu wrote:
>
> On Fri, 10 Jan 2020 13:45:31 -0300
> Arnaldo Carvalho de Melo wrote:
>
>> Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
>>> On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra
>>> wrote:
Again, this only a
,Jann Horn ,Thomas Gleixner
,Tvrtko Ursulin ,Lionel
Landwerlin ,linux-kernel
,"linux-security-mod...@vger.kernel.org"
,"seli...@vger.kernel.org"
,"intel-gfx@lists.freedesktop.org"
,"b...@vger.kernel.org"
,"linux-par...@vger.kernel.org"
,"linuxppc-...@lists.ozlabs.org"
,"linux-perf-us...@vg
If no 'CONFIG_ACPI' configured, shouldn't call 'acpi_device_handle',
'acpi_dev_get_resources' and 'acpi_dev_free_resource_list' in function
'mipi_exec_i2c'.
Fixes: 8cbf89db2941("drm/i915/dsi: Parse the I2C element from the VBT MIPI
sequence block (v3)")
Reported-by: Hulk Robot
Signed-off-by: Zha
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there is an error
when compile the kernel:
drivers/gpu/drm/i915/gt/intel_reset.c:
In function intel_gt_handle_error:
drivers/gpu/drm/i915/gt/intel_reset.c:1233:3:
error: too few arguments to function i915_capture_error_state
i91
On Mon, 13 Jan 2020, Jani Nikula wrote:
On Mon, 13 Jan 2020, Chris Wilson wrote:
Quoting Wambui Karuga (2020-01-13 11:10:25)
fn(...) {
...
struct intel_engine_cs *E = ...;
+struct drm_i915_private *dev_priv = E->i915;
No new dev_priv.
Wambui, we're gradually converting all dev_priv var
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there are some
errors like:
drivers/gpu/drm/i915/i915_irq.o:
In function `i915_vma_capture_finish':
./drivers/gpu/drm/i915/i915_gpu_error.h:312:
multiple definition of `i915_vma_capture_finish'
drivers/gpu/drm/i915/i915_drv.o:
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Skip trying to unbind in
restore_ggtt_mappings
URL : https://patchwork.freedesktop.org/series/71876/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7716_full -> Patchwork_16049_full
==
== Series Details ==
Series: drm/i915/tgl: Add Wa_1409825376 to tgl (rev3)
URL : https://patchwork.freedesktop.org/series/71853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7733 -> Patchwork_16076
Summary
---
**SUC
== Series Details ==
Series: drm/i915/tgl: Add Wa_1409825376 to tgl (rev3)
URL : https://patchwork.freedesktop.org/series/71853/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/x86/boot/
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev6)
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4e50429aa2ae drm/i915/gt: Sanitize and reset GPU before removing powercontext
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev6)
URL : https://patchwork.freedesktop.org/series/71952/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7734 -> Patchwork_16077
== Series Details ==
Series: drm/i915/gt: Sanitize and reset GPU before removing powercontext (rev6)
URL : https://patchwork.freedesktop.org/series/71952/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compil
Hi Jani,
On Mon, Jan 13, 2020 at 02:14:51PM +0200, Jani Nikula wrote:
> On Mon, 13 Jan 2020, Pankaj Bharadiya
> wrote:
> > We will need struct drm_device pointer to pass it to drm_WARN* calls.
> >
> > Add helper functions to exract drm_device pointer from various structs.
>
> Please don't do t
On Fri, 2020-01-10 at 17:45 -0800, Matt Roper wrote:
> I don't think we've ever hit these new error codes, but they're
> documented in the gen11 pcode document, so we might as well add them
> to
> the handler.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
>
On Mon, Jan 13, 2020 at 02:33:36PM +0200, Jani Nikula wrote:
> On Mon, 13 Jan 2020, Pankaj Bharadiya
> wrote:
> > Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> > include device information in the backtrace, so we know what device
> > the warnings originate from.
> >
> >
On Fri, Jan 10, 2020 at 4:21 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> amdgpu over.
>
I would prefer to just change the signature of
amdgpu_display_get_crtc_scano
On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> radeon over.
>
I'd prefer to just change the signature of
radeon_get_crtc_scanoutpos() to m
Hi Pankaj.
On Mon, Jan 13, 2020 at 05:25:52PM +0530, Pankaj Bharadiya wrote:
> Add new struct drm_device based WARN* macros. These are modeled after
> the core kernel device based WARN* macros. These would be preferred
> over the regular WARN* macros, where possible.
>
> These macros include devi
On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
I think I'd prefer to just update the signatures of the relevant
functions rather than wrapping them.
A
On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert radeon over.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon
The bspec tells us we need to set this bit to avoid potential underruns.
v2: use new register write convention (Anshuman) add bspec 7386 ref.
Bspec: 7386
Bspec: 33450
Bspec: 33451
Cc: Anshuman Gupta
Reviewed-by: Rodrigo Vivi
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/i915_reg.h | 1
1 - 100 of 147 matches
Mail list logo
