On Mon, Nov 14, 2016 at 06:59:16PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Signed-off-by: Gustavo Padovan
> ---
> tests/kms_atomic_transition.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition
On Tue, 15 Nov 2016, David Weinehall wrote:
> On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
>> On Thu, 06 Oct 2016, Tomeu Vizoso wrote:
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index 23a6c7213eca..7412a05fa5d9 100644
>
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 35cf03508d8466ecc5199c9d609e74e85bec785b
commit: 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29 [23/26] drm/fb_cma_helper: Add
drm_fb_cma_prepare_fb() helper
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2
On Mon, Nov 14, 2016 at 06:59:18PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Signed-off-by: Gustavo Padovan
gtkdoc for anything exported would always be nice ...
-Daniel
> ---
> lib/igt_kms.c | 6 +++---
> lib/igt_kms.h | 5 +
> 2 files changed, 8 insertions(+), 3 deletion
On Mon, Nov 14, 2016 at 06:59:22PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Signed-off-by: Gustavo Padovan
> ---
> tests/kms_atomic.c | 124
> +
> 1 file changed, 115 insertions(+), 9 deletions(-)
>
> diff --git a/tests/kms_
Hi Abdiel,
here running the whole of kms_busy causes all subtests after the first
one to be skipped due to:
Test requirement not met in function __real_main164, file
../../intel-gpu-tools/tests/kms_busy.c:195:
Test requirement: gem_has_ring(display.drm_fd, e->exec_id | e->flags)
If I run the sub
On Tue, Nov 15, 2016 at 04:29:04PM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
> head: 35cf03508d8466ecc5199c9d609e74e85bec785b
> commit: 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29 [23/26] drm/fb_cma_helper:
> Add drm_fb_cma_prepare_fb() helper
Just a quick tidy now to make the next patch neater.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 38
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_
In the next patch, a few rearrangements are made to make these static.
First, we move them so the changes are not lost in the noise.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 255 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 +
2 fil
The generic atomic helper likes to skip a prepare_plane_fb() if it
decides that the plane->fb is unchanged. This is wrong for us for a
couple of reasons:
- if the pipe is reconfigured (i.e. a size change) but the framebuffer
is untouched, we still have to flush any rendering prior to the
re
On Mon, Nov 14, 2016 at 01:06:09PM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote:
> > Chris, happy with this revision?
>
> Me? No. It still uses a thread instead of events, so I don't think it
> qualifies as a good example for anyone else wanting to do
Since an fb may have multiple VMA (due to rotations etc), we need to
wait a vblank and unpin the old VMA not if the fb itself is changed, but
if the underlying VMA is changed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 10 +++---
1 file changed, 7 insertions(+), 3
With atomic plane states we are able to track an allocation right from
preparation, during use and through to the final free after being
swapped out for a new plane. We can couple the VMA we pin for the
framebuffer (and its rotation) to this lifetime and avoid all the clumsy
lookups in between.
Si
On Mon, Nov 14, 2016 at 06:35:10PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> actually touching the hardware, in which case we won't force a modeset
> on all the pipes, and thus won't lock any of the
On Mon, Nov 14, 2016 at 06:53:58PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Using == to check for 180 degree rotation only works as long as the
> reflection bits aren't set. That will change soon enough for CHV, so
> let's stop doing things the wrong way.
>
> v2: Dro
== Series Details ==
Series: series starting with [1/5] drm/i915: Move intel_prepare_plane_fb() and
intel_cleanup_plane_fb()
URL : https://patchwork.freedesktop.org/series/15325/
State : warning
== Summary ==
Series 15325v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
On Tue, Nov 15, 2016 at 10:08:10AM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 06:35:10PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> > actually touching the hardware, in which case we
On Mon, Nov 14, 2016 at 06:35:11PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No need for the extra break statements and whatnot, just return the
> error directly. And tighten the scope of the local variables while at
> it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-b
On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> Gen graphics hardware can be set up to periodically write snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace via
> the
> i915 perf interface.
>
>
Commit 6b5e90f58c56 ("drm/i915/scheduler: Boost priorities for flips")
added priority boosting for the modern atomic pageflips (and modesets),
but we should do the same for existing users of mmioflips (we don't yet
need to consider csflips as they are not used by execlists and so do not
have any su
On Tue, Nov 15, 2016 at 08:58:13AM +, Chris Wilson wrote:
> In the next patch, a few rearrangements are made to make these static.
> First, we move them so the changes are not lost in the noise.
>
> Signed-off-by: Chris Wilson
Assuming you really just moved (didn't spot anything else):
Revi
On Mon, 14 Nov 2016, Dhinakaran Pandiyan wrote:
> We store DP link rates as link clock frequencies in kHz, just like all
> other clock values. But, DP link rates in the DP Spec. are expressed in
> Gbps/lane, which seems to have led to some confusion.
>
> E.g., for HBR2
> Max. data rate = 5.4 Gbps/
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoids frequent software forcewake.
This certainly gives advantage over the forcewake as this new
mechanism “decouples” CPU
On 15/11/2016 09:22, Chris Wilson wrote:
Commit 6b5e90f58c56 ("drm/i915/scheduler: Boost priorities for flips")
added priority boosting for the modern atomic pageflips (and modesets),
but we should do the same for existing users of mmioflips (we don't yet
need to consider csflips as they are not
On Tue, Nov 15, 2016 at 08:58:14AM +, Chris Wilson wrote:
> The generic atomic helper likes to skip a prepare_plane_fb() if it
> decides that the plane->fb is unchanged. This is wrong for us for a
> couple of reasons:
>
> - if the pipe is reconfigured (i.e. a size change) but the framebuffer
On Mon, Nov 14, 2016 at 06:49:22PM -0200, Paulo Zanoni wrote:
> Em Seg, 2016-11-14 às 22:26 +0200, Ville Syrjälä escreveu:
> > On Fri, Nov 11, 2016 at 06:49:59PM -0200, Paulo Zanoni wrote:
> > >
> > > Em Sex, 2016-11-11 às 22:24 +0200, Ville Syrjälä escreveu:
> > > >
> > > > On Fri, Nov 11, 2016
== Series Details ==
Series: drm/i915: Add execution priority boosting for mmioflips
URL : https://patchwork.freedesktop.org/series/15326/
State : success
== Summary ==
Series 15326v1 drm/i915: Add execution priority boosting for mmioflips
https://patchwork.freedesktop.org/api/1.0/series/15326
On 15/11/2016 09:37, Daniel Vetter wrote:
On Tue, Nov 15, 2016 at 08:58:14AM +, Chris Wilson wrote:
The generic atomic helper likes to skip a prepare_plane_fb() if it
decides that the plane->fb is unchanged. This is wrong for us for a
couple of reasons:
- if the pipe is reconfigured (i.e.
On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> With atomic plane states we are able to track an allocation right from
> preparation, during use and through to the final free after being
> swapped out for a new plane. We can couple the VMA we pin for the
> framebuffer (and its rotat
On Tue, Nov 15, 2016 at 10:08:10AM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 06:35:10PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> > actually touching the hardware, in which case we
On Tue, Nov 15, 2016 at 10:37:09AM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 08:58:14AM +, Chris Wilson wrote:
> > The generic atomic helper likes to skip a prepare_plane_fb() if it
> > decides that the plane->fb is unchanged. This is wrong for us for a
> > couple of reasons:
> >
>
On Tue, Nov 15, 2016 at 10:52:00AM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> > With atomic plane states we are able to track an allocation right from
> > preparation, during use and through to the final free after being
> > swapped out for a new p
On Tue, Nov 15, 2016 at 09:47:31AM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 04:29:04PM +0800, kbuild test robot wrote:
> > tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
> > head: 35cf03508d8466ecc5199c9d609e74e85bec785b
> > commit: 14d7f96f90fb65c2ca0e0ac7df237e06ff0
On Tue, Nov 15, 2016 at 09:46:40AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Add execution priority boosting for mmioflips
> URL : https://patchwork.freedesktop.org/series/15326/
> State : success
>
> == Summary ==
>
> Series 15326v1 drm/i915: Add execution priority
On Tue, Nov 15, 2016 at 09:36:34AM +, Tvrtko Ursulin wrote:
>
> On 15/11/2016 06:40, Praveen Paneri wrote:
> >Decoupled MMIO is an alternative way to access forcewake domain
> >registers, which requires less cycles for a single read/write and
> >avoids frequent software forcewake.
> >This cert
On Tue, Nov 15, 2016 at 09:57:37AM +, Chris Wilson wrote:
> On Tue, Nov 15, 2016 at 10:37:09AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 08:58:14AM +, Chris Wilson wrote:
> > > The generic atomic helper likes to skip a prepare_plane_fb() if it
> > > decides that the plane->fb
On Tue, Nov 15, 2016 at 10:02:23AM +, Chris Wilson wrote:
> On Tue, Nov 15, 2016 at 10:52:00AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> > > With atomic plane states we are able to track an allocation right from
> > > preparation, during use
Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> actually touching the hardware, in which case we won't force a modeset
> on all the pipes, and thus won't lock any of the other pipes either.
Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> When we end up not recomputing the cdclk, we need to populate
> intel_state->cdclk with the "atomic_cdclk_freq" instead of the
> current cdclk_freq. When no pipes are active, the actual cdclk_freq
> may be lower
On Tue, Nov 15, 2016 at 08:58:17AM +, Chris Wilson wrote:
> Since an fb may have multiple VMA (due to rotations etc), we need to
> wait a vblank and unpin the old VMA not if the fb itself is changed, but
> if the underlying VMA is changed.
>
> Signed-off-by: Chris Wilson
Imo we should move t
On Tue, Nov 15, 2016 at 11:10:26AM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 09:57:37AM +, Chris Wilson wrote:
> > On Tue, Nov 15, 2016 at 10:37:09AM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 15, 2016 at 08:58:14AM +, Chris Wilson wrote:
> > > > The generic atomic helper lik
On Tue, Nov 15, 2016 at 08:58:16AM +, Chris Wilson wrote:
> Just a quick tidy now to make the next patch neater.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 38
>
> 1 file changed, 21 insertions(+), 17 deletions(-)
>
>
On Tue, Nov 15, 2016 at 08:58:15AM +, Chris Wilson wrote:
> @@ -12340,7 +12325,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> cleanup_request:
> i915_add_request_no_flush(request);
> cleanup_unpin:
> - intel_unpin_fb_obj(fb, crtc->primary->state->rotation);
> + to
On 15/11/2016 00:39, Anusha Srivatsa wrote:
From: Peter Antoine
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-in
On Mon, Nov 14, 2016 at 12:58:19PM +0100, Daniel Vetter wrote:
> I want to move dumb buffer documentation into the right vfuncs, and
> for that I first need to be able to pull that into kerneldoc without
> having to clean up all of drmP.h. Also, header-splitting is nice.
>
> While at it shuffle al
On Mon, Nov 14, 2016 at 12:58:21PM +0100, Daniel Vetter wrote:
> Put the callback docs into struct drm_driver, and the small overview
> into a DOC comment.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
On 14/11/2016 17:34, Srivatsa, Anusha wrote:
[snip]
One idea could be to hide the guc loading form the user altogether and hence
improve usability (decrease exposed complexity) by having only two parameters;
i915.enable_guc_scheduling and i915.enable_huc.
That's a good point. But with this we
On Mon, Nov 14, 2016 at 12:58:23PM +0100, Daniel Vetter wrote:
> And shuffle the kernel-doc structure a bit since drm_crtc.[hc] now
> only contains CRTC-related functions and structures.
>
> Signed-off-by: Daniel Vetter
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_c
On Mon, Nov 14, 2016 at 12:58:25PM +0100, Daniel Vetter wrote:
> Just noise.
>
> Signed-off-by: Daniel Vetter
Sometimes it is interesting. Practice across the kernel is mixed, but
convergence on not putting extern.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technolog
On Mon, Nov 14, 2016 at 12:58:24PM +0100, Daniel Vetter wrote:
> And also put the overview section into the KMS Properties part of the
> docs, instead of randomly-placed within the helpers - this is part of
> the uabi.
>
> With this patch I think drm_crtc.[hc] is cleaned up and entirely
> document
On Mon, Nov 14, 2016 at 12:58:20PM +0100, Daniel Vetter wrote:
> Just cleans up what's there, still plenty missing.
>
> Signed-off-by: Daniel Vetter
I read it, seems to match my limited understanding of kerneldoc.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology
On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> Just code movement, doc cleanup will follow up later.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/Makefile| 3 +-
> drivers/gpu/drm/drm_crtc.c | 109 -
> drivers/gpu/d
On Mon, Nov 14, 2016 at 12:58:17PM +0100, Daniel Vetter wrote:
> Would be great if everony could add
everyone
> $ make DOCBOOKS="" htmldocs
>
> to their build scripts to catch these. 0day should also report them,
> not sure why it failed to spot this.
"make IGNORE_DOCBOOKS=1 SPHINXOPTS=-W htmld
On Mon, Nov 14, 2016 at 12:58:22PM +0100, Daniel Vetter wrote:
> kerneldoc expects the comment next to definitions, otherwise it can't
> pick up exported vs. internal stuff.
>
> This fixes a warning from the doc build done with:
>
> $ make DOCBOOKS="" htmldocs
>
> Fixes: d8187177b0b1 ("drm: add
On Mon, Nov 14, 2016 at 12:58:18PM +0100, Daniel Vetter wrote:
> Would be great if everony could add
>
> $ make DOCBOOKS="" htmldocs
>
> to their build scripts to catch these. 0day should also report them,
> not sure why it failed to spot this.
>
> Fixes: f54d1867005c ("dma-buf: Rename struct fe
On ma, 2016-11-14 at 20:11 +0200, Ville Syrjälä wrote:
> On Wed, Nov 09, 2016 at 04:24:58PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Add a per-pipe plane identifier enum (rev4)
> > URL : https://patchwork.freedesktop.org/series/14978/
> > State : warning
> >
>
Hi Tvrtko,
On Tuesday 15 November 2016 03:06 PM, Tvrtko Ursulin wrote:
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoids frequent software forcewake.
This certainly
On Tue, Nov 15, 2016 at 10:44:29AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:17PM +0100, Daniel Vetter wrote:
> > Would be great if everony could add
>
> everyone
>
> > $ make DOCBOOKS="" htmldocs
> >
> > to their build scripts to catch these. 0day should also report them,
> > n
On 15/11/2016 10:56, Praveen Paneri wrote:
Hi Tvrtko,
On Tuesday 15 November 2016 03:06 PM, Tvrtko Ursulin wrote:
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoid
On 14 November 2016 at 19:24, Abdiel Janulgue
wrote:
> A lot of igt testcases need some GPU workload to make sure a race
> window is big enough. Unfortunately having a fixed amount of
> workload leads to spurious test failures or overtly long runtimes
> on some fast/slow platforms. This library co
On 11/15/2016 11:02 AM, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 09:47:31AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 15, 2016 at 04:29:04PM +0800, kbuild test robot wrote:
>>> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
>>> head: 35cf03508d8466ecc5199c9d609e74e85bec785b
On 15 November 2016 at 11:59, Tomeu Vizoso wrote:
> On 14 November 2016 at 19:24, Abdiel Janulgue
> wrote:
>> A lot of igt testcases need some GPU workload to make sure a race
>> window is big enough. Unfortunately having a fixed amount of
>> workload leads to spurious test failures or overtly lo
Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
modification rather than proliferate it into all the callers of the
insert (which may or may not in fact have to do the insertion).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c
On Tue, Nov 15, 2016 at 11:16:50AM +, Chris Wilson wrote:
> Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
> modification rather than proliferate it into all the callers of the
> insert (which may or may not in fact have to do the insertion).
>
> Signed-off-by: Chris Wi
On 11 November 2016 at 18:53, Lyude Paul wrote:
> Alright, quick question: should we be going with your branch then or
> mine?
I'm not going to be able to work on this in the short term, so I think
it's up to you.
Wonder if there are more opinions regarding xmlrpc vs. libsoup. I
liked it mostly
== Series Details ==
Series: drm/i915: Invalidate the guc ggtt TLB upon insertion
URL : https://patchwork.freedesktop.org/series/15336/
State : success
== Summary ==
Series 15336v1 drm/i915: Invalidate the guc ggtt TLB upon insertion
https://patchwork.freedesktop.org/api/1.0/series/15336/revis
On Tue, Nov 15, 2016 at 10:42:08AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> > b/drivers/gpu/drm/drm_dumb_buffers.c
> > new file mode 100644
> > index ..4b4364b61c8d
> > --- /dev/nul
On Tue, Nov 15, 2016 at 10:37:26AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:22PM +0100, Daniel Vetter wrote:
> > kerneldoc expects the comment next to definitions, otherwise it can't
> > pick up exported vs. internal stuff.
> >
> > This fixes a warning from the doc build done wit
On Tue, Nov 15, 2016 at 12:47:31PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 10:42:08AM +, Chris Wilson wrote:
> > On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> > > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> > > b/drivers/gpu/drm/drm_dumb_buffers.c
> > > n
On Tue, Nov 15, 2016 at 12:53:48PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 10:37:26AM +, Chris Wilson wrote:
> > On Mon, Nov 14, 2016 at 12:58:22PM +0100, Daniel Vetter wrote:
> > > kerneldoc expects the comment next to definitions, otherwise it can't
> > > pick up exported vs. in
Request the GPIO by index through the consumer API. For now, use a quick
hack to store the already requested ones, simply because I have no idea
whether this actually works or not, and I have no way to test it.
Cc: Mika Kahola
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_
Use a table similar to vlv to check for accepted gpio indexes. For now,
add all, but this list should be trimmed down. Use managed gpio request,
which will be automatically released when the driver is detached.
Cc: Mika Kahola
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_
On Tue, Nov 15, 2016 at 11:16:50AM +, Chris Wilson wrote:
> Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
> modification rather than proliferate it into all the callers of the
> insert (which may or may not in fact have to do the insertion).
>
> Signed-off-by: Chris Wi
Commit 721d8747e3a2 added sync() calls to igt_main and
igt_simple_main, making self-tests fail to build. #including unistd.h
in igt_core.h fixes that.
Fixes: 721d8747e3a2 ("igt: Add a test for reordering execbufs")
CC: Chris Wilson
Signed-off-by: Petri Latvala
---
lib/igt_core.h | 1 +
1 file c
Testcase for plane visibility after atomic modesets. The idea of the test
is the following:
- draw a blue screen with high resolution
- enable a yellow plane, visible, in lower-left corner
- set a new lower resolution mode (1024x768) that makes plane invisible
- check from debugfs 'i915_displa
On Tue, Nov 15, 2016 at 02:34:42PM +0200, Petri Latvala wrote:
> Commit 721d8747e3a2 added sync() calls to igt_main and
> igt_simple_main, making self-tests fail to build. #including unistd.h
> in igt_core.h fixes that.
>
> Fixes: 721d8747e3a2 ("igt: Add a test for reordering execbufs")
> CC: Chri
On Tue, Nov 15, 2016 at 01:00:14PM +, Chris Wilson wrote:
> Reviewed-by: Chris Wilson
> -Chris
>
Thanks, pushed.
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Chris,
On Tuesday 15 November 2016 03:37 PM, Chris Wilson wrote:
On Tue, Nov 15, 2016 at 09:36:34AM +, Tvrtko Ursulin wrote:
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single rea
== Series Details ==
Series: drm/i915/bxt: add bxt dsi gpio element support (rev2)
URL : https://patchwork.freedesktop.org/series/15338/
State : success
== Summary ==
Series 15338v2 drm/i915/bxt: add bxt dsi gpio element support
https://patchwork.freedesktop.org/api/1.0/series/15338/revisions/
Hi
On 15.11.2016 10:45, Tomeu Vizoso wrote:
> Hi Abdiel,
>
> here running the whole of kms_busy causes all subtests after the first
> one to be skipped due to:
>
> Test requirement not met in function __real_main164, file
> ../../intel-gpu-tools/tests/kms_busy.c:195:
> Test requirement: gem_has_
Hi Mika,
On 15 November 2016 at 12:38, Mika Kahola wrote:
> Testcase for plane visibility after atomic modesets. The idea of the test
> is the following:
>
> - draw a blue screen with high resolution
> - enable a yellow plane, visible, in lower-left corner
> - set a new lower resolution mode (
On 15 November 2016 at 09:01, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 06:59:16PM +0900, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Signed-off-by: Gustavo Padovan
>> ---
>> tests/kms_atomic_transition.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a
On Tue, Nov 15, 2016 at 11:14:29AM +0100, Maarten Lankhorst wrote:
> Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> > actually touching the hardware, in which case we won't force a m
Op 15-11-16 om 14:41 schreef Ville Syrjälä:
> On Tue, Nov 15, 2016 at 11:14:29AM +0100, Maarten Lankhorst wrote:
>> Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
>>> actually touching
On 15.11.2016 12:59, Tomeu Vizoso wrote:
> On 14 November 2016 at 19:24, Abdiel Janulgue
> wrote:
>> A lot of igt testcases need some GPU workload to make sure a race
>> window is big enough. Unfortunately having a fixed amount of
>> workload leads to spurious test failures or overtly long runti
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
On Tue, Nov 15, 2016 at 10:44:29AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:17PM +0100, Daniel Vetter wrote:
> > Would be great if everony could add
>
> everyone
>
> > $ make DOCBOOKS="" htmldocs
> >
> > to their build scripts to catch these. 0day should also report them,
> > n
On Tue, Nov 15, 2016 at 10:32:14AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:23PM +0100, Daniel Vetter wrote:
> > And shuffle the kernel-doc structure a bit since drm_crtc.[hc] now
> > only contains CRTC-related functions and structures.
> >
> > Signed-off-by: Daniel Vetter
> > d
Hangcheck state accumulation has gained more steps
along the years, like head movement and more recently the
subunit inactivity check. As the subunit sampling is only
done if the previous state check showed inactivity, we
have added more stages (and time) to reach a hang verdict.
Asymmetric engine
If we have a bad client submitting unfavourably across different
contexts, creating new ones, the per context scoring of badness
doesn't remove the root cause, the offending client.
To counter, keep track of per client context bans. Deny access if
client is responsible for more than 3 context bans
As hangcheck score was removed, the active decay of score
was removed also. This removed feature for hangcheck to detect
if the gpu client was accidentally or maliciously causing intermittent
hangs. Reinstate the scoring as a per context property, so that if
one context starts to act unfavourably,
Bannable property, banned status, guilty and active counts are
properties of i915_gem_context. Make them so.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h| 27 ---
drivers/gpu/drm/i915/i915_gem.c| 25 +++
Now when driver has per context scoring of 'hanging badness'
and also subsequent hangs during short windows are allowed,
if there is progress made in between, it does not make sense
to expose a ban timing window as a context parameter anymore.
Let the scoring be the sole indicator for ban policy a
In order to simplify hangcheck state keeping, split hangcheck
per engine loop in three phases: state load, action, state save.
Add few more hangcheck actions to separate between seqno, head
and subunit movements. This helps to gather all the hangcheck
actions under a single switch umbrella.
Cc: C
On ma, 2016-11-14 at 08:53 +, Chris Wilson wrote:
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -53,6 +53,12 @@ i915_vma_retire(struct i915_gem_active *active,
> if (--obj->active_count)
> return;
>
> + /* Prune the shared fence arrays iff completely idle (inc. external
== Series Details ==
Series: drm/i915: Be more careful to drop the GT wakeref
URL : https://patchwork.freedesktop.org/series/15349/
State : success
== Summary ==
Series 15349v1 drm/i915: Be more careful to drop the GT wakeref
https://patchwork.freedesktop.org/api/1.0/series/15349/revisions/1/m
On 15/11/2016 13:17, Praveen Paneri wrote:
Hi Chris,
On Tuesday 15 November 2016 03:37 PM, Chris Wilson wrote:
On Tue, Nov 15, 2016 at 09:36:34AM +, Tvrtko Ursulin wrote:
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
register
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
On Tue, Nov 15, 2016 at 04:38:19PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-14 at 08:53 +, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -53,6 +53,12 @@ i915_vma_retire(struct i915_gem_active *active,
> > if (--obj->active_count)
> > return;
> >
>
1 - 100 of 157 matches
Mail list logo
