Quoting Antonio Argenziano (2018-08-16 00:59:30)
>
>
> On 15/08/18 10:24, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-08-15 18:20:10)
> >>
> >>
> >> On 15/08/18 03:26, Chris Wilson wrote:
> >>> Quoting Antonio Argenziano (2018-08-15 00:50:43)
>
>
> On 10/08/18 04:01, C
On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
> On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
>> On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
>>
>> First of all we need to fix the commit subject:
>>
>> drm/i915: Increase LSPCON timeout
>>
>> (this can be done when m
On 15/08/2018 12:58, Tvrtko Ursulin wrote:
On 14/08/2018 15:59, Lionel Landwerlin wrote:
Hey Tvrtko,
Thanks for taking over this series.
I've been talking to developers using the i915/perf interface and from
their point of view, they expect the system to be in a stable
configuration when d
Regards
Shashank
On 8/16/2018 12:47 PM, Jani Nikula wrote:
On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wrote:
First of all we need to fix the commit subject:
drm/i915: Increa
The context owns both the ppgtt and the vma within it, and our activity
tracking on the context ensures that we do not release active ppgtt. As
the context fulfils our obligations for active memory tracking, we can
relinquish the reference from the vma.
This fixes a silly transient refleak from cl
Include a count of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr.
Signed-off-by: Chris Wilso
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 119
On Tue, Aug 14, 2018 at 11:39:48AM +0200, Takashi Iwai wrote:
> On Tue, 14 Aug 2018 11:34:07 +0200,
> Daniel Vetter wrote:
> >
> > On Tue, Aug 14, 2018 at 02:54:31PM +0800, Feng Tang wrote:
> > > Hi Jani, Daniel
> > >
> > > Could you help to comment? thanks,
> > >
> > > - Feng
> > >
> > > On Th
== Series Details ==
Series: series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt
from each vma
URL : https://patchwork.freedesktop.org/series/48297/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
179bc3e01013 drm/i915: Stop holding a ref to the ppgtt from each
Quoting Sharma, Shashank (2018-08-16 08:33:36)
> Regards
>
> Shashank
>
>
> On 8/16/2018 12:47 PM, Jani Nikula wrote:
> > On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
> >> On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
> >>> On Mon, Aug 13, 2018 at 07:51:33PM +0200, Fredrik Schön wro
On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote:
> The pm_rpm module-reload exists to exercise a rpm wakeref leak, and
> affects the random selection of tests run after it. Similar to the
> normal module-reload tests, care must be taken in its execution to avoid
> causing spurious fail
== Series Details ==
Series: series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt
from each vma
URL : https://patchwork.freedesktop.org/series/48297/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4676 -> Patchwork_9960 =
== Summary - SUCCESS ==
No regres
Quoting Petri Latvala (2018-08-16 08:56:27)
> On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote:
> > The pm_rpm module-reload exists to exercise a rpm wakeref leak, and
> > affects the random selection of tests run after it. Similar to the
> > normal module-reload tests, care must be tak
Hey Chris,
On 8/16/2018 1:13 PM, Chris Wilson wrote:
Quoting Sharma, Shashank (2018-08-16 08:33:36)
Regards
Shashank
On 8/16/2018 12:47 PM, Jani Nikula wrote:
On Wed, 15 Aug 2018, Rodrigo Vivi wrote:
On Wed, Aug 15, 2018 at 03:39:40PM -0700, Rodrigo Vivi wrote:
On Mon, Aug 13, 2018 at 0
On Thu, Aug 16, 2018 at 09:00:37AM +0100, Chris Wilson wrote:
> Quoting Petri Latvala (2018-08-16 08:56:27)
> > On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote:
> > > The pm_rpm module-reload exists to exercise a rpm wakeref leak, and
> > > affects the random selection of tests run aft
== Series Details ==
Series: series starting with [1/3] drm/i915: Stop holding a ref to the ppgtt
from each vma
URL : https://patchwork.freedesktop.org/series/48297/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4676_full -> Patchwork_9960_full =
== Summary - SUCCESS ==
Quoting Petri Latvala (2018-08-16 09:43:10)
> On Thu, Aug 16, 2018 at 09:00:37AM +0100, Chris Wilson wrote:
> > Quoting Petri Latvala (2018-08-16 08:56:27)
> > > On Thu, Aug 16, 2018 at 07:06:46AM +0100, Chris Wilson wrote:
> > > > The pm_rpm module-reload exists to exercise a rpm wakeref leak, and
Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Jani Nikula
> Sent: torstai 16. elokuuta 2018 10.18
> To: Vivi, Rodrigo ; Fredrik Schön
>
> Cc: intel-gfx@lists.freedesktop.org; Fredrik Schön
>
> Subject: Re: [Intel-gfx] [PATCH] [
On 16/08/18 08:31, Tvrtko Ursulin wrote:
On 15/08/2018 12:58, Tvrtko Ursulin wrote:
On 14/08/2018 15:59, Lionel Landwerlin wrote:
Hey Tvrtko,
Thanks for taking over this series.
I've been talking to developers using the i915/perf interface and
from their point of view, they expect the syst
Chris Wilson writes:
> Show the reset depth (the tasklet disable count) in the GEM_TRACE to
> indicate when we might not expect tasklets to be flushed.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff
Quoting Mika Kuoppala (2018-08-16 12:04:28)
> Chris Wilson writes:
>
> > Show the reset depth (the tasklet disable count) in the GEM_TRACE to
> > indicate when we might not expect tasklets to be flushed.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 6 --
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
Signed-off-by: Chris Wils
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
v2: Handle the perma-pinned contexts.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 29 +
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume
URL : https://patchwork.freedesktop.org/series/48310/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
af4e727f9fdd drm/i915/execlists: Delay updating ring
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume
URL : https://patchwork.freedesktop.org/series/48310/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/execlists: Delay updating ring register
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume
URL : https://patchwork.freedesktop.org/series/48310/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4677 -> Patchwork_9961 =
== Summary - FAILURE ==
Chris Wilson writes:
> The context owns both the ppgtt and the vma within it, and our activity
> tracking on the context ensures that we do not release active ppgtt. As
> the context fulfils our obligations for active memory tracking, we can
> relinquish the reference from the vma.
>
The part of
Quoting Mika Kuoppala (2018-08-16 12:42:08)
> Chris Wilson writes:
>
> > The context owns both the ppgtt and the vma within it, and our activity
> > tracking on the context ensures that we do not release active ppgtt. As
> > the context fulfils our obligations for active memory tracking, we can
>
Quoting Chris Wilson (2018-08-16 12:11:49)
> That we use a WB mapping for updating the RING_TAIL register inside the
> context image even on !llc machines has been a source of consternation
> for every reader. It appears to work on bsw+, but it may just have been
> that we have been incredibly bad
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-16 12:42:08)
>> Chris Wilson writes:
>>
>> > The context owns both the ppgtt and the vma within it, and our activity
>> > tracking on the context ensures that we do not release active ppgtt. As
>> > the context fulfils our obligations for ac
Quoting Mika Kuoppala (2018-08-16 13:14:37)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-08-16 12:42:08)
> >> Chris Wilson writes:
> >>
> >> > The context owns both the ppgtt and the vma within it, and our activity
> >> > tracking on the context ensures that we do not release active
From: Chris Wilson
Currently, we cancel the extra wakeref we have for !runtime-pm devices
inside power_wells_fini_hw. However, this is not strictly paired with
the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may
be called on errors paths before we even call runtime_pm_enable)
The device global init_power_on flag is somewhat arbitrary and makes
debugging power refcounting problems difficult. Instead arrange things
so that all display power domain get has a corresponding put call. After
this change we have the following sequences:
driver loading:
intel_power_domains_init
Quoting Imre Deak (2018-08-16 13:37:57)
> The device global init_power_on flag is somewhat arbitrary and makes
> debugging power refcounting problems difficult. Instead arrange things
> so that all display power domain get has a corresponding put call. After
> this change we have the following sequ
Quoting Mika Kuoppala (2018-08-16 13:14:37)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-08-16 12:42:08)
> >> Chris Wilson writes:
> >>
> >> > The context owns both the ppgtt and the vma within it, and our activity
> >> > tracking on the context ensures that we do not release active
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First c
Add needed plane control flag definitions for P010, P012 and
P016 formats.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/dr
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 24 +-
drivers/gpu/drm/i915/intel_sprite.c | 39 ++
== Series Details ==
Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable
to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/48315/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
62108989ff60 drm/i915: Introduce intel_runti
Chris Wilson writes:
> Include a count of closed vma when reporting the per_ctx_stats of
> debugfs/i915_gem_objects.
>
The code corresponds for you to report a count of bytes of a closed vmas
and I am not sure which one do you want.
-Mika
> Whilst adjusting the context tracking, note that we
Quoting Mika Kuoppala (2018-08-16 14:29:33)
> Chris Wilson writes:
>
> > Include a count of closed vma when reporting the per_ctx_stats of
> > debugfs/i915_gem_objects.
> >
>
> The code corresponds for you to report a count of bytes of a closed vmas
> and I am not sure which one do you want.
By
== Series Details ==
Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable
to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/48315/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4678 -> Patchwork_9962 =
== Summary - SU
== Series Details ==
Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions
and fourcc
URL : https://patchwork.freedesktop.org/series/48316/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0cb3dff0a6d4 drm: Add P010, P012, P016 format definitions and fou
== Series Details ==
Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions
and fourcc
URL : https://patchwork.freedesktop.org/series/48316/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: Add P010, P012, P016 format definitions and fourcc
Okay!
== Series Details ==
Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions
and fourcc
URL : https://patchwork.freedesktop.org/series/48316/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4678 -> Patchwork_9963 =
== Summary - SUCCESS ==
No regres
If we've explicitly disabled the display, we will never find any
connected outputs or modes. Checking for them will fail and report the
missing requirement instead.
Signed-off-by: Chris Wilson
Cc: Imre Deak
---
tests/pm_rpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Thu, Aug 16, 2018 at 01:47:08PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Introduce
> intel_runtime_pm_disable to pair intel_runtime_pm_enable
> URL : https://patchwork.freedesktop.org/series/48315/
> State : success
Pushed to -dinq, tha
If we've explicitly disabled the display, we will never find any
connected outputs or modes. Checking for them will fail and report the
missing requirement instead.
v2: Sigh, avoid more comparisons against enabled displays
Signed-off-by: Chris Wilson
Cc: Imre Deak
---
tests/pm_rpm.c | 10 -
Shashank,
Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
:
>
> Hey Chris,
>
>
> On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 8/16/2018 12:47 PM, Jani Nikula wrote:
> >>> On Wed, 15 Aug 2018, Ro
If we've explicitly disabled the display, we will never find any
connected outputs or modes. Checking for them will fail and report the
missing requirement instead.
v2: Sigh, avoid more comparisons against enabled displays
v3: Try occasionally compiling patches
Signed-off-by: Chris Wilson
Cc: Im
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
v2: With extra enthusiasm
Op 16-08-18 om 14:55 schreef Juha-Pekka Heikkila:
> Enabling of P010, P012 and P016 formats. These formats will
> extend NV12 for larger bit depths.
>
> Signed-off-by: Juha-Pekka Heikkila
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 24 +-
>
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume (rev2)
URL : https://patchwork.freedesktop.org/series/48310/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b8bbc947a979 drm/i915/execlists: Delay updatin
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume (rev2)
URL : https://patchwork.freedesktop.org/series/48310/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/execlists: Delay updating ring re
== Series Details ==
Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable
to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/48315/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4678_full -> Patchwork_9962_full =
== Su
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume (rev2)
URL : https://patchwork.freedesktop.org/series/48310/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4680 -> Patchwork_9964 =
== Summary - SUCC
== Series Details ==
Series: series starting with [1/4] drm: Add P010, P012, P016 format definitions
and fourcc
URL : https://patchwork.freedesktop.org/series/48316/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4678_full -> Patchwork_9963_full =
== Summary - WARNING ==
On 16/08/18 00:08, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-16 00:59:30)
On 15/08/18 10:24, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 18:20:10)
On 15/08/18 03:26, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 00:50:43)
On 10/08/18 04:01, C
Quoting Antonio Argenziano (2018-08-16 18:42:17)
>
>
> On 16/08/18 00:08, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-08-16 00:59:30)
> >>
> >>
> >> On 15/08/18 10:24, Chris Wilson wrote:
> >>> Quoting Antonio Argenziano (2018-08-15 18:20:10)
>
>
> On 15/08/18 03:26, C
On Wed, Aug 08, 2018 at 10:53:35AM +0200, Jan-Marek Glogowski wrote:
> This re-applies the workaround for "some DP sinks, [which] are a
> little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> quality check unconditionally during long pulse").
> It makes the secondary AOC E2460P monitor c
Loading the sounds modules is asynchronous with the sysfs device
hierarchy being instantiated sometime after modprobe returns. As such
while we are probing for the sound device, poll a few times to
accommodate the async discovery.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Tvrtko Ursulin
---
On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> Shashank,
>
> Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> :
> >
> > Hey Chris,
> >
> >
> > On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > > Quoting Sharma, Shashank (2018-08-16 08:33:36)
> > >> Regards
> > >>
> > >> Shasha
On Fri, Jul 27, 2018 at 12:36:47PM -0700, Lucas De Marchi wrote:
> Instead of defining all registers twice, define just a PCH_GPIO_BASE
> that has the same address as PCH_GPIO_A and use that to calculate all
> the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> the same thing.
>
On Thu, Aug 16, 2018 at 11:49:26AM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 27, 2018 at 12:36:47PM -0700, Lucas De Marchi wrote:
> > Instead of defining all registers twice, define just a PCH_GPIO_BASE
> > that has the same address as PCH_GPIO_A and use that to calculate all
> > the others. This al
Hi Dave,
Here goes drm-intel-next-fixes-2018-08-16-1:
Fixes for:
- DP full color range.
- selftest for gem_object
- forcewake on suspend
- GPU reset
This also include accumulated fixes from GVT:
- Fix an error code in gvt_dma_map_page() (Dan)
- Fix off by one error in intel_vgpu_write_fence() (D
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Delay updating ring
register state after resume (rev2)
URL : https://patchwork.freedesktop.org/series/48310/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4680_full -> Patchwork_9964_full =
== Summ
If the request is currently on the HW (in port 0), then we do not need
to kick the submission tasklet to evaluate whether we should be
preempting itself in order to execute it again.
In the case that was annoying me:
execlists_schedule: rq(18:211173).prio=0 -> 2
need_preempt: last(18:211174
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
v2: With extra enthusiasm
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/d
Select the runtime-pm kconfig option if the general i915 debug option is
selected so that anyone using CI/IGT should be co-opted into enabling the
extra debug tracking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
dif
Using the guc, we cannot disable the user interrupt generation as we use
it for driving submission. And from Icelake, we no longer have the
ability to individually mask interrupt generation from each engine,
disabling our ability to fake missed interrupts.
In both cases, report back to userspace t
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dp.c | 227 +---
1 file changed, 118 insertions(+), 109 deleti
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 wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
Show the reset depth (the tasklet disable count) in the GEM_TRACE to
indicate when we might not expect tasklets to be flushed.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_guc_submission.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
In the sequence
<0>[ 531.960431] drv_self-48067 527402570us : intel_gpu_reset:
engine_mask=1, ret=0, retry=0
<0>[ 531.960431] drv_self-48067 527402571us : execlists_reset: rcs0
request global=115de, current=71133
<0>[ 531.960431] drv_self-48067d..1 527402571us :
execlists
If we have an available execlists port, the queue_priority should be
INT_MIN to allow immediate direct submission. As we clear the ports in
execlists_cancel_port_requests(), we should then reset queue_priority to
show the available space.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/inte
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 119
Fix up the error unwind for logical_ring_init() failing by moving the
cleanup into the callers who own the various bits of state during
initialisation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff
We can bypass ksoftirqd for restarting our submission queue after a GPU
reset and so avoid any inscrutable delays.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 24 +
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
2 files changed, 25 inse
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig
Include the total size of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr.
Signed-off-by: Chri
Attach our device_info to the our i915 private on creation so that it is
always available for inspection.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 66 +++--
1 file changed, 38 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
We need to exercise the HW and submission paths for switching contexts
rapidly to check that features such as execlists' wa_tail are adequate.
Plus it's an interesting baseline latency metric.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 185 ++
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
v2: Handle the perma-pinned contexts.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 29 +
Currently, we convert the error state into a string every time we read
from sysfs (and sysfs reads in page size (4KiB) chunks). We do try to
window the string and only capture the portion that is being read, but
that means that we must always convert up to the window to find the
start. For a very l
tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> > Shashank,
> >
> > Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> > :
> > >
> > > Hey Chris,
> > >
> > >
> > > On 8/16/2018 1:13 PM, Chris Wilson wrote:
> > > > Qu
On Thu, Aug 16, 2018 at 11:35:26PM +0200, fredriksc...@gmail.com wrote:
> tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> > On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> > > Shashank,
> > >
> > > Den tors 16 aug. 2018 kl 10:15 skrev Sharma, Shashank
> > > :
> > > >
> >
== Series Details ==
Series: series starting with [01/23] drm/i915: Cache the error string
URL : https://patchwork.freedesktop.org/series/48362/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
31a8de99a658 drm/i915: Cache the error string
07069ce0121b drm/i915/execlists: Avoid ki
== Series Details ==
Series: series starting with [01/23] drm/i915: Cache the error string
URL : https://patchwork.freedesktop.org/series/48362/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Cache the error string
+drivers/gpu/drm/i915/i915_gpu_error.c:820:25: war
tor 2018-08-16 klockan 14:43 -0700 skrev Rodrigo Vivi:
> On Thu, Aug 16, 2018 at 11:35:26PM +0200, fredriksc...@gmail.com
> wrote:
> > tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> > > On Thu, Aug 16, 2018 at 10:36:43AM +0200, Fredrik Schön wrote:
> > > > Shashank,
> > > >
> > > > Den t
On Thu, Aug 16, 2018 at 11:51:07PM +0200, Fredrik Schön wrote:
> tor 2018-08-16 klockan 14:43 -0700 skrev Rodrigo Vivi:
> > On Thu, Aug 16, 2018 at 11:35:26PM +0200, fredriksc...@gmail.com
> > wrote:
> > > tor 2018-08-16 klockan 11:23 -0700 skrev Rodrigo Vivi:
> > > > On Thu, Aug 16, 2018 at 10:36:
== Series Details ==
Series: series starting with [01/23] drm/i915: Cache the error string
URL : https://patchwork.freedesktop.org/series/48362/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4682 -> Patchwork_9965 =
== Summary - SUCCESS ==
No regressions found.
Extern
On Thu, Jul 26, 2018 at 07:44:06PM +0530, Mahesh Kumar wrote:
> This patch adds support to decode system memory bandwidth and other
> parameters for broxton platform, which will be used for arbitrated
> display memory bandwidth calculation in GEN9 based platforms and
> WM latency level-0 Work-aroun
On Thu, Jul 26, 2018 at 07:44:07PM +0530, Mahesh Kumar wrote:
> This patch adds support to decode system memory bandwidth and other
> parameters for skylake and Gen9+ platforms, which will be used for
> arbitrated display memory bandwidth calculation in GEN9 based
> platforms and WM latency level-0
== Series Details ==
Series: series starting with [01/23] drm/i915: Cache the error string
URL : https://patchwork.freedesktop.org/series/48362/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4682_full -> Patchwork_9965_full =
== Summary - WARNING ==
Minor unknown changes
100 matches
Mail list logo
